There are two paths we can pursue for our cybersecurity strategy: the control strategy or the resilience strategy.
I created this infographic as a handy reference for the software engineering, platform engineering, and cybersecurity communities, drawing on a table in Chapter 7 of my new book. It’s a great way to validate that the decisions we make when leading cybersecurity programs support resilience rather than control.
The control strategy designs security programs, and the elements within them, based on what security-humans think other humans should do. From this control-centric perspective, what humans “should” do is give their full attention to a task every time; give every risk conscious consideration; notice and comply with every warning; adhere to rules, policies, and procedures 100% of the time; and remain willing to expend all resources toward this compliance (time, cognitive energy, money, etc.).
The control strategy amounts to nothing more than wishful thinking.
The resilience strategy is grounded in reality. It promotes and designs security based on how humans actually behave – the reality of our finite cognition, attention, and energy. The resilience strategy appreciates that security isn’t always the top priority; in fact, most organizations, and the individuals working in them, are constantly calibrating how they balance competing priorities. Our security strategy must respect those priorities and find ways to work with them rather than against them.
Why don’t we see the resilience strategy in action more? As I say in the book, the control strategy is extremely convenient from the security team’s perspective. In fact, it might be better described as the “convenience strategy.” The cybersecurity program can pursue “solutions” that are comparatively easy to implement — like warnings, procedures, policies, training, and even some bolt-on security tools — and that also allow the security program to blame users when an incident occurs.
The security team gains convenience at the expense of everyone else’s inconvenience. As a common example, the security team may force developers to wrangle with slow, cumbersome appsec tools, gaining their own convenience at the expense of developers’ inconvenience. They get to avoid the hard work of brainstorming design-based solutions and instead prescribe fanciful ways people should work, then blame them when they fail to live up to those conceits.
The resilience strategy offers a way forward that transforms security into an enabler and a secure-by-design-er rather than a blocker or “pass the buck”-er. Through this transformation, our strategy respects that humans don’t interact with software or systems to be secure, they interact to perform a task to achieve a goal.
If you want to learn more about the resilience strategy and emerging practice of platform resilience engineering, check out my new book Security Chaos Engineering: Sustaining Resilience in Software and Systems available at Amazon and other major retailers.