Threat Driven Security
“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”
Introduction
Security is fundamentally about mitigating threats. If you are securing the network of a small company with a few employees, working with an engineering team on secure product development practices or evaluating the defenses of a multi national company, the goal is always the same: to efficiently and effectively mitigate threats.
The scale and complexity of many organisations, combined with the wide range of evolving threats that need to be mitigated, clearly means that standardised frameworks are needed to add some structure and consistency to organisational security programs. But, in the midst of our efforts to make security reliable, scalable and repeatable, have we lost sight of the real end goal?
In a recent blog post Anton Chuvakin pointed out that, in practice, not many organisations actually seem to focus on threats. This is an increasingly common perspective. The seemingly endless stream of network breaches and ransomware attacks, many involving companies that have clearly invested a lot of time and money in their internal security programs, is also a clear indication that something is going very wrong.
In this post we will look at threat driven security, specifically: what it is, why it's important and why it often simply never happens.
What is it?
There are two key aspects to threat driven security, the first aspect is neatly defined by the MITRE Engenuity Center for Threat-Informed Defense:
"Threat-informed defense is the systematic application of a deep understanding of adversary tradecraft and technology to improve defenses."
While a deep understanding of our adversaries is clearly valuable, this definition doesn't quite give the complete picture. There is also a much more inward focused perspective of threat driven security. This examines the intrinsic threats that arise from the use of specific products, technologies and controls. It is the view that you tend to see when looking at a system threat model. Contrast the MITRE definition with the following from an earlier paper on threat driven security from Lockheed Martin:
"The conceptual foundation of the threat-driven approach is a model of the relationship between threats, assets and controls."
In some ways these can be seen as different perspectives on the same underlying principles, but it is worth spelling out both of these. This now gives us a working definition of threat driven security:
Threat driven security combines a deep understanding of adversary tradecraft and technology with a deep technical insight into organisational threats, assets and controls to continually refine and enhance an organisation's cybersecurity defenses
Is it really that important?
If you remove all of the threat centric aspects of security then you end up with a pure framework driven approach. This amounts to building a pre-defined set of defenses and operating them in a pre-defined manner. At first glance this might not seem like a bad approach. Frameworks really do help to ensure that complex systems are coherent, consistent and comprehensive, so where is the problem?
The reason this approach will generally fail is simple: our adversaries are highly motivated, technically informed, adaptive and creative people. Relying on a framework centric approach is analogous to defining a single battle plan and just sticking to it regardless of how the adversary behaves. As "no plan survives contact with the enemy" this approach is all but guaranteed to fail.
Standardised security frameworks and architectural patterns are valuable, in many cases they are essentially mandatory. But, without the level of awareness and adaptability that comes from threat driven security, a pure framework driven approach will never be sufficient. The adversaries will simply work around it.
Why isn't everybody doing it?
If you look at any aspect of threat driven security, and drill down into what it actually takes to deliver it, then you continually run into the same road block. It needs a level of technical skill that is still very rare. A recent blog post from Ben Rothke commented on the current information security jobs crisis:
"What there is a shortage of are computer scientists, developers, engineers, and information security professionals who can code, understand technical security architecture, product security and application security specialists, analysts with threat hunting and incident response skills."
The problem is that a deep understanding of technical architecture, application security knowledge and threat hunting, are exactly the technical skill sets that are needed to deliver an effective level of threat driven security. This is where the cybersecurity skills gap really bites.
An additional complexity is that these aren't the kind of skills that are easily picked up, the underlying analytical, critical thinking and problem solving skills take years to develop (and it still isn't clear if everybody can learn these or if it requires some kind of innate ability). This is on top of the kind of deep systems level 'under the hood' knowledge that typically results from years of hands-on experience in a specific technical domain.
Compliance is not security
How do you tell the difference between a pure framework centric security program and one that is threat driven? We have established that one is far more effective than the other, but if there is no way to quantify and communicate this difference, and that difference is simply not visible to customers or board members, then there will never be any real pressure coming from anywhere to change it.
This makes it easy for organisations to effectively 'get stuck' in a situation where their defenses are significantly weaker than expected. From a general governance and compliance perspective the organisation might appear to be getting everything right, but if ransomware gangs seem to be continually walking straight through their defenses then it is quite likely that the root cause is down to a lack of focus on technically effective threat driven security.
How can we get better?
The way forward really comes down to technical skills development. There are process changes that can be made to encourage people to more consistently evaluate and communicate specific threat impacts and needed mitigations but, without the right set of underlying technical skills, any process changes are unlikely to really move the needle.
Technical skills development is obviously a complex area and most organisations develop their own approaches to this, there are some specific approaches that can help here though:
Focus on potential rather than specific task experience. This is a little difficult to articulate but some people have a certain combination of innate technical curiosity and critical thinking skills that naturally leads them to look look at the world through a threat centric lens. Make sure your recruitment and career development processes are able to identify and recognise these skills.
Lower-level technical skills such as coding, reverse engineering, exploit analysis, OS internals, CPU architecture, protocol analysis and vulnerability discovery should be seen as beneficial skills for anybody in a security role. Even if these are not directly applicable to the planned role, this type of deeper technical knowledge can be invaluable when it comes to effectively responding to changing threats.
Think strategically. Everybody wants new hires to hit the ground running as soon as they walk through the door, especially if the current team is already under pressure. But make sure you build the right mix of skills and have at least some people on each team with a more threat centric approach and wider technical experience. Internal mentoring and training can then help to share these skills with the rest of the team.
Calibrating skill levels in a specific technical area can be difficult, make sure you can recognise and encourage high value technical skills in your existing team. In some cases this might mean asking for external help as internal managers and leaders might not always have the right technical skills to do this effectively.
The current tendency of organisations to focus on frameworks rather than threats is not going to go away overnight. In reality I suspect we are in for several years of challenging times as ransomware groups continue to effectively out manoeuvre organisations that are relying on framework centric approaches to security.
Moving towards a threat based approach to security should be a strategic objective for most organisations, but don't expect immediate results. This is fundamentally about building a new technical core competence and, in practice, that always takes time.
