The threat model as a compass
Article by ThreatQuotient APJC regional director Anthony Stitt.
The purpose of the Cyber Threat Intelligence (CTI) team is to understand the cyber-threat environment and communicate intelligence so the organisation can make better decisions about lowering cyber risk.
Decision stakeholders can be people or systems — therefore the information, and how it is communicated needs to be tailored to each user. It’s important to remember that the CTI team is not just producing intelligence but also conducting another vital job — managing the process of guiding and satisfying a complex range of stakeholder needs. This process should also include assessing each need, defining metrics to measure outcomes, and building feedback loops to ensure things improve over time. Collectively, this set of cyber-intelligence use-cases forms the intelligence requirements (IRs) of the organisation.
Not every stakeholder can articulate their intelligence needs or how to achieve them. Rather, stakeholder requirements will sit on a spectrum from reasonably well-formed to completely unknown. The CTI team needs to guide stakeholders, educate the organisation about what’s possible, and bring new use-cases for consideration.
Doing this effectively requires an understanding of the cyber-threat environment, knowledge of sources of threat data, and strong proficiency in intelligence analysis. It also requires knowledge of the organisation’s systems and the security controls to protect them.
Documenting the intersection of the organisation’s business assets with the threat environment is formally called threat modelling. Threat modelling is an important function in documenting the CTI team’s understanding of threat actors and prioritising them according to their asset risk profile. Most organisations will already have a risk assessment framework in place, which the CTI team can leverage to help in building a threat model.
The threat model helps determine stakeholder requirements, including how the intelligence gets delivered and when and in what format. For example, if an organisation assesses it is at risk from phishing attacks from APT28, its IR should describe how CTI is delivered to its email system and possibly SIEM.
The threat model will also influence the sources of threat information required to meet the stakeholder needs because information about different adversaries will come from different sources. Finally, a threat model will highlight where the organisation has protection gaps or visibility gaps from the threats and adversaries relevant to the business.
One way to think about the relationship between threat modelling and intelligence requirements is like a compass. North is adversaries, south is business assets, west is intelligence inputs, and east is intelligence outputs.
Therefore, the east-west axis is intelligence requirements, while the north-south axis is the threat model. The threats a business faces are intrinsic to its mission, where it is based and how it operates.
No organisation is at risk to every threat, and organisations change regularly, which changes the threats; the threat environment changes as new adversaries appear, morph and disappear. Businesses acquire other businesses in new markets and geographies; they change how they accomplish their goals, they may migrate to the cloud or enable employees to work remotely.
All of these business decisions change the threats and assets of the business. Just like a compass, regularly reviewing the threat model keeps the CTI teams IR’s pointed in the right direction over time.
So how is it that most organisations can survive without a documented threat model? For these organisations, the threat model is implied by their choice of security tools and systems. The assets side of the threat model is implied by the type of security tools and where they are deployed. The threats side is implied by the types of attacks the tools are designed to mitigate together with any threat intelligence downloaded from the vendor’s threat research team to keep the tools up-to-date.
However, increasing cost of breaches and lengthening attacker dwell times point to one compelling reality: traditional security approaches do not detect every attack in a reasonable timeframe. There are practical limits to centralised vendor intelligence ecosystems regarding the number of IoCs that can be pushed to devices, the speed of disseminating intelligence, and the specificity of intelligence.
For these reasons, organisations bolster their threat visibility by gathering threat intelligence from external sources. External threat intelligence is designed for a wide audience, and so it is provided with contextual information to help an organisation determine its relevance for them.
Threat modelling helps filter the intelligence based on the organisation’s geography, industry, type of intelligence, the adversary, the TTP’s used, the vulnerability targeted, etc.
This is where a threat intelligence platform comes in. Implementing a threat model across a range of threat intelligence sources is virtually impossible unless it is automated. A good threat intelligence platform will also provide a place to document IR’s, automate how they run, and track the metrics needed to measure each IR.
Buying an external threat feed and sending the data directly to the SIEM is how many organisations start with threat intelligence. However, most quickly discover that there are hundreds of interesting sources of intelligence.
It’s not feasible to send all of this to the SIEM. The false positives alone will drive the SOC team mad. Making sense of it all requires a threat model and a set of IR’s to work against.