Resilience in Security 101

This post highlights the key things you need to know about what resilience means in an information security context. It’s intended to serve as a 101 for people involved in building, maintaining, and securing systems.

It’s also meant to serve as an antidote for the recent twisting of the term by self-serving vendors and #thotleaders who are blisteringly unaware of the decades of research outside of infosec on the topic.

tl;dr – Resilience in security means a flexible system that can absorb an attack and reorganize around the threat.

The basics of resilience in infosec

Resilience in information security (and in other domains) consists of three characteristics: robustness, adaptability, and transformability.¹

Robustness = withstanding and resisting a negative event. Think of this as your systems’ ability to prevent or block pwnage.

Adaptability = managing your current systems’ response to negative events. Think of this as minimizing event impact in your systems, optimizing for system recovery, and minimizing friction involved in changing your systems.

Transformability = reorganizing your system in response to updated assumptions. Think of this as moving to a new system configuration or trajectory when existing conditions are indefensible.

Once more, but less abstractly

Let’s walk through a brief practical example to show how each of these characteristics of resilience work together.

Your organization delivers a PHP application to customers. You use inline PHP code within the HTML of your web apps to perform database queries. An injection vulnerability is found in an instance of this inline PHP code.

Robustness manifests as implementation of a web application firewall to stop exploitation of the vuln, along with patching that instance of the vuln. These actions return things to “normal” – the prevailing status quo before discovery of the vuln (the negative event).

Adaptability manifests as removing inline queries from the application, then replacing them with one class that accesses the database and is responsible for all sanitization. This reduces potential incident impact and, by only requiring issues to be fixed in one place, minimizes friction involved in changing the system going forward.

Transformability manifests as re-architecting the application in a different language, like Java, to solve PHP’s endemic security problems. Evidence from application monitoring or publicly-disclosed vulnerabilities in PHP leads to updated assumptions about PHP’s suitability for the application. These assumptions motivate revision of previous choices that result in reorganization of the system to optimize for the evolving reality.

Piecing it together, these activities result in a more flexibly-designed application that can absorb an attack and be reorganized based on its evolving threat context.

What most of the industry gets wrong

1. Robustness does not equal resilience. Robustness is insufficient on its own to foster resilience. Prevention is not resilience. Prevention is insufficient on its own to foster resilience. Being able to block or withstand an attack is not resilience. Being able to block or withstand an attack is insufficient on its own to foster resilience.

   I am spelling this out as plainly as I can because I see this misconception all the time now. Resilience is being used as a substitution for robustness, prevention, and “stopping threats” by marketing teams to make their stale pitches feel fresh again. Don’t be bamboozled by these misleading claims.

   If you want to understand more why this is such a dangerous conflation, read the Robustness section in my keynote on resilience.

2. Resilience is not a tech stack or set of tools. Given people still think DevOps is achieved by implementing a certain tech stack, I don’t hold much faith that people will let go of similar notions about resilience. Just like DevOps, resilience is a set of principles and practices. It’s an approach that aims to help you evolve your security as your environment and context evolves.

   Certain tools can support your resilience practices – such as transformability via migrating systems from on-prem to the cloud – but you will not be able to “do resilience” just by purchasing tech.

In Conclusion

I’ll repeat my definition again: Resilience in security means a flexible system that can absorb an attack and reorganize around the threat.

I firmly believe resilience is the future of information security. Alas, the term is actively being bastardized by some vendors to serve their pestilent purposes. To the practitioners reading (whether you build systems or secure systems), remember that attackers are continuously evolving their methods based on changing context, and it is imperative for you to evolve your methods, too.

Adopting a resilience approach will help you survive – and hopefully even thrive – in this dynamic digital world of ours.

Thanks to my engineering and security friends for their feedback on drafts, especially Camille, James, and Vladimir!