5 Minute Briefing: Designing for Security Outcomes

This is the first in a set of blogs focused on high level briefings – typically 5 minute reads, covering design patterns and meta trends relating to security architecture and design.

When it comes to cyber security design, there have been numerous ways of attempting to devise the investment profile and allocative efficiency metric.  Should we protect a $10 bike with a $6 lock, if the chance of loss is 10% – that sort of stuff.  I don’t want to tackle the measurement process per-se.

I want to focus upon taking the generic business concept of outcomes, alongside some of the uncertainty that is often associated with complex security and access control investments.

I guess, to start with, a few definitions to get us all on the same page.  Firstly, what are outcomes?  In a simple business context, an outcome is really just a forward looking statement – where do we want go get to?  What do we want to achieve?  In the objective, strategy and tactics model of analysis, it is likely the outcome could fall somewhere in the objective and possibly strategy blocks.

A really basic example of an OST breakdown could be the following:

    • Objective: fit in to my wedding dress by July 1st
    • Strategy: eat less and exercise more
    • Tactic: don’t eat snacks between meals and walk to work

So how does this fit into security?  Well cyber is typically seen as a business cost – with risk management another parallel cost centre, used to manage the implementation of cyber security investment and the subsequent returns – or associated loss reduction.
The end result of traditional information security management, is something resembling a control – essentially a pretty fine grained and repeatable step that can be measured.  Maybe something like “run anti-virus version x or above on all managed desktops”.  
But how does something so linear and pretty abstract in some cases, flow back to the business objectives?  I think in general, it doesn’t (or even can’t) which results in the inertia associated with security investment – the overall security posture is compromised and business investment in those controls is questioned.
The security control could be seen as a tactic – but is often not associated with any strategy or IT objective – and certainly very rarely associated with a business objective.  The business wants to sell widgets, not worry about security controls and quite rightly so.

Improve Security Design

So how are outcomes better than simple controls?  I think there are two aspects to this.  First is about security design and second is about security communications.
If we take the AV control previously described – what is that trying to achieve?  Maybe a more broad brush outcome, is that malware isn’t great and should be avoided.  Why should malware be avoided?  Perhaps metrics can attribute firewall performance reductions of 18% due to malware call home activity, which in turn reduces the ability for the business to uphold a 5 minute response SLA for customer support calls?
Or that 2 recent data breaches, were attributable to a bot net miner browser plug-in, that resulted in 20,000 identity records being leaked at a cost of $120 per record in fines?  
Does a security outcome such as “a 25% reduction in malware activity” result in a more productive, accountable and business understandable work effort?  
It would certainly require multiple different strategies and tactics to make it successful, covering lots of different aspects of people, process and technology.  Perhaps one of the tactics involved is indeed running up to date AV.   I guess the outcome can act as both a modular umbrella and also a future proofed and autonomous way of identifying the most value driven technical control.
Perhaps outcomes really are more about reporting and accountability?

Improve Security Communications

Accountability and communications are often a major weakness of security design and risk management.  IT often doesn’t understand the nuance of certain security requirements – anyone heard of devsecops (secdevops)?
Business understanding is vitally important when it comes to security design and that really is what “security communications” is all about.  I’m not talking about TLS (nerd joke alert), but more about making sure both the business and IT functions not only use a common language, but also work towards common goals. 
Security controls tend to be less effective when seen as checkbox exercises, powered by internal and external audit processes (audit functions tend to exist in areas of market failure, where the equilibrium state of the market results in externalities….but I won’t go there here).
Controls are often abstracted away from business objectives via a risk management layer and can lose their overall effectiveness – and in turn business confidence.  Controls also tend to be implicitly out of date by the time they are designed and certainly when they implemented.
If controls are emphasised less, and security outcomes more – and making sure outcomes are tied more closely with business objectives, an alignment on accountability and in turn investment profiles can be made.


So what are trying to say?  At a high level, try to move away from controls and encourage more goals and outcomes based design when it comes to security.  By leveraging an outcomes based model, procurement and investment decisions can be crystallised and made more accountable.  
The business objectives can be contributed towards and security essentially can become more effective – resulting in fewer data breaches, better returns on investment and greater clarity on where investment should be made.

*** This is a Security Bloggers Network syndicated blog from The Cyber Hut authored by Simon M. Read the original post at: