You’ll recall my observation from Part 1 that increasingly tools are being used in place of thought and rigour. Its worth setting out what I mean by thought and rigour in the context of this issue, so briefly this is how I define it (constrained by a desire for brevity).

Lack of understanding of context: There is a reason that the SABSA Architecture Matrix shows the top row as the Contextual Architecture. Without understanding the context of the requirement (or perhaps – utilising a different context incorrectly – you can spot this with “In my last place, we did..xyz”)

Lack of thought in design: A mindset problem of security being an annoying ‘non-functional’ requirement. The failure to think hard about the security aspects of the application, platform or ecosystem and what it requires to be secure. This may or may not be facilitated by agile methods where, in my experience, it is easy to lose track of the bigger picture because of the micro focus in certain areas.

Lack of rigour in implementation: This has been written about for years, but the basic problem of focus on features that make money to the detriment of others that provide a security aspect. An example might be the ability to exploit a Separation of Duties issue, or the ability to infer data in an unintended way. This is far beyond the usual stuff of ‘run our chosen AV agent on your servers’. But it might also extend to the planning for application level logs being monitored for business specific events, then alerting on potentially suspicious activity. Which leads to the next problem…

Lack of connectedness in assurance: The joining-up between the outcomes of implementation – the application code, the infrastructure it runs on, with the stated intentions of the requirements and design. This includes the orthogonal aspects of security which should also be tested – both at a functional level (does the Separation of Duties concern exist?) and non-functional (are you running a hardened server/container etc?).

The question is: why?

Which brings me to my starting point back in Part 1. The reason that tools are failing and being blamed is because they are being used as a crutch for the lack of thought, poor decisions and activities of others. More certainly that they are not being used as part of a layered defence mechanism. There are associated issues of disconnection to ‘the business’I loathe that phrase but use it because of its widespread understanding. This issue extends to offshoring, resourcing strategies, longevity of service as well as they other more technical issues discussed above.

But what to do?

That’s the harder part and I think like most things its cultural – culture eats strategy for breakfast (Drucker). That is the subject of Part 3