CDW Blog

Security Transformation: Part 2 – Root Causes and the Quality Approach

14 November, 2023 / by Greg Van Der Gaast

 

In this series, I want to share my holistic view of cybersecurity, not just as a series of technologies, but a business strategy. 

'Security Transformation' is a move away from 'doing cybersecurity' to 'doing business securely'. 

Put simply, I want organisations to move away from perceiving security as being an IT function - where it has limited impact with regards to business process - to one that allows all parts of the business to work securely.  

Part 1: https://news.uk.cdw.com/cybersecurity-security-transformation

Part 2: https://news.uk.cdw.com/security-transformation-quality-approach

Part 3: https://news.uk.cdw.com/security-strategy

Security as a quality function 

In this article I want to go a little further into the concept of ‘Security Transformation’, or rather, why the shift to security as a quality function, is so important. 

Presenting information security as a quality function rather than a risk function usually leaves most people scratching their heads, due to it not aligning with just about everything they’ve heard about security. 

In fact, the resistance from some security practitioners can be significant. 

In many ways, the quality approach to security is all about improving the quality of everything else (Business and IT processes) so that there’s far less security work to be done in the first place. Therefore, it’s no surprise that it can feel a little counterintuitive, or even a little threatening, to practitioners.  

There’s really no need for it to feel that way. This approach will be beneficial to everyone who cares for the betterment of security. It’s also extremely logical for most executives and other security laymen. 

To get past this resistance, I often resort to analogies where the listener can reach a logical conclusion, and then realise that their situation is analogous and should be treated the same way. 

Addressing the root problem rather than reactive firefighting  

Here’s an analogy I’ve been using since joining CDW: 

Imagine your company builds passenger planes.  

At some point, a technician somewhere realises that the bolts that secure the wings onto the airframes come loose during flight, which will eventually result in a catastrophic disaster.  

Needless to say, this would be extraordinarily bad for business.  

So, what do you do? Well, the obvious solution is to build workshops in every airport in the world and fill them with engineers and specialist equipment to continuously inspect and tighten the bolts after every flight to minimise the risk of a catastrophic incident happening.  

The first time I ran this analogy past a colleague (who does not work in security) I’d barely gotten to “you build workshops in every airport...” when he immediately interrupted me with “No you wouldn’t! That’s stupid!”  

He is, of course, correct.  

What’s far more likely to happen is a close collaboration between all relevant parts of the business to immediately have the design changed so that this defect is eliminated (and then use what was learned in every future design). You’d then retrofit or retire what was out there, and the issue would be solved, for good.  

The latter solution just makes a lot more sense from a risk reduction standpoint, a risk reduction over time standpoint, and a business operational cost standpoint. In other words, it’s the cheapest, fastest, and most effective way of solving the problem for good. And that makes it best for the bottom line too. 

Additionally, we’ll have learned something about fasteners that we can apply to analogous situations in the future, so that such issues are never experienced again. This means no corrective or mitigating action and spend will be needed.  

In security, such an approach would provide continuous and cumulative reductions in vulnerabilities (defects) over time. Meaning fewer vulnerabilities to manage, to mitigate, and to worry about over time. 

The difficulty of effecting change 

Still, the first thought of many security practitioners when encountering such a problem as described above is around increasing the capability and capacity of mitigation systems, rather than fixing the root cause that keeps producing the same issue.  

I’ve had comments from people in security who understood this concept enough to agree with me, but they stated that the problem was that they didn’t “own any of it”, and thus could only rely on the ‘reactive mitigation’ approach. 

That may be true, but I’d argue the aviation field technician likely doesn’t own the design and manufacturing processes either, but the industry manages to sort these problems just fine. 

It’s one reason why I’ve always made it my first task as a CISO to make sure these structures were in place. I feel it’s almost pointless to proceed without them, because if we cannot address the reasons why we are increasingly vulnerable, then not only can we not secure the organisation, but we will incur ever-increasing costs trying to do so. In fact, we may even be indirectly increasing the number of threats we all face. 

A mouse problem....or a grain problem? 

Let me share one more analogy: 

Imagine you are a farmer and as part of your business process you store big canvas bags full of grain on the floor in a shed. One day you wake up to find you have tens of thousands of mice in your shed. 

In the information security equivalent, no security practitioner would be surprised by this. Many would likely sit there holding their heads in their hands, and lament, “I told you this would happen”. 

They would then ask you for budget for ten thousand mousetraps to handle the problem. 

But hold on a minute. Do you have a mouse problem, or a grain storage problem? 

You could argue either, and you wouldn’t be wrong. But what’s the best approach to get out of this situation? 

Is it to set up ten thousand mousetraps, which likely wouldn’t catch a significant proportion of the mice as some would avoid the traps and probably multiply faster than you could catch them anyway? Or to take away the grain that’s drawing them, feeding them, and causing them to multiply? 

That second solution is what we’re typically not doing, and it’s leading us to fuel the population of threat actors coming after our easy grain. No number of traps will deter them; it’s the presence of food (vulnerabilities) that sustains that ecosystem. 

This is one thing that irks me when some security vendors pitch to customers about the ever-increasing threat landscape, because we are somewhat responsible for its growth. 

That is not to say that security tooling is useless, not at all. It has its place and can help. But how these tools are used plays a huge role in the outcomes achieved.  

If we consider that security vulnerabilities are quality defects, then that makes some security tools incredibly powerful at detecting quality defects in your IT and business processes. This enables you to fix them, which greatly benefits both security and business/IT efficiency.  

But a strategic quality-management mindset is needed to use those tools, instead of the operational whack-a-mole method that we are largely using them for today. 

This is exactly what we’ll be covering in our next instalment: how to create security strategies that go beyond the security and IT silo.