The Threat Modeling Framework describes activities & components needed to perform threat modeling in a structured and systematic manner, from external factors influencing a threat model to the core threats and security requirements.
It is an answer to problems with threat modeling: threat modeling is overly complex with too much jargon.
Image 1: Threat Modeling Framework overview.
Overview of the Threat Modeling Framework
The following paragraphs explains the overview sections of the framework.
Goals
The Threat Modeling Framework strives for:
- A structured step-by-step approach
- Ease of use within an enterprise environment
- Align & integrate with existing architecture, development, and security processes that an enterprise environment already has
- Usage within any stage of the development lifecycle
Inputs into the Framework
Regulatory requirements, security policies, threat intelligence, and threat actors are input into the threat modeling framework. These can vary depending on the industry, geography, and business.
Exposure
The application (in the scope of threat modeling) will have external and internal exposure. This exposure should be identified.
Features
The features and use cases of the application will impact threats (which can be identified via abuse cases).
Applications, Platforms & Infrastructure
The type of application, the underlying platform(s), and the infrastructure will impact the threats and security requirements.
Core High-Level & Detailed Threats and Security Requirements
The threats and security requirements are the main ingredient of the threat model, and thus the threat modeling framework.
Authors of the Threat Modeling Framework
Nick Kirtley and Tejvir Singh (founders of Aristiun) developed the Threat Modeling Framework.
Overview of Threats and Security Requirements
Identity & Access Management
Threats related to gaining unauthorized access to system(s) or data, or performing unauthorized actions.
| Threat | Security Requirement |
|---|---|
| Unauthorized access is gained from a compromised password | Use Multi-Factor Authentication (MFA) when accessing all parts of the system |
| Unauthorized access is gained from compromised credentials | Use Single-Sign-On (SSO) where possible |
| Privileged access is gained through abusing complicated access rights | Use Role Based Access Control (RBAC), with a clear overview of roles, the rights per role, and the users assigned to roles |
| Users who should no longer have access gain unauthorized access to the system using existing rights | Performing periodic access reviews for all users, administrators, and highly privileged users |
| Unauthorized (and privileged) access is gained by abusing NPAs or system accounts | Manage Non-Personal Accounts (NPAs), High-Privileged Accounts and Service Accounts effectively |
| Users abuse access rights that are not required | Use of the least privilege principle, meaning that users only have access rights that are absolutely needed |
| Users abuse sensitive functions and access rights | Use of Segregation of Duties (SoD) for privileged or highly-sensitive actions & activities |
Encryption
Threats related to insecure development processes and tooling.
| Threat | Security Requirement |
|---|---|
| Abuse of vulnerabilities & weaknesses (originating from the code base) | Use code scanning tooling for newly developed or committed code |
| Malicious code is added to the code base by an insider | Use of the four eyes principle for newly committed code |
| The system is abused via dependencies or libraries | Using trusted and secured dependencies, frameworks, and libraries only, and scanning them for known vulnerabilities |
| Vulnerabilities or weaknesses are abused | Performing pentesting for newly developed applications or upon major changes |
Hardening
Threats related to exploiting (configuration) weaknesses in system(s).
| Threat | Security Requirement |
|---|---|
| Misconfigurations are abused for unauthorized access or disruption | Hardening of (all) technical components of the system |
| Unnecessary services, pages, or ports are abused | Removing unnecessary services that are provided by default, or enabled during development |
| Sensitive pages or services are accessed externally | Reducing the exposure of services, web pages, administrator panels |
| Outdated software with vulnerabilities is abused | Applying security patches to technical components of the system |
| Exposed secrets or tokens are used for abuse or access | Securely manage secrets, tokens, etc. in a vault or similar technology |
| Production data is lost in the development or testing phase | Use of DTAP (Development, Test, Acceptance, and Production) |
Network Security
Threats related to gaining unauthorized network access to (parts of) system(s) or data.
| Threat | Security Requirement |
|---|---|
| Critical technical components are abused from external networks | Segmenting internal parts of the solution (i.e., segmenting components at the network level) |
| Services and ports are maliciously accessed from external networks | Using a firewall between trusted and untrusted zones |
Security Logging, Monitoring & Response
Threats related to abuse that go undetected or not identified & remediated.
| Threat | Security Requirement |
|---|---|
| Security events at the infrastructure level are not identified | Logging of technical events occurring at the infrastructure level |
| Security events at application level are not identified | Logging of important events occurring at the application level |
| Security events are not analyzed by security professionals | Triggering active monitoring of critical events at the infrastructure and application level |
| Security events are not resolved by security professionals or SOC | Response measures by the SOC or other security professionals in case of critical events |
Backup, Availability & Continuity
Threats related to disrupting the availability of system(s) or data.
| Threat | Security Requirement |
|---|---|
| Data is lost in case of a cyber event or attack | Performing periodic backups of systems and data |
| Data is lost in case of a ransomware attack | Performing air-gapped backups of systems and data for use in a ransomware attack |
| Systems or data cannot be recovered in case of a cyber attack | Performing regular recovery tests using backup data |
| Processes cannot recover in case of a cyber attack | Performing regular business continuity sessions to recover from a (simulated) attack or outage |
| Systems are down due to loss of a single point of failure | Develop redundancy of systems and processes for systems with high availability requirements |
Secure Development
Threats related to insecure development processes and tooling.
| Threat | Security Requirement |
|---|---|
| Abuse of vulnerabilities & weaknesses (originating from the code base) | Use code scanning tooling for newly developed or committed code |
| Malicious code is added to the code base by an insider | Use of the four eyes principle for newly committed code |
| The system is abused via dependencies or libraries | Using trusted and secured dependencies, frameworks, and libraries only, and scanning them for known vulnerabilities |
| Vulnerabilities or weaknesses are abused | Performing pentesting for newly developed applications or upon major changes |
