Post 2

In our last article we talked about how, in mature industries like aviation, there was a tremendous focus on Quality Management. In particular, a focus on addressing root causes of a problem so that they stop producing issues and risks.

These causes can include business processes, policy, manufacturing, training, material procurement, maintenance processes, even company culture.

We know that addressing root causes is a more effective and sustainable approach to reducing risk over time. While this approach is rarely prioritised in security, most practitioners will eventually agree that it makes more sense. That, as one practitioner recently put it to me, not doing effectively had them playing "whack-a-mole" for the past decade.

And yet, getting security functions to actually adopt this approach is difficult for two main reasons:

1. The first is that they don't want to lose job security. This is a major cultural issue within the security function. One that is unfortunately not rare due to the lack of understanding, and therefore accountability, of the security function by the business. We won't be discussing this today, and it's one we can't resolve unless we are engaged at the utmost levels of the organisation.

2. The second problem, which we will go into depth on now, is faced even by those functions who truly want to help the organisation: the fact that they do not "own" the other departments where the problems are originating.

How can you fix a problem that you have no control over? You can't. And thus many altruistic security functions have no choice but to firefight the issues created elsewhere in the business to protect it as best they can.

And this is the number one reason I am given as to why security teams do not tackle root causes proactively. I always find it fascinating because when I ask them to explain their situation and pain points they often state this issue. In other words, they have identified the problem... but then immediately give up on it and try to buy some more tech or hire some more bodies to mitigate the resulting problems.

But let's go back to our aircraft manufacturer analogy from our last article, shall we?

A technician finds an issue with the bolts securing the wings in place on our new plane, kicking off a whole flurry of activity all over the place. Management teams are notified, resources are made available, forensic reviews are had, designs are modified, assembly lines are changed, engineering practices are updated.

Did the technician "own" any of these departments or processes? They did not, and yet all these things happened. They happened because an understanding that the total cost of operationally managing such issues (building loads of workshops and forever re-torquing bolts) is not just financially inefficient, but also an ineffective way of reducing risk. And thus, a structure exists that allows changes to happen far upstream from where the issue was found, ensuring all areas that might have caused the issue, and all areas involved in its rectification, can be called upon to do so.

Because it has the best outcome for the business.

We all know this approach would have a better outcome for the business when it comes to security too. And it's why we feel that establishing such a structure is one of the first things a CISO should do. Operating without it is virtually guaranteed to cause a tremendous waste of resource managing issues for years to come which could have been eliminated much earlier at a fraction of the cost.

Unfortunately, we find many CISOs lacking the position or arguments to get such structures agreed to and implemented. One of those reasons is a disconnect from business arguments and logic, engagement skills, and a tendency to look at costs from a risk perspective rather than from that of a business' bottom line.

And that's exactly what we'll discuss in our next instalment.

As always, please follow us to stay up to date, and don't hesitate to get in touch if you recognise these issues in your organisation.