What exactly is a threat model, and why organizations should care

1 August 2017

Many organizations are exquisitely aware that they are the target of a wide-range of cyber-attacks: from targeted intrusions to mere vandalism. Financial services companies, defense contractors, critical infrastructure providers are routine and expected targets. However, shifts in how interconnected and dependent organizations are have led to changes in how attackers see the value of a particular target. As mentioned in our previous blog “Keep your Eyes on the Prize”, how valuable an organization is to an attacker is not necessarily aligned with how important an organization sees itself. In order understand better the threats an organization faces; a threat model is typically developed.

Threat modelling is an iterative process that needs to be updated whenever there are substantial changes to either assets or threats. Typically the process consists of:

  1. Defining an organization’s assets - e.g., critical business processes, high-value systems, etc.
  2. Identifying which systems comprise those assets – e.g., databases, Enterprise Resource Planners (ERPs), etc.
  3. Creating a security profile for each system – e.g., which security controls are currently used to protect the identified software applications, such as, firewalls, Endpoint Detection and Response (EDR) systems, web proxies, etc. and which known vulnerabilities are present
  4. Identifying potential threats – e.g., hacktivists, cyber criminals, freelancers, nation states, etc.
  5. Prioritizing potential threats, and documenting adverse events and the actions taken in each case – e.g., working from known examples of documented attacks and internal risk concerns, attempting to foresee what the organizational impact of particular threats could be.

If your organization does any of the following things, you may find the chosen case studies to be helpful in developing your own threat model:

If you build things: if an organization builds devices which have internet connectivity, it needs a Secure Development Lifecycle (SDL).  The Mirai botnet illustrated this point by hijacking internet-connected devices which were not considered to be critical assets. The devices in question had default passwords and were connected to the public internet. Armed with a simple list of passwords, DVR appliances were readily compromised by Mirai and harnessed together to flood targets with up to 1.2Tbps of traffic.

If you make software: widely-deployed or strategically-deployed software are both attractive targets for attackers. Backdooring carefully chosen software allows an attacker to gain access to a particular target. The Nyetna attack showed how a widely-deployed piece of software in a particular geography can become an extremely attractive target for attackers, effectively giving them access to over 400,000 endpoints with a single malicious update. The Havex malware was used in a campaign targeting Industrial Control Systems (ICS) by, among other vectors, backdooring the software installation files for three different ICS vendors. Compromises of this nature allow the attacker to have their malware deployed directly to their targets, most likely bypassing perimeter and other security controls.

If you have an internet presence: attackers are always on the lookout for deniable infrastructure to use in their campaigns. Infrastructure that has a good level of connectivity and a poor security posture is ideal. It is no surprise that attackers such as the Equation Group used cloud hosted virtual machines and university computers to redirect traffic towards their targets. While asset owners may not consider their assets to be particularly sensitive, the value of having a reliable, deniable infrastructure which attackers can freely use for their own purposes is very high. The feasibility and speed of Internet-wide scanning means that vulnerable internet-connected machines do not remain undetected for long.

If you store data: many organizations collect large amounts of data for their own purposes. In particular, data and metadata around how their customers are using their system. This data may well be part of an attacker’s collection requirements. The Equation Group compromise of Eastnets and potentially other SWIFT Service Bureaus shows that, while the organizations may consider security as part of their regular operations, they may face attacks from actors with a significantly higher capability than what they anticipated due to the perceived value of the data that they hold.

Security is a global, pervasive responsibility for all organizations. It is clear that many organizations that did not consider themselves high value targets or with a high degree of responsibility for security may need to reconsider. Paranoia and hysteria are to be avoided, but a sober analysis of the real risks to an organization and, by extension, the other organizations or people it is a dependency for. An understanding attacker goals and security engineering principles, coupled with a robust approach to threat modelling, goes a long way to reducing the uncertainty around risk to an organization.