The Dropbox Security Team is responsible for securing over 500 petabytes of data belonging to over half a billion registered users across hundreds of thousands of businesses. Securing data at this scale requires a security team that is not only well-resourced, but also one that can keep ahead of the expansion of our platform. We focus on scaling our own leverage, so each new security person we add multiplies the impact of our team.
Over the course of this year—and beyond—we’ll go into more detail on how Dropbox approaches security and some of the projects we’ve tackled. Protecting Dropbox requires serious investments in security. We have a large number of security sub-teams and we’ll be hearing from many of them. Some of the themes we’ll look to explore in more detail include:
Culture, not training
It’s relatively easy to spin up an annual security training and declare your responsibility done. We do have security training, of course, but stopping there would be a mistake. A security team needs an open, ongoing relationship with the rest of the company, not a once-a-year checkpoint. At Dropbox, we’ve caught many attacks and internal problems early because of this partnership with Dropbox employees. By nurturing our culture of security, we’re scaling out our team’s instincts to the wider company.
Independent validation
The strongest defenses are the ones that are regularly tested and improved on an ongoing basis. I’ve been to dry board meetings in the past where I’ve been asked “do you get an annual pen test?,” as if an affirmative answer were all that’s needed for a robust security posture. We engage annually in not one, but multiple external paid product assessments: pen tests, product security assessments, and formal red team engagements. On top of these external tests, we have a dedicated internal Offensive Security team that performs adversarial testing day in, day out.
And we still do more. On top of that, we invite the broader security community to participate via our Bug Bounty Program. The bounties have helped us close many important bugs, and build strong relationships with researchers. We’ve seen a lot of success and we recently increased our rewards to industry-leading levels. We’ve effectively scaled out security testing to the internet at large.
Engineering advanced tooling
One of the best ways to scale a team is to write code and tools and have computers do the work. We use in-house engineering to counter attempted abuse of our product in many different ways (for example, deflecting password brute forcing attempts). We also use engineering to help with internal security challenges. Last year, we open sourced SecurityBot, a way to automate certain components of internal alerting. For critical applications where commercial tools are lacking, we’re not afraid to engineer open source replacements, such as for Mac OS host monitoring.
Closer to the product, we make sure to identify the most critical pieces of code and invest heavily in these places. An example here is the care we take in choosing how to hash and encrypt user passwords at rest. A further example is how we encrypt data in transit: we don’t just check the “SSL” box, we also use a range of industry-leading HTTP, SSL and cryptography best practices.
Enabling users to self-serve
Helping users to discover features that help them self-secure is a great way to scale. We’re an early supporter of multi-factor authentication and support very strong factors including U2F keys. But launching stronger authentication, ironically, may introduce scaling challenges in account recovery or risk more account lock outs. Our goal is to make strong security easy, so we launched linked mobile devices as a strong self-serve recovery option.
And sometimes it’s simple things like making sure the technology behind “standard” features—such as the password strength estimator—is doing a great job at guiding users to good choices that can have a big impact.
I’m excited for what the team will deliver in 2018. Follow our progress here.
