Threat modeling can often feel complex and confusing for security professionals who are new to it. Further, it can feel extra complex to developers, management, and other important stakeholders with limited security experience.

So what are the factors that make threat modeling seem complex:

• It’s a broad term that can include many different solutions and practices. There’s no single or one way of performing threat modeling. Some threat modeling practitioners only include a simple high-level data flow diagram, and outline a few threats defined in a single session. Other threat modeling practitioners use complex frameworks and tooling, have multiple sessions, and use many & formal security requirements.
• There are many threat modeling methodologies & frameworks such as STRIDE, PASTA, LINDDUN, attack trees, and more. Each one is different and has a very different approach to threat modeling. Even the use of STRIDE (probably the most well-known threat modeling methodology) varies from professional to professional.
• The various threat modeling methodologies & frameworks introduce complex terminology. This terminology can alienate some stakeholders.
• Threat modeling is only known and practiced by a small group of security professionals (like a niche within the security niche). Most security professionals don’t know the details of threat modeling, let alone the wider IT and business community.
• There are new requirements within regulations and legislation to perform threat modeling for secure products and services, these regulations have limited (official) definitions clarifying exactly what threat modeling is and is not.
• There are many threat modeling tools available, and the approaches taken by the tools vary significantly.

So we’ve established that threat modeling can seem complex to new practitioners and why this is the case. What can we do about it, and how can we simplify threat modeling?

We can align threat modeling with more traditional security practices, and remove unnecessary jargon & practices. Our threat modeling framework does just that!

Simplify Threat Modeling with Recognizable Topics and Security Requirements

The first step in simplifying threat modeling is categorizing threats and security requirements (or countermeasures) into understandable & recognizable topics. The topics consist of:

• Identity & Access Management
• Encryption
• Hardening
• Network Security
• Security Logging, Monitoring & Response
• Backup, Availability & Continuity
• Secure Development

Identity & Access Management

Threats related to gaining unauthorized access to system(s) or data.

Most common and recognizable security requirements for Identity & Access Management:

• Use Multi-Factor Authentication (MFA) when accessing all parts of the system
• Use Single-Sign-On (SSO) where possible
• Use Role Based Access Control (RBAC), with a clear overview of roles, the rights per role, and the users assigned to roles.
• Performing periodic access reviews for all users, administrators, and highly privileged users.
• Manage Non-Personal Accounts (NPAs), High-Privileged Accounts and Service Accounts effectively.
• Use of the least privilege principle, meaning that users only have access rights that are absolutely needed.
• Use of Segregation of Duties (SoD) for privileged or highly-sensitive actions & activities.

Encryption

Threats related to gaining or intercepting unencrypted business, technical, or personal data.

Most common and recognizable security requirements for Encryption:

• Encrypt all data in transit.
• Encrypt all data at rest.
• Manage security & encryption keys effectively using proven systems and processes.
• Use customer-managed keys when hosting data or systems in (public) cloud environments.

Hardening

Threats related to exploiting (configuration) weaknesses in system(s).

Most common and recognizable security requirements for Hardening:

• Hardening of technical components of the system (i.e., databases, web servers, etc.).
• Removing unnecessary services that are provided by default, or enabled during development.
• Reducing the exposure of services, web pages, administrator panels, etc.
• Applying security patches to technical components of the system.
• Securely manage secrets, tokens, etc. in a vault or similar technology.

Network Security

Threats related to gaining unauthorized network access to (parts of) system(s) or data.

Most common and recognizable security requirements for Network Security:

• Segmenting internal parts of the solution (i.e., segmenting components at the network level).
• Using a firewall between trusted and untrusted zones.

Security Logging, Monitoring & Response

Threats and security requirements related to abuse that go undetected or not identified & remediated.

Most common and recognizable security requirements for Security Logging, Monitoring & Response:

• Logging of technical events occuring at the infrastructure level.
• Logging of important events occuring at the application level.
• Triggering active monitoring of critical events at the infrastructure and application level.
• Response measures by the SOC or other security professionals in case of critical events.

Backup, Availability & Continuity

Threats and security requirements related to disrupting the availability of system(s) or data.

Most common and recognizable security requirements for Backup, Availability & Continuity:

• Performing periodic backups of systems and data.
• Performing air-gapped backups of systems and data for use in a ransomware attack.
• Performing regular recovery tests using backup data.
• Performing regular business continuity sessions to recover from a (simulated) attack or outage.
• Develop redundancy of systems and processes for systems with high availability requirements.

Secure Development

Threats and security requirements related to insecure development processes and tooling.

Most common and recognizable security requirements for Secure Development:

• Use code scanning tooling for newly developed or committed code.
• Use of the four eyes principle for newly committed code.
• Using trusted and secured dependencies, frameworks, and libraries only, and scanning them for known vulnerabilities.
• Performing pentesting for newly developed applications or upon major changes.
• Use of DTAP (Development, Test, Acceptance, and Production) environments, and not using production data in non-production environments.

Simplify Threat Modeling using Known Security Terms (and Less Jargon)

Threat modeling introduces new jargon unfamiliar to many security, IT, and management professionals. The following are examples of unnecessary jargon and their suggested alternatives:

• The STRIDE terms (Spoofing, Tampering, Repudiation, etc.), and instead use terms such as unauthorized access, lack of logging, unauthorized disclosure of (personal) data, gaining unauthorized administrator access, etc.
• Trust Zones and Boundaries, and instead use network-related terms like the Internet, the public network, the internal network, etc.
• Countermeasures or Mitigations, and instead use the term security requirements.
• Datastore, and instead use the terms database, API, etc.
• Threat Library, and instead use the term common threats, or common security requirements (for the countermeasures).

Side note: It’s interesting to see how these topics are mapped in the CISO security mind map.