Frankly Speaking - Breaches are inevitable

Security helps limit the damage

Recently, many major breaches, such as CircleCI, Reddit, and LastPass have made the news. I’ve analyzed them in previous blog posts and given my thoughts on handling them. Although based on the descriptions, I was able to understand and infer some possible gaps that might have led to the breach, it’s hard to compare breaches. Moreover, it would be close to impossible to fully understand the whole context, i.e. what decisions and actions the company took that led them to that point. In fact, this is extremely difficult even if you worked there unless you have worked there since the company’s inception. Either way, where am I going with this? I’m returning to this post's original point: breaches are random and inevitable, which has been a theme I’ve discussed in previous posts.

This is definitely a shifted mindset from the past where the goal of security was to prevent security incidents and breaches. However, this is no longer a realistic goal today given the complexity of systems and the competitive nature of software that requires certain risks and tradeoffs to stay ahead.

So what is security’s role assuming this scenario? How does this change the way we do security? In this newsletter, we explore these questions.

To start, why do I believe breaches are inevitable and random?

Increasing security leverage and setting reasonable expectations

An obvious statement to start: As long as companies have any public internet-facing assets, there is always a non-zero probability of a breach. However, the job of security is to mitigate this risk through preventative measures and limiting damage blast radius during an incident. Similarly, having a solid security team that is transparent can establish trust with a customer base and fuel growth. That allows security to be both a risk mitigator and a value generator, which is a great position.

Unfortunately, many executive teams set unreasonable expectations that security’s job is to prevent a breach. That’s not realistic for a number of reasons, and I don’t see enough security leaders push back on that expectation. One reason for this is that many security leaders are expected or used to be primarily risk mitigators. However, this dynamic has changed as customers and users demand and expect more trust.

This changing dynamic sounds complicated, so how does security adapt to this? How does security mitigate risk and take on risk at the same time? Honestly, nothing material has changed — just how risk is calculated.

Previously, there was a balance between cost and risk. The security team’s goal was to balance risk with cost, i.e. negotiate with leadership on the cost of reducing risk. However, now, security has another lever to pull. They can take some risks to reduce risk. That sounds somewhat counterintuitive, so let’s unpack that.

This is the power of security engineering. The organization is taking on execution and cost risk like a typical engineering team where the company invests in building software that can produce customer value and increase operational efficiency. The added benefit of the security engineering team is that it can also reduce security risk, but there is an upfront risk of time and cost. In my opinion, this provides security with flexibility, specifically being able to ask for more budget that can both generate value for the end user and reduce organizational risk.

A new framework for security risk

With that said, let’s go back to the idea that breaches are inevitable. Why do I say this? First, attacks are random. Of course, if the company is a brand name or holds important data, it becomes a bigger target, but hackers are human and limited. That is, there aren’t unlimited hackers who have unlimited capabilities. They have to choose targets and how they allocate their efforts. In many ways, they behave like organizations, which many of them are. The point I’m making here is that whether an organization is attacked or not and whether that attack is successful has high variance. A successful security program makes a successful attack less likely, but a breach in and of itself doesn’t give a sufficient signal of the quality of a security program.

Second, it’s nearly impossible to protect a system given today’s complexity. Everyone talks about defense in depth or layers of security. Those definitely help, but it’s difficult to completely prevent even the basic attacks and “weak” points in systems. There are zero days, hacks of SaaS applications out of your control, legacy systems, and the list goes on. At the end of the day, there will always be some risk, however minimal.

How do we think about security in this type of world? We need to think of a new framework to set proper expectations for security.

Security can’t solve all risks and might need to take on some risks for business purposes. In the past, security has always been a blocker, trying not to always say no and not be a scapegoat. Those days are over. Security should and needs to act as a partner in helping the organization grow and deliver value. This shift means that executive teams need to understand that everyone shares the risk of security. This is a more realistic and healthier expectation, and most importantly, it ends up benefiting the business as a whole.

Following up on that, security should set clear threat models and work with the rest of the organization, especially engineering, to ensure they are addressing and mitigating the most substantial risks for that organization. The last part is important because risks differ from place to place, and it’s hard to address without proper context. With that said, security should take a data-driven approach to figure out how risks should be prioritized and addressed. Too many security products and teams work on the long tail of problems and magnify them without proper data. For example, it is well-known that poor identity and access management is the cause of many breaches. It is likely that is the biggest risk in an organization, so there’s no reason to magnify other risks like vulnerability management until that is addressed. The team should be constantly assessing and refining the risks and threat models.

It’s important to set clear roadmaps to address these threat models. This allows the executive team who might not have in-depth security knowledge to understand the health and productivity of the security organization. Tying the programs and threat models to business objectives, it’s an easy way to set expectations rather than using traditional FUD techniques that have been shown not to work.

Finally, responding to an incident properly is extremely important. Many security incidents turn out to be nothing and rarely do breaches happen instantly. They usually take several hours and days to materialize. Specifically, if you look at breach announcements, an attacker lurks around a system for several days or even months before doing anything. Having good detection and response mechanisms can reduce the risk substantially of a security incident turning into a devastating breach. Also, it’s important to practice and set ground rules on how to communicate externally and internally. Bad communication makes a huge difference in customer experience and trust. In other words, being prepared and proactive goes a long way.

Conclusion

Breaches have become a way of life. Preventing them is important, but it’s also important to ensure that your organization addresses the most pressing risks and prepares for one. This new framework is also more suitable for the realities we face today with more complex systems and a more competitive technology landscape.