css templates

How much security is enough?
How do I show I am delivering security not just performing security activities?

Mobirise

Security verification is the term for showing that security controls are performing as they should be. Security validation is the term for showing that those security controls are actually delivering the desired amount of security protection.

Security verification is what most assessments and straightforward metrics provide. They serve to answer a wide range of questions such as:

  • Are risk assessments being carried out when they should be?
  • Are security designs reviewed and signed-off by the accountable risk owner?
  • Are security functions correctly implemented?
  • Is (name your security solution) installed everywhere and being managed properly?
  • Am I logging activity data from all of my end-points?
  • Do I have a tested incident response plan and up-to-date contact details?

Security verification serves as a proxy for security validation. This works on the premise that if security controls are being applied, operated and managed to the standard required then one can presume they are providing security to the level desired. In the absence of scientific security methodologies and tools, this is about as much as one can do. There is still room for qualitative judgment based on experience and common sense, but no objective way to tell if a security system is over-engineered or under-engineered other than by waiting for it to fail.

To move beyond security verification to doing some, even if not full, security validation requires a conceptual understanding of how security controls provide security protection. This is more than just saying something like

Risk = Threat x Vulnerability – Controls

To do security validation requires a suitable paradigm, one that describes how the dynamics between threats, vulnerabilities and controls work, and that provides a framework for the use of stochastic methods to analyse those dynamics. (Analysts have tried using deterministic methods for decades and they simply do not cut the mustard. The processes by which risk is generated are fundamentally stochastic and the only proper way to analyse them is using stochastic methods.)

That is what TBSE brings to the table. However, as before, ‘Perfect’ can be the enemy of ‘Good’ here too. You don’t need to take on the full weight of something like TBSE in order to start your journey beyond verification. Firstly, it will take decades before people are in a position to use scientific methods like that across the entirety of their security landscape to come up with a single total for overall risk. And secondly, almost nobody today needs the level of mathematical precision a fully stochastic analysis would provide.

Instead, choose one place within your security landscape where you want to begin, and then start with elementary modelling to understand the risk dynamics in play there. Walk before you run. Elementary modelling is relatively easy and provides early benefits, and you can increase sophistication and range as the need takes you.

Over the past few years, I have helped clients start their beyond-verification journey in a number of different parts of the security landscape: Resistance to malware; Resistance to Phishing; Staff security awareness; End-user password strength; Perimeter resistance to intrusion attacks; Software vulnerability removal; DDoS protection; and a few others.

There is a great subject here for further discussion. If you would like to talk about any aspect of this in more detail, please get in touch. Email me at john.leach@jlis.co.uk or call 07734 311567 (+44 7734 311567).

© Copyright 2020 JLIS Ltd