Security and Privacy when Building Great Products

Frédéric Rivain at UXDX USA. Video: https://www.youtube.com/watch?v=a9XQeJysIuw

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why privacy and security matter for every product

[00:00:00] My name is Frédéric. I am the CTO of Dashlane. We build a password manager to help you manage your digital identity in a safe and user-friendly way, and today I'd like to talk to you about how we think about privacy and security at Dashlane, and why I feel it is really important for you to build great products.

[00:00:20] We were founded 12 years ago and we have a distributed team globally, mostly between France, Portugal and the US. Our products address both consumers, the B2C, and the enterprise world, B2B. Just to give you a sense of scale, we have around 20 product engineering agile teams.

[00:00:39] When we think about privacy and security, it is really about the two sides of a similar coin for us. You can't have one without the other. In our case, because we store very sensitive data for our customers, their logins, their passwords, their payment information, it's obviously mandatory to ensure that the data is really secure, really private, and only accessible by the users themselves.

[00:01:03] Our product, like password managers in general, must be built by design for privacy and security. But even though this is true for password managers, I believe it applies also to most products to some extent. We all store, to some level, sensitive information on behalf of our customers, whether it's medical information or payment information and so on.

Classifying the data we hold

[00:01:27] So let's start with the perspective of privacy. Firstly, the important thing is that you need to be clear and explicit about what data you have and how you classify it. For Dashlane, as you can see on the screen, we have three main categories. First, the customer vault. That is the core of our product. Everything the user stores is in there, and obviously it's critically sensitive.

[00:01:51] Then the middle layer is the user data, and we have two flavors of that data. Account data, things like the email which you use to create an account — and we try to minimize the number of data points that we have on that front. We don't want much and we shouldn't have much, because it's what we call PII, personally identifiable information.

[00:02:10] And then the second flavor is more traditional event data, the logs that we collect about the usage of our product. Yet again, we try to be frugal about it. We do need some of it to operate, but we want to minimize it, and we just want to aggregate what is needed for us to improve the product, do marketing and so on.

[00:02:30] Finally, in our case we have what we call activity logs. They are the logs related to how our users are using Dashlane on a daily basis, how they interact with websites and online services. Of course, in that case we don't want to know what each specific user is doing. I don't want to know that you're using Amazon or that you're using Dropbox or so on. So we consider those logs as sensitive data, and they are anonymized and aggregated.

The customer vault and zero-knowledge architecture

[00:02:54] But let's do a bit of a deep dive into each type of data and how we address them. First, managing the customer vault. This is very specific to our need and our business. The way we manage a customer vault is based on a security concept called zero-knowledge architecture. It implies that nobody can access the user data except the users themselves. Everything is built around that very simple notion, which, to be honest, is very complex to put in practice.

[00:03:22] The short version of it is that the vault is always encrypted locally on the user's device. It's using a key derived from a secret, which we call the master password, that only the user knows, nobody else. That master password is never transmitted or stored by Dashlane. That's really important, because this is what protects you as a user and that's what makes your data private.

[00:03:44] Which, by the way, means that if you forget that master password, we can't do a forgot-password flow like on traditional online services. We can't give you back your access, because we don't have the key, so it means that you as a user will have to start over if you lose that master password.

[00:04:00] Obviously you may not have such sensitive information in your own product, but if you do, whether it is financial information, health data or personal content, you should consider the level of encryption and the technical complexity required to ensure that you offer the best level of protection for the privacy of your customers. So that's really something that's important even for you.

Logs, PII and the data privacy committee

[00:04:23] The two other types of data that I mentioned are generated from the client applications and they are stored in a segregated database. For us it's, on the one side, the activity logs, which are anonymized locally in the client before being sent to the Dashlane servers. Of course we are also dropping parts of the timestamps, to avoid the risk of correlation, for instance. We're doing more filtering on the server side, to ensure that if there is an issue on the client side we don't have unwanted details going up by mistake.

[00:04:51] We also try to really, really limit PII, personally identifiable information. Those are the really sensitive ones that are regulated, so the less you have, the better you are. And because of the diversity of those logs and data, we created what we call a data privacy committee. It's a group made of myself as CTO, our CSO, our general counsel, some representatives from data, from product, from the different departments. What we do in that committee is have an ongoing review of our practices, and in particular we evaluate and approve the addition of new data points inside the logs. Do we actually need those new logs? What level of granularity should we have? What type of classification do they belong to, and so on?

[00:05:31] One thing to keep in mind as well, regardless of the types of data, is that with the explosion of SaaS tools that we all use, some of the data will be duplicated into third-party services, and that increases the risk of what we call contamination. So think about platforms like Salesforce, like Braze for CRM, SendGrid, Zendesk. All these platforms are creating some form of privacy exposure for you, so you need to keep them in mind.

Compliance and the privacy policy

[00:05:58] A word about the compliance side of privacy. Our world is becoming more and more regulated, so this is not something you can avoid, and you should always, yet again, try to minimize your compliance exposure. The more you can limit the need for data, for PII, for regulated data types, the better you are. It will make things easier for you also regarding compliance and audits and those types of activities.

[00:06:21] It's not always easy, depending on your business, but at least you should ensure that you have strong segregation between your different categories of data, that you maintain an up-to-date inventory of all data items that you collect — where are they coming from, what is their sensitivity, how are you using them, where could they be forwarded, to which party could they be forwarded — and you also need to define the retention policy per data type. How long should you keep each data type? That's very important from a regulatory standpoint.

[00:06:52] There are a lot of mandatory flows in regulations like GDPR or CCPA, which is the Californian version of GDPR, so ideally you want to automate all those flows, so that you respect the rules and you don't have to think about it. Just as an example, recently, I mean a few months back, Apple made it mandatory for iOS applications to offer in-app access to the deletion of your account. So that's typically a flow that you want to automate, that you delete your account automatically across the board inside your own system, but also across the different systems where you're delegating data to third parties.

[00:07:26] Another point about compliance is that all those practices should be compiled into your privacy policy, and that privacy policy should obviously be published publicly for your customers, either on your website or inside your applications. You have a screenshot of the Dashlane privacy policy here. One thing that I really like about the Dashlane one is that there is a summary in plain English before all the legal jargon, that makes it a nicer read for our customers. That's something that our general counsel implemented, which I find a very nice tip.

Our privacy stance

[00:07:59] One last thought about privacy: it must be an ongoing conversation inside the organization. We are not in a static world, so it is important to always review our practices. How can we find the best solution for the business while ensuring the privacy of our users? For that purpose, at Dashlane we have built what we call our privacy stance. It's a little bit like the three laws of robotics from Asimov: we have a set of principles from the highest order to the more specific, and principles must be considered in order. So we start from the top, and of course principle two cannot go against principle one.

[00:08:34] In our case, principle number one is that Dashlane as a company should never be able to access and use the data. Here we are really referring to the customer vault, and the fact that only the customer can access their customer data. Principle number two is related to the B2B context. As an employee in an organization, you have a workspace and a personal space in your vault when you use Dashlane. Of course your admin, the IT team in your organization, can know certain things about what's happening in your workspace, but they shouldn't know what's happening in your personal space, so you have a strong segregation of that customer data.

[00:09:09] Principle number three refers to logs and account data and how we aggregate the data, as I mentioned previously. And finally, number four is about the customization and personalization of the user experience. Most of the time, in our case, it needs to happen on the client side if you want to maintain privacy. If you don't have a privacy stance for your organization, I really encourage you to do the exercise. It's an interesting way to align the organization across how you think about privacy, and then have a guideline for your business.

What security means for us

[00:09:40] Let's look at security. Security is about keeping everybody safe. When we say everybody safe, it's obviously our customers — and this is also one of the key purposes of our product in our case — but it's also about employees, it's also about the company, the shareholders and so on. So really, how do we protect everybody?

[00:10:03] Depending on your business it can be very existential, and in our case, because we build a security product, security is one of our core features, but it has to also be a marketing input. In our case we want to use security as one of the factors why you should use Dashlane. It can be that for you as well, depending on your own product.

[00:10:22] In our case there are also two additional important considerations. We think we have a mission to educate our users around security. Most of them will start originally because they have the pain point of managing their passwords, but hopefully, because we can educate them, we can teach them about security, they will onboard and raise their awareness about security and privacy as they start using Dashlane.

[00:10:46] And last but not least, our second kind of mission is that we hope that at our level we can influence the digital world, that we can have an impact and make sure that privacy and security become more and more foundational on the internet. An example for us is how we participate in some consortiums like the FIDO Alliance, which is a group of organizations that are trying to contribute to pushing multi-factor authentication solutions.

Security is mission impossible: the three goals

[00:11:12] But let's start with a given: security is mission impossible. We know that one day we will be breached[?], or that we will suffer critical security incidents, so we really want to be pragmatic about it. The goal of our effort is really not to guarantee that nothing bad will ever happen, because something will. The goal is first and foremost to minimize the likelihood that something would happen. We want to make it very complex and expensive for attackers to target us, and this is kind of the game of cat and mouse: if it's too hard for the cat to catch the mouse, they will go someplace else. So that way, hopefully, the hackers will target some easier targets.

[00:11:52] Number two, we want to make sure that we are as ready as possible, which means that if something happens we are able to react to a security crisis in a very fast way. That readiness can make a huge difference depending on how prepared you are. Are you able to react fast? Do you have the right countermeasures in place, the right internal crisis organization, the right investigation capabilities? What I strongly encourage you to do is to design your own code red plan, which is the plan of what happens in that case, and you need to rehearse it and practice it with the organization.

[00:12:24] And finally, the last goal here is to minimize the impact if something bad were to happen. How can we make sure we limit as much as possible the impact for our customers and of course for our company? So far, so good, touch wood: we never had a public security breach, as far as we are aware. But yet again, that does not mean it won't happen, so we should not stop investing in security and we should keep rehearsing for that moment when it happens.

Our threat model: five attack vectors

[00:12:55] So if someone wanted to hack Dashlane, how would they do it? We are going to try to identify the attack vectors and the main threats against us, and doing that exercise of building your own threat model is a very important one. I strongly encourage you to do the same for your organization and be aware of, okay, what happens if someone tries to hack us?

[00:13:16] In our case we have five main attack vectors against Dashlane. We are going to deep dive on each of them, but here's the high-level view. Number one, the compromise of the client application: that's essentially bugs and vulnerabilities. Attack vector number two, compromising the user's device, like planting a malware, planting a trojan horse or a keylogger, for instance. Attack vector number three, which is the main one, attacking the servers, compromising the server infrastructure.

[00:13:43] Attack vector number four, breaching our internal IT: what if someone gets into the Dashlane network and accesses our systems? And finally, last but not least, the human factor, the insider threat: what happens if someone is bribed or threatened, or an employee goes wrong?

Bugs and vulnerabilities in the client

[00:13:59] But let's look first at the first attack vector. Well, no code is perfect, there are always bugs, issues, and those bugs and issues can be ways for malicious actors to exploit them and get access to the customer's data. So it could be a bug in a client application, it could be a man-in-the-middle attack to intercept communication between the server and the client to get data in transit. Here the impact is really about leaking some of the user data, well, it depends on where the vulnerability is.

[00:14:27] The common theme, by the way, to all those attack vectors, is that reputation is always at risk, even if the actual impact can be limited. The impact on Dashlane and reputation, and the communication that you have to do in terms of security crises, are always very critical to us, and they should be to everybody.

[00:14:45] But there are many ways to try and mitigate that risk. Most of them relate to best practices of the secure development lifecycle: for instance code analysis, code reviews, having multiple layers of security review, reviewing code continuously. I just want to highlight two of them. The main one for us is obviously the concept of zero-knowledge architecture. It is a very simple principle, but it's really a way for us to be protected and make the life of hackers very hard.

[00:15:12] And then the second one that I want to mention is bug bounty programs. Even if you don't have a team with dozens of security engineers — and of course there will never be enough engineers to look at this — you can use bug bounty programs. It's a way for you to have more eyeballs on your code, more eyeballs on your platform, and it will give you a greater chance to find those vulnerabilities and bugs before the hackers find them.

[00:15:35] We do use bug bounty programs. The main one is HackerOne, and we have asked the security researchers to investigate our code, try to find vulnerabilities. Our head of security, our CISO, likes to call those platforms the Uber of security. Even if you're a small startup or an early-stage company, I strongly encourage you to already start having a smaller program on those bug bounty platforms. It's already a good start.

Compromising the user's device

[00:16:01] The second attack vector is the compromise of the user's device. What if the user's laptop, the user's mobile, is infected by a malware or keylogger? In that case the attacker can steal the user data directly from the device memory. At that point it's kind of game over already, since the attacker is already inside of the house. You've already given the key to the house, so he can do whatever he wants, and unfortunately, as Dashlane, there is not so much we can do to prevent this. At the end of the day it's really more of an OS-level challenge to mitigate against those malicious attacks. Still, we try to do our best to make the life of the attacker more complicated by using techniques such as obfuscation in memory, hardware encryption, advanced two-factor authentication and so on. But that's a tricky one, to be honest.

Attacking the servers

[00:16:49] An attacker could try to penetrate our servers. We are hosted on AWS, and they could try to see the encrypted user files that we are storing on behalf of our customers on our servers. In practice I don't think that's the most effective attack, because by doing so the attackers would get access to millions of small encrypted files without having any of the keys, and that's thanks to our zero-knowledge architecture. Or they could of course try to brute force each of those files, but that would require a massive amount of computing power, and I'm not sure that's efficient.

[00:17:23] On that front, there are very traditional server-side security hardening practices, so it's a well-known activity. You don't need to reinvent the wheel, you need to leverage the best practices from the industry, along with the compliance standards like PCI DSS, SOC 2. In our case we also benefit from all the built-in security from AWS and the many years of the tech community observing security and improving security. So it's really about doing things right in that case.

Breaching internal IT, and the insider threat

[00:17:52] This one, in a sense, is more sensitive. If someone were to compromise the internal IT infrastructure, that would be a bigger deal for us, and here the use case is not really intellectual property. It's really more about someone accessing, for instance, the release pipeline[?] of our engineering team and being able to plant malicious code in the software, so that we would ship a Dashlane application with malicious software inside, like a back door or something along those lines.

[00:18:16] So that's the traditional supply chain attack. We had the SolarWinds incident, which was a typical example of those types of attacks. As a startup it's the trickiest one[?], because you need to find the right balance between strict IT security practices and also employee productivity. We need to still go fast as a startup. Of course we need more on the security side because we are a security product, and that's why we have 2FA everywhere, we have strong network security and breach detection mechanisms. We've tried to put in place tight IT processes such as least privilege access, the fact that you have only access to the minimum you need for your job, and only the systems that are required for you to do your job, not much more. But still, it's always a trade-off and a balance to find between the productivity of the company and the security.

[00:19:05] The last attack vector has a similar impact as the previous one. One comes from the outside, the other one from the inside, but the risk is similar. Of course we trust our employees, but for their own safety and the safety of the company we need to think about, okay, what if one or several employees were bribed with money, or threatened, or one of them went wrong? What could they do to make harm on our customers and our company? So yet again, the sensitive system here is our software factory. We make sure we have a very secure pipeline with full traceability. You need multiple approvals to ship code into production. We sign the application to make sure that you have integrity of the data. So the goal here is really to make sure that one employee alone cannot ship a corrupted Dashlane release[?].

Three takeaways

[00:19:52] That's it for today. I want to leave you with three main takeaways, very basic ones. The first one is that privacy and security is not a topic just for the security or the legal teams. It really is a company conversation, so it needs to be something everybody's accountable for, and you need to have everybody in the organization talking about privacy and security.

[00:20:13] Number two, it will not happen by magic. There is work, there is an effort that needs to be put behind privacy and security, so you should be proactive about it, you should invest some of your time in this. And finally, last but not least, most of the time it's really about common sense. You don't have to reinvent the wheel, just do what seems to be the most obvious in your own context. Keep it simple, but really integrate it from the start in everything you do.

[00:20:39] Thank you for listening. Be safe, be the ambassadors of privacy and security in your own organization, and of course, if you don't do it, use a password manager. Thank you very much.