You will recall from Part 1 and Part 2 that I bemoaned the flagellation of the security tools industry for failures in security and therefore the occurrence of breaches.
The real question is: given there is a problem here, what should we do about it. If security tooling is not the answer, what is? Well, like most solutions, I see it as a mix of different points depending on any particular situations and company.
Disdain for Process – Since the widespread use of agile methods and public cloud technology, there has been a general abandonment and disdain for process. I suspect this is largely I think this might be behind some of the issues. No thought (and therefore application of process) is required, because if we mess-up, we can just pivot/hit reverse etc. While that works for general technology issues, it doesn’t work so well in the security domain – because if you’ve been subject to a breach – you can’t reverse out of that.
Valuing Thought – Increasingly I see action being mistaken for progress. Working through a design, doing security risk assessments developing the risk treatments and making sure there is assurance of their application all takes time. Leaders nod like donkeys when we talk about getting the need to reduce time to market and the need to bake in security, but this is all very component driven.
The Whole is Greater than the Sum of the Parts – The push for widespread use of secure design patterns and templated secure builds, is all good, but misses the point. Each of these points are akin to secure modelling blocks (you should think of the famous plastic block made in Denmark here!) Each of these building blocks is secure, but it doesn’t necessarily guarantee you a secure outcome (just that its probably more secure than if you had developed your own building blocks).
So, where next?
I’ve seen a little noise on LinkedIn from notable folk in the cyber community about people who can only configure tools as being one-trick ponies. I think that mindset needs to become more widespread. Its why I far value people with architecture exposure and certifications such as SABSA (and to a much lesser extent – TOGAF) over vendor certifications.
