This article includes key takeaways from Don Goodman-Wilson’s talk on how to scale security. You can view the full video on Youtube or…

This article includes key takeaways from Don Goodman-Wilson’s talk on how to scale security. You can view the full video on Youtube or check out the latest from our Scale series.

Formerly at Screenhero then Slack, Don was most recently Head of Developer Relations at Sqreen. Don was on the ground the day Slack’s security was breached, and shares some of the insights scaling startups need to handle the inevitable: getting hacked.

3 key mindsets

Mindset #1: It’s never too early

Security is often viewed as a massive undertaking, as well as one that can be put off until later. Don takes a page out of Blaise Pascal’s book to illustrate why this reasoning is flawed. The same logic from Pascal’s wager can be applied to security: in a condition of uncertainty about the existence of God, or the existence of a serious security threat, Don invites startups to consider the question “are we willing to bet our startup that we won’t get hacked?” instead. In the event of an attempted attack on your systems, the decision to invest in security or not yields a similar result: mild satisfaction. On the one hand you may have spent a little on something that turned out not to be critical, or saved up a small amount. However, in the event of an attempted breach, investing in security yields infinitely positive returns (maintaining the goodwill and trust you’ve managed to muster) whereas failing to do so yields infinitely negative returns (you lose the startup). Considered from this angle, the decision to invest in security is a no-brainer: the infinitely positive outcome of investing in security and preserving your user’s trust outweighs all the other options. Which takes us to mindset #2:

Mindset #2: Your users trust you (for now)

Don’s framework for thinking about security is governed by one simple principle: maintaining user trust. In the hierarchy of security needs which he sketches out, user trust comes at the top of the pyramid, followed by the data, the app or website, the network, and lastly the physical layer. Placing user trust as the highest rung of this hierarchy creates a goal which security teams can work towards. In determining which security policy to implement, they can bring it back to that goal and to whether said policy contributes to user trust. The resulting rationale is simple and practical: if the security measure you’re considering doesn’t contribute to user trust, don’t do it.

Note: Some internal measures, though they aren’t made public to your user’s, can contribute to this goal. Don takes the example of Slack’s “Security Playbook” to highlight this point: though the existence of this protocol wasn’t made public, the guidelines that it stipulated in the event of a breach allowed Slack to demonstrate that it was prepared to handle such an occasion, turning a security fail into a security win as far as user trust was concerned.

Mindset #3: You’re going to f*** up

We’re all human: mistakes happen. Having a culture that tolerates mistakes is a first step in scaling security. Accepting that something will go wrong will encourage your team to think proactively about what to do when that happens. It also encourages team members to adopt open and honest communication with one another, a necessary prerequisite to successfully tackle best practice #1:

4 key best practices

Best practice #1: Be public

Don was at ground-zero when Slack experienced the biggest security breach in the history of the company. And their first response was to talk openly about what had happened — immediately. The result? People trusted Slack even more…

Note: For the days following the incident, the entire engineering team (the largest at Slack) were all put on support. Their use of a public platform (Twitter, in Slack’s case) also reinforced user trust by showing that the company had nothing to hide and that it was fully committed to resolving the issue.

Best practice #2: Have a playbook

The reason why Slack responded this way is that they had a playbook in place to treat the unlikely event whereby they might be hacked. The goal of the playbook was two-fold: firstly, to extract the DB without tampering with the evidence so as to better understand the hack (who was affected, why, how, …), secondly, to treat the downfall from such an event proactively:

Best practice #3: Respond proactively

Slack did more than just communicate about the hack and offer a detailed investigation to those users which were affected. It also shifted its roadmap, increasing resources being allocated to a key security feature — 2-factor authentication — so as to deliver it quicker and strengthen the perception that users could trust Slack with their data.

Note: The feature in question was already on the roadmap. However, by increasing the velocity on shipping it, Slack proved that it was fully committed to preventing this type of attack in the future, further reinforcing user trust.

Best practice #4: Treat security like a product

Building security is necessary, but not all at once. Proceeding in incremental steps, as one would with a regular product, insures that your “security MVP” is in line with your current assessment of the threat level. As the product grows and more features are added, the threat level may rise accordingly — as was the case at Screenhero while Don was working there. Treating security like a product ensures that you’re able to deliver at scale, and that the growth of the product is met by a corresponding growth in security.

Note: Don points out several industry-based exceptions to this. Some industries will have a higher baseline purely based on the user data they are entrusted with, other industries will have regulatory or other contractual constraints on what they can and can’t communicate, in what fashion and with whom.

Subscribe to get notified of the latest Scale talks.

References:

Pensées, Blaise Pascal

A Theory of Human Motivation, Abraham Maslow

The SaaS CTO Security Checklist

About Don Goodman-Wilson:

Formerly at Screenhero then Slack, Don was most recently Head of Developer Relations at Sqreen. Don had first-hand experience in managing security: both from a risk management point of view and from a communication standpoint, offering a fresh perspective on one of the most-critical and less-discussed areas of scaling a startup. Follow Don on Twitter.