A few weeks ago, I overheard a security leader comment to a group of business peers about how his team were battling “the breach of the week”. I’m sure it wasn’t intentional, but he managed to come across as both flippant and defeatist at the same time. It wasn’t a good look, coming from the person responsible for running the security programme.
I work with security leaders every day in my role. All the security leaders I know personally are conscientious and want to do the right thing, for their organisations and for their people. But I also work with security practitioners in the trenches every day too, and their view of the organisation’s security state is often very different to that of their leaders. Sometimes the two are on completely different planets.
Here’s an example: I once performed a security assessment for a large, well-known organisation. The assessment showed that they were highly vulnerable to commodity identity attacks, because they did not use multi-factor authentication. The rank-and-file in the security organisation had warned about this for years. But when I mentioned this risk to the CSO and the other senior security leaders, they all looked at one another and said, “I thought we did that already?”
Now imagine you’re one of the security practitioners in this organisation. You are tasked with putting the organisation back together again, after a breach caused by the compromise of a privileged account that wasn’t protected by MFA. What would you think, if you overheard this conversation? Probably something like, “Why am I working so hard for leaders that don’t listen, and have no idea what’s actually happening on the ground?”
Unfortunately (or fortunately, depending on your perspective), nothing brings this disparity into focus like a breach. One of the weighty responsibilities of security leadership is this: if you are responsible for budget, strategy, and/or prioritization, and your organisation gets owned by something for which it absolutely could have and should have been prepared, then that buck stops with you.
That’s why breaches (ideally those that happen to others first) are such a great opportunity for leaders to self-reflect. Honest self-reflection is not just helpful for prioritizing your longer-term recovery plan, but for setting the right tone with your own people, who are looking to you for guidance and inspiration. They will shoulder the burden of implementing the recovery plan, after all.
So here are 3 challenging (but fair) questions that all security leaders should ask themselves, after a breach:
#1: What role did I play in this incident/breach?
It’s one thing to accept that breaches are inevitable. They are, and accepting that fact prepares organisations to respond and recover from them more effectively.
It’s quite another to expect people to continually rescue the business from breaches that were preventable. And according to an OTA study from a few years back, 93% of breaches are.
We talk a lot about burnout in the industry, that people often feel a sense of futility about their roles/impact. But I am increasingly convinced that it is not the futility of a never-ending wave of cyber attacks…it’s the futility of working for an organisation that does not have the political will to do more than shuffle the chairs every year or so.
Security folks can accept that there is an endless stream of people on the internet who will never stop trying to hack their organisation. It’s part of what makes the job interesting and engaging, actually.
They have a harder time accepting that their own leaders seem unwilling to address the tooling fiefdoms, organisational silos, and turf wars that undermine their own org’s transformation into something more effective.
And so they leave, because they realize that they are running on a hamster wheel of the organisation’s own creation. The organisation could be better prepared, but it isn’t, and there’s little evidence to suggest that this will change. The cognitive dissonance becomes exhausting.
Things to consider, as you reflect on this question:
- Your security team are investing their most precious resource into your organisation: their own blood, sweat, and tears. What do you think they would say, if you asked them if they were getting a good return on that investment?
- Are the priorities I’m setting, and our investment strategy, aligned to the risks and opportunities that matter most? For example, if the engineering team are buying (yet another) security tool, but MFA is not enforced for every user, then the answer is no.
- For the areas of greatest risk, do I know for certain what is really happening on the ground?
- Did my (in)action in a key area contribute to the conditions that allowed this attack to succeed?
- Do we do the security basics well, in every area where sensitive/critical/impactful assets are at risk?
- Can I drive change top-down in my organisation, when it’s warranted? If not, why not? And what am I going to do about it?
#2: Do I require root cause analysis, and do I create the space and time for people to do it?
I get that resource-constrained security organisations simply cannot commit to open-ended root cause analysis, every time there’s an incident or breach. But root cause analysis doesn’t need to be a drawn-out forensics exercise; it isn’t usually a mystery how a breach occurred, and that’s the only starting point you need.
Now use the “5 Hows” technique (a parallel technique to “5 Whys”, developed by Toyota), to quickly decompose the issue to the root cause, and formulate solutions.
Note: “Why” and “How” are subtly different questions and will lead you down different paths. From a security breach perspective, “why did this happen?” is probably less important and actionable than “how did this happen?”, since the focus is more on how to prevent the breach re-occurring.
Now you have a root cause to investigate and remediate. Without an approach like this, it’s too easy to get sidetracked/stuck on one of the intermediary (but not root) issues.
The process inevitably flushes out other important questions too, such as: Why wasn’t the data exfiltration detected? Why wasn’t MFA enabled on the admin account? Why was the admin using a normal productivity laptop, instead of a dedicated, hardened admin device?
The point is, the rigour and structure of the process is the key, not the tool. This is true for similar processes, like threat modelling.
But it’s up to you, as a security leader, to prioritize the process. That means setting the expectation that: 1.) it is not optional, and 2.) the incident response team are empowered to carve out the time needed to perform the analysis. This need not take any more than a few hours, but it helps to create much more focused output, with clear cause-and-effect lineage.
The challenge of course is that as soon as an incident has been addressed, the incident response resources (which are almost always a v-team, not dedicated resources) need to get back to their “day jobs”. But the only way to discover and address the real reasons why these events occur is to perform this kind of analysis, and your security folks can’t create the mandate for this on their own—they’re looking to you for that.
#3: Can people really be honest with me, about the findings?
You don’t have to spend a long time with a technique like 5 Whys/5 Hows to discover something interesting: problems often have both operational and systemic causes.
But even the operational causes inevitably spin-off “why” questions. The explanations for “why” questions are often more cultural in nature than technical/operational, and can hint at deeper underlying systemic issues—if you’re brave enough to look at them.
And that last bit is really important, because let’s face it: the people that have been at the company for a while already know all about the underlying cultural/systemic issues that contribute to (if not directly cause) the operational issues you’re experiencing. They just might not feel like they can bring them up.
While insecure leaders insulate themselves from criticism, and surround themselves with people that don’t ask hard questions, you’re better than that. You want your people to be able to share the unvarnished truth about why a breach has occurred, and how to prevent it from reoccurring—even if it’s unflattering.
So how are you doing in this area, as a leader? Here are some questions to ask yourself:
- Are the people performing the post-breach analysis actively encouraged to provide unvarnished feedback, about both the operational and systemic root causes?
- Do you have a culture where it’s safe to make messes? Or is it a finger-pointing culture, where people are punished for making mistakes?
- Is it safe to ask hard questions? Do people openly address the elephant in the room, or does everyone ignore it and pretend it isn’t there? Is it costly to disagree (emotionally and/or professionally)? If so, then you can talk about an “open door” policy all you want…people will still hide the truth from you.
- Are you “confrontable”? Or do you only accept constructive criticism from those above you?