At Cortex Insight, we have long believed that using Threat Based Vulnerability Management in order to move away from the overly simplistic approach of setting a risk bar and fixing issues that are above that bar, is the way forward.
In this current environment the one size fits all approach does not scale, nor does it account for the needs of systems and applications with specialised security requirements.
This bar approach may have been okay in the past when risk registers where ‘small’ and businesses had just a handful of systems and applications to worry about. The modern landscape is far more complex and with the current regulatory landscape, you have more than just a few systems or apps to care about.
In an ideal world you would have an individual ‘risk profile’ for every system and application, an individual bar that would determine what gets fixed and when due to the nature of the entity in question. It allows you to customise this bar to address what issues are really important for the entity and maintain an appropriate security posture without sacrificing anything. However, there is one problem with this, it gets really complicated very quickly when you have many entities to manage.
In the past this was a problem, the volume of ‘paperwork’ to implement this approach would cripple even the largest of security teams. However, now we have automation and vulnerability management systems that could allow the approach to scale.
So how does Threat Based Vulnerability management fit into this? Generating a individual ‘risk profile’ is all about context, you need to understand the risk appetite for a given entity so you can tailor the management of vulnerabilities.
When you move away from a fixed ‘severity’ or ‘risk rating’ based bar you need a way to choose what to fix. This basically means having some context about the entity to help choose what to fix.
This is where having a list of threats comes into play, attack based threats such as those developed using the STRIDE threat model can be seen as attacks or outcomes you do not want to see, these are the bad things that you care about.
These threats can be used to provide a context filter on vulnerabilities that have been identified for an entity and as a result any vulnerability that in essence is present makes that threat/outcome a reality and thus should be addressed.
To aid the process these threats would be ranked according to your own needs and risk appetite. When applied as a filter any vulnerability that it mapped to a threat would be addressed based on the ranking of the threat.
To develop a per entity ‘risk profile’ information is key, we use Threat Modelling to develop threats that are used to provide the context, however the process to develop the threats needs information to be able to make an informed decision.
Our approach takes two types of information and analyses it to help develop context.
The first element of the approach it to collect functional requirements for the entity. These are the requirements that describe what it is the entity will do.
Functional requirements can be anything, from describing how a particular business process may work to how a user will change their profile picture. We are basically describing what the entity will do.
The second element require for developing the threat list is non-functional security requirements. These coming in various forms such as:
- PCI DSS 3.2.x
- NIST (So many Standards to name)
Just to name a few, but there are other requirements that may be specific to particular industries and regulators.
The great thing about standardised requirements they are typically easily mapped to threats. This is because in essence they are designed to address certain threats.
As a result, we map these requirements to known threats to be used within threat modelling.
The threat list becomes an important element of the process, as a result an approach is needed to develop the threat list. It turns out Threat Modelling can be an excellent way to in essence choose what threats could be relevant.
Of the threat modelling approaches those that produce an attack focused list of threats work best, however any approach that allows you to develop a list of outcomes that you would not want to see will work.
For example, the STRIDE threat modelling approach will develop a list of threats categorised by
- Information Disclosure
- Denial of Service
- Escalation of Privilege
These do not cover every eventuality however they provide an excellent starting point for threats and will allow you to map any threat developed to vulnerabilities pretty easily.
Typically with each of the threats developed using STRIDE threat modelling it is possible to link it to a category of vulnerability or to specific individual vulnerabilities.
For example, when using the Microsoft STRIDE threat modelling toolset one of the threats suggested relates to ‘Persistent Cross-Site Scripting’ this can easily be linked to vulnerabilities in the Mitre CWE taxonomy of application vulnerabilities and from there to identified web application vulnerabilities from testing your own applications to known vulnerabilities from the CVE library as these too can be categorised.
As a result, should your threat model identify the ‘Cross-Site Scripting’ threat, you can easily map any identified Cross-Site Scripting vulnerabilities to the threat and then based on the priority assigned to the threat remediate accordingly.
Using the Threat Model Output
As well as being used for the remediation process, it is actually possible to use the threat model output before a single system has been built or a line of code written.
Threats can be used to influence elements of the entities design.
Controls can be developed and implemented, steps can be taken to in essence remediate issues before they become a problem. By implementing specific countermeasures for the identified threats.
For example, implementing specific code syntax or API calls to mitigate Cross-Site Scripting at the code level. Selecting appropriate technologies to enable to construction of a secure system, for example selecting a ORM Framework to handle interactions with Databases.
All of which are technical or logical controls to address issues before they occur, or implementing process based controls such as using a ‘Four Eyes Verification’ approach where actions would be verified by a second party.
Controls that have been identified, developed and implemented can then be recorded against the threats they counter and be used to adjust the filter when it comes to vulnerability management.
Some controls may not completely eliminate a threat but reduce the effects, thus resulting in some residual risk. Thus, vulnerabilities that could be mapped to the threat would still be left for remediation, however their priority may be reduced as there would be controls in place that are mitigating some of the risk.
The Cortex Insight Platform
We developed the Cortex Insight Platform to enable the use of this threat based approach to vulnerability management. Within the platform you are directed through a process of information collection to develop a threat mode.
The resulting threat list is then mapped to vulnerabilities that have been consolidated within the platform and from there is it possible to show a list of vulnerabilities to be remediate using the threat list as a filter.
Controls and mitigation’s can be recorded to allow the prioritisation to account for when something else is in place to act in defence of a threat or vulnerability.
The prioritised list is adjusted to ensure that threat mapped vulnerabilities without control protection are handled before those with a control.