Threat Modeling

What is Threat Modeling and Why Do We Need It?

Threat modeling looks at a system from a potential attacker's perspective, as opposed to a defender's viewpoint. Making threat modeling a core component of your SDLC can help increase product security/

Threat modeling is about answering the question:

Ok, but what information security actually is?

Information Security Dimensions

• Authentication: Verifying the identity of users, systems, or entities to ensure they are who they claim to be.
• Authorization: Granting or restricting access to resources based on the authenticated user's privileges and permissions.
• Integrity: Ensuring that data remains accurate, consistent, and unaltered during storage, processing, or transmission.
• Availability: Ensuring that systems and resources are consistently accessible and usable by authorized users when needed.
• Non-Repudiation: Preventing individuals from denying the validity of their actions or transactions, ensuring accountability for actions taken.
• Confidentiality: Protecting sensitive information from unauthorized access, disclosure, or exposure.

Threat Modeling and Asset Protection

Threat modeling involves a systematic approach to identifying potential threats, assessing vulnerabilities, and implementing security controls. When it comes to assets, the threat modeling process becomes a strategic exercise to ensure the resilience of the organization. Here's how you can approach it:

Asset Identification

Start by creating an inventory of all assets, categorizing them based on their value to the organization. This could include customer data, intellectual property, hardware infrastructure, and more.

By understanding what assets are, recognizing their value, and incorporating them into a comprehensive threat modeling framework, organizations can fortify their defenses and safeguard against potential cyber threats.

Defining Assets in Threat Modeling. What should we secure?

1. Valuable Things - The Business Cares!

Assets are the lifeblood of any organization. They are the tangible and intangible elements that contribute to the business's success and sustainability. This could encompass customer data, proprietary software, financial records, or any resource critical to the functioning of the enterprise.

2. Something an Attacker Wants?

Assets are not just valuable to the business; they are often equally appealing to attackers with malicious intent. Hackers may target sensitive information, financial assets, or intellectual property to exploit, sell, or disrupt. Identifying what makes an asset attractive to potential threats is a key step in the threat modeling process.

3. Something You Want to Protect?

An asset is something that warrants protection. Whether it's customer trust, proprietary technology, or confidential information, recognizing the importance of these elements to the organization is the first line of defense. Understanding what you want to protect helps in crafting robust security measures.

4. A Stepping Stone?

Assets can serve as stepping stones for attackers to gain access to more critical systems or information. For example, compromising a less secure system might provide a gateway to a more valuable one. Recognizing the interconnectedness of assets and potential pathways for attackers is vital in building a comprehensive threat model.

How to Perform Threat Modeling Step by Step

1. Decompose the application
2. Determine and rank threats
3. Determine countermeasures and mitigation

1. Decompose the application

The first step in the intriguing world of threat modeling involves gaining a solid understanding of the application and its interactions with the outside world. This includes:

• Creating Use Cases: Understanding how the application is used by sketching out common scenarios.
• Identifying Entry Points: Locating potential areas where an attacker might interact with the application.
• Identifying Assets: Recognizing items or areas that might catch an attacker's interest.
• Identifying Trust Levels: Defining the access rights the application grants to external entities.

All these details find a home in the resulting Threat Model document. This document not only summarizes the application's intricacies but also serves as a guide for future security measures.

Further, these insights contribute to the creation of Data Flow Diagrams (DFDs). These diagrams map out the pathways of information flow, shedding light on privilege boundaries within the system.

This comprehensive understanding, documented and visualized, equips security professionals to navigate the challenges of safeguarding the digital landscape.

Data Flow Diagram example:

Key description:

2. Determine and Rank Threats

In the world of cybersecurity, identifying threats is crucial, and it often begins with a categorization method like STRIDE or the Application Security Framework (ASF). This framework breaks down threats into categories such as Auditing & Logging, Authentication, Authorization, and more.

The purpose of threat categorization is to highlight potential risks from both the attacker's and defender's perspectives (ASF). When we start the journey, Data Flow Diagrams (DFDs) become handy, helping us spot potential threats from the attacker's point of view – like data sources, processes, and user interactions.

These identified threats become the basis for threat trees, each representing a specific risk. From a defensive angle, ASF categorization acts as a guide, revealing threats as weaknesses in security controls. To dig deeper into these risks, common threat lists with examples are useful.

Practical use and abuse cases come into play, illustrating how existing protective measures could be bypassed or where protection might be lacking. Assessing the security risk for each threat finds its grounding in a risk model like DREAD or a qualitative approach considering factors like likelihood and impact.

STRIDE

Examples of Threats

• SPOOFING: Falsely claiming to be Acme.com, winsock .dll, Barack Obama, a police officer, or the Nigerian Anti-Fraud Group
• TAMPERING: Changing a spreadsheet, the binary of an important program, or the contents of a database on disk; modifying, adding, or removing packets over a network, either local or far across the Internet, wired or wireless; changing either the data a program is using or the running program itself
• REPUDIATION: Process or system: “I didn't hit the big red button” or “I didn't order that Ferrari.” Note that repudiation is somewhat the odd-threat-out here; it transcends the technical nature of the other threats to the business layer. What evidence do you have?
• INFORMATION DISCLOSURE: The most obvious example is allowing access to files, e-mail, or databases, but information disclosure can also involve filenames (“Termination for John Doe.docx”), packets on a network, or the contents of program memory.
• DENIAL OF SERVICE: A program that can be tricked into using up all its memory, a file that fills up the disk, or so many network connections that real traffic can't get through
• ELEVATION OF PRIVILEGE: Allowing a normal user to execute code as admin; allowing a remote person without any privileges to run code

Determine Countermeasures and Mitigation

Addressing vulnerabilities in a systematic and effective way is paramount for ensuring the security of an application or system. Here's a structured approach to finding and mitigating vulnerabilities:

• Find Countermeasures: Utilize threat-countermeasure mapping lists to identify potential countermeasures for each vulnerability. This step involves understanding the specific threats and determining the appropriate measures to counteract them.
• Choose a Risk Mitigation Strategy: Based on the business impact and available options, select a risk mitigation strategy. The options include:
• Accept: Decide that the impact is acceptable, acknowledging that the risk is within acceptable limits.
• Eliminate: Remove components that cause the vulnerability, effectively eradicating the source of the risk.
• Mitigate: Implement checks or controls that either reduce the impact or the likelihood of the vulnerability being exploited.
• Document Countermeasures: Thoroughly document the selected countermeasures for each vulnerability. This documentation serves as a reference for the implemented security measures.
• Document Residual Risk and Assumptions: In the threat model documentation, capture the residual risk i.e. the remaining risk after countermeasures are applied. Additionally, document any assumptions made during the mitigation process, providing clarity on the decision-making context.

This structured approach ensures that vulnerabilities are not only identified but also addressed with well-thought-out countermeasures, aligning with the overall risk mitigation strategy and business objectives.

Tools and Techniques for Creating and Analyzing Threat Models

• Microsoft Threat Modeling Tool
• OWASP Threat Dragon
• Threagile
• OWASP pytm

References

• OWASP Threat Modeling
• Threat Modeling: Designing for Security - Adam Shostack