What We Call Security: Security as Quality (2/7)

We ended our introduction to this series with several questions. Questions I’ve found myself asking over my 25 years working in Information Security. Some of these questions stemmed from others, and some led to more questions, but they did take me to a general conclusion:

The way that we currently practice security, overall, isn’t just ineffective as shown by virtually every statistic. It’s also weird.

We have developed very niche approaches to solving problems in our industry. But if you applied analogous practices in other industries, we would likely leave people scratching their heads at what we were doing. Conversely, other industries have developed and refined approaches that deal with analogous problems very well, yet we reject them as not applicable.

I’ve seen a particular Sun Tzu quote used in several security presentations talking about the importance of threat intelligence, detection, response, logging, monitoring, and a whole host of other security solutions and practices.

Know thy enemy.

Know thy self.

A thousand battles.

A thousand victories.

Most of their narratives highlighted the importance of “know thy enemy”, but in my eyes failed to realise that they were omitting the know thy self part.

In short, I believe we are too quick to focus on the threat actors while we ignore what makes them threatening to begin with: Our own [excessive] vulnerability, or vulnerabilities.

But what is a security vulnerability? You could argue in its simplest form that it’s a defect, a quality defect. A defect in code, in architecture, in a workflow that doesn’t allow maintenance, in a procurement process that brought in something else that had defects, in any business process really. And yes, every IT process, no matter how small, is a business process to some degree.

Would we allow planes to leave the assembly line with known defects that could make them crash, and then leave it up to some “operations centre” to try and detect when these defects start causing dangerous situations, in the hope of stopping the worst-case scenarios?

The“operations centre” may play a role in detecting and trying to mitigate such an issue, but regardless of the outcome we would immediately address it in the design of the aircraft, on the assembly line, the very first time it happened, to make sure the risk is never introduced again.

At the end of most automotive assembly lines there is a person doing quality assurance. Their job is to see if any defects have been introduced in any of the 100+ sequential stations in the assembly line building the car. If they do find a defect, like the steering wheel being mounted off from centre, the car goes back to that station to be fixed. If this defect is significant or occurs more than once, then the time is taken to examine the cause and re-engineer the process at the station where it was first installed to prevent it from happening again.

They do not hire an ever-increasing army of quality assurance people to fix defects at the end of the line, nor would they, if a defect kept recurring, just keep sending every affected car back to the line without addressing the process that caused it to have that defect in the first place.

But these rather common-sense approaches to quality management seem to have largely escaped the field of Information Security. As a result, the more our organisations grow, the more technology we take on, the more security issues result, and the more we constantly need to firefight. I would argue that much of what we have come to call “security” has more in common with firefighting than “securing”.

We are not only failing to learn from what other industries have long ago figured out, but we are also missing out on the economies of scale of putting quality into the build process (of code, systems, architecture, process, etc.) rather than endlessly rectifying things at the end. Plus, we’ve reached a point there the volume of firefighting is so high that we can’t keep up despite forever increasing our investment in “Security”.

Security is incredibly well placed and effective at detecting these quality issues, but we rarely leverage the information to actually fix the processes that cause them.

It’s the reason why both incident and spending numbers keep climbing. It’s the reason we too easily now say “it’s no longer a matter of if but when” when most breaches have been shown to be readily preventable.

You might recall the trends below from this series’ opener.

‍

‍

Too often, security practitioners’ minds focus immediately on “compensating controls” and mitigation efforts without thinking about why they are needed in the first place.

Worse still, just like every other system, the effectiveness of security controls is also dependent on the integrity of dependencies which are often not considered. For example, your IAM service validating your users cannot be trusted if it has acode defect allowing the injection or modification of accounts, or running on a server missing critical patches that allow someone to compromise it and have full control over your IAM setup.

Incidentally, this is the fundamental reason I tell cyber insurance providers doing due diligence to look at the maturity of business processes (something often primarily driven by company culture) rather than the mere presence of security controls. Without good process, the security controls themselves are likely to be ineffective or potentially compromised.

Another rarely considered and counter-intuitive angle: The needed presence of many compensating controls can point to poor business process, and higher risk, in of itself. Why were so many compensating controls needed? Why wasn’t the security built in earlier? What internal issues led to that?

If a car company built a dedicated team of people to find and realign wrongly installed steering wheels at the end of its assembly line, but neither the company nor that team had bothered finding ways to make sure they were mounted correctly in the first place, wouldn’t you have some questions?

Questions about the process, about the company, about the people there?

Wouldn’t we be asking ourselves why they hadn’t focused on the much easier solution of maybe creating a jig or a template when first installing the steering wheels so that all this work at the end wouldn’t be needed? Wouldn’t that be faster, cheaper, and generally more beneficial to the business?

This is my personal definition of strategic security. Asking the questions that lead to approaches and solutions that create long-term reductions in issues and put the business first, rather than building up operational work (with no long-term benefit) to mitigate ever-increasing symptoms of a more fundamental problem.

So, what does this have to do with storage? Or even recovery?

In some ways, not much. In other ways, everything.

This strategy, or philosophy, or common sense, of Security as Quality shape show I and some others approach our roles as CISOs. It’s how we strive to reduce attack surface over time, make sustainable progress rather than firefight, and lower costs. It’s also a way of doing things that offers numerous additional business benefits to our organisations because improving quality improves much more than just security. Storage and recovery play a crucial role here in two ways:

The first reason is simply the security status quo that we usually start with. The common industry practices have created a “way of working” where an organisation’s vulnerability is ever increasing in scale and complexity. To the point that, using present-day security approaches and solutions, that vulnerability can no longer be effectively managed with the means at our disposal. This can be seen by the trends of ever-increasing quantity and scale of breaches despite increased spending on security.

We have created a space where it’s very much a matter of “If, not when.” And while this phrase is technically true, in the same way that an asteroid will likely eventually hit the very spot I’m sitting in as I write this, I fear we’ve cometo use it as an excuse to not do better. Or we’ve just failed to realise there are other ways of approaching the problem.

As a result, recovery has become of paramount importance and grows more important by the day because, as the trends demonstrate, in generalised terms at least, our current approach cannot stop the breaches from coming.

The second reason is however far more compelling to me: Recovery capabilities give us a safety net that can empower us to change things for the better. It can allow us to deprioritise firefighting and instead prioritise a Security as Quality approach that drives lasting improvements.

From a pureRisk Management perspective, recovery allows us to limit the maximum impact of a breach. This means we can (and should, based on risk management logic)reallocate more resource to where it can drive greater change.

We can refocus to reducing how much risk our business processes introduce, driving long-term reductions to how much Security needs to manage, in turn freeing up evermore resource for more proactive work. This exponential growth in our power to affect change is what can turn the tide and make our organisations increasingly invulnerable.

That brings me to the end of this instalment which I hope has fuelled some thoughts on how we can approach security differently. In our next instalment I’d like to share how I structure security programmed and how recovery capabilities give us the freedom to reallocate resource away from reactive efforts towards ones creating long term improvements, all while helping us sleep at night too.

‍

Next article: What We Call Security: Building a Programme (3/7)