STRIDE Threat Modelling: What You Need to Know

TL;DR:

• STRIDE threat modelling is a methodology used to identify and eliminate potential vulnerabilities in software development.
• Developed by Microsoft engineers, STRIDE accounts for six different threat categories including spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privileges.
• Other threat modelling methodologies beyond STRIDE include PASTA, VAST, Trike, OCTAVE, and NIST.
• Threat modelling should be conducted annually and whenever significant changes are made to the application.
• Software Secured offers professional Threat Modeling services as part of their Penetration Testing as a Service core offering.

Understanding the Process and Importance of Threat Modelling

Threat modelling is a structured process for understanding a system's security, supported by a manifesto to enhance security and privacy in development. Threat modelling fosters collaboration among diverse stakeholders, bringing together expertise from various domains to comprehensively assess and address potential security risks. This collaborative approach not only enhances the quality of the threat modelling process but also serves as a powerful educational tool. By actively participating in threat modelling exercises, team members across different departments gain valuable insights into cybersecurity concepts and best practices. This engagement helps to cultivate a security-conscious mindset throughout the organization, transforming cybersecurity from a siloed responsibility to a shared competency. As team members become more aware of potential threats and their implications, they are better equipped to incorporate security considerations into their daily work, leading to a more robust and resilient security posture across the entire organization.

STRIDE Threat Modelling: What You Need to Know

STRIDE threat modelling is an approach to integrating security earlier in your software development lifecycle (SDLC). As a threat modelling methodology, the STRIDE framework maps out your application based on its unique use cases and business logic. Therefore, it can be used to identify and eliminate potential vulnerabilities before a single line of code is written. You can also come back to the STRIDE framework anytime while your application is being developed or in production and every time you release new code to see how it will affect your application's overall attack vector. Employing threat modelling should be your first step toward building networks, systems, and applications that will be secure by design.STRIDE is a model of threats that can be used as a framework for ensuring secure application design.

STRIDE as a threat modelling framework

STRIDE was developed in the late 1990s by two engineers working at Microsoft, Koren Kohnfelder and Praerit Garg. In their letter called "The Threats To Our Products," they addressed the new security threats to systems caused by advancing technologies and determined that there needed to be a way to map out the location of potential threats. STRIDE’s threat model accounts for six different threat categories, including:

Spoofing identity

Identify spoofing occurs when the hacker pretends to be another person, assuming the identity and information in that identity to commit fraud. A very common example of this threat is when an email is sent from a false email address, appearing to be someone else (also called a phishing attack). Typically, these emails request sensitive data. A vulnerable or unaware recipient provides the requested data and the hacker is then easily able to assume the new identity.

Identities that are faked can include both human and technical identities. Through spoofing, the hacker can gain access through just one vulnerable identity to then execute a much larger cyber attack. With rapid new advances in artificial intelligence (AI), phishing attacks created by automated tools are now more convincing than ever. Some ways AI conducts phishing include:

• Emails or messages attempting to trick users into clicking malicious content.
• Social opposition trolls to ruin brand reputation.
• Fake news websites and social media pages.

Tampering with data

Data tampering occurs when data or information is changed without authorization. Ways that a bad actor can execute tampering could be through changing a configuration file to gain system control, inserting a malicious file, or deleting/modifying a log file.

Change monitoring, also known as file integrity monitoring (FIM) is essential to integrate into your business to identify if and when data tampering occurs. This process critically examines files with a baseline of what a ‘good’ file looks like. Proper logging and storage are critical to support file monitoring. Read the Security Playbook here to understand the risks of insufficient or excessive logging and auditing.

The image below is an example of a tampering attack tree (another threat modelling activity) of a 3D concrete printing system. Image provided from the publication Threat Modeling in Construction: An Example of a 3D Concrete Printing System.

Repudiation threats

Repudiation threats happen when a bad actor performs an illegal or malicious operation in a system and then denies their involvement with the attack. In these attacks, the system cannot actually trace the malicious activity to identify a hacker.

Repudiation attacks are relatively easy to execute on e-mail systems, as very few systems check outbound mail for validity. Most of these attacks begin as access attacks.

Information disclosure

Information disclosure is also known as information leakage. It happens when an application or website unintentionally reveals data to unauthorized users. This type of threat can affect the process, data flow and data storage in an application. Some examples of information disclosure include unintentional access to source code files via temporary backups, unnecessary exposure of sensitive information such as credit card numbers, and revealing database information in error messages.

These issues are common and can arise from internal content that is shared publicly, insecure application configurations, or flawed error responses in the design of the application.

Denial of service (Dos)

Denial of Service (DoS) attacks restrict an authorized user from accessing resources that they should be able to access. This affects the process, data flow and data storage in an application. DoS attacks are getting bigger and more frequent, with an estimated 12.5 million DDoS weapons detected in 2020. In the State of Penetration Testing as a Service report for 2022, it was reported that DoS attacks increased in frequency by 133% last year.

One of the most famous attacks was on Google in 2017. In their statement, Google said, “The attacker used several networks to spoof 167 Mpps (millions of packets per second) to 180,000 exposed CLDAP, DNS, and SMTP servers, which would then send large responses to us. This demonstrates the volumes a well-resourced attacker can achieve: This was four times larger than the record-breaking 623 Gbps attack from the Mirai botnet a year earlier.”

Despite increases in DoS attacks, it does seem that protective tools such as AWS Shield and CloudFlare continue to be effective.

Elevation of privileges

Through the elevation of privileges, an authorized or unauthorized user in the system can gain access to other information that they are not authorized to see. An example of this attack could be as simple as a missed authorization check, or even elevation through data tampering where the attacker modifies the disk or memory to execute non-authorized commands.

Other threat modelling methodologies beyond the STRIDE framework

One reason that threat modelling is performed as a first step is to obtain an objective viewpoint of the big picture for the project. It will also help define the locations of potential security vulnerabilities. This process can be done once the design has been defined conceptually.

Though STRIDE is a highly popular and effective methodology, several others are also available including PASTA, VAST, Trike, OCTAVE, and NIST. Some are more appropriate for different information technology (IT) disciplines or have different focuses, such as applications instead of networks, for example.

No threat modelling technique is perfectly tailored to a specific use. You should choose the one that most closely aligns with your goals. However, your DevOps team should be encouraged to adapt or customize threat modelling techniques to better fit their specific use case.

Going forward, remember that your threat model is a living document and needs to be constantly reviewed and updated. After a system-wide threat model has been performed it can be valuable to perform mini-threat models as a secure engineering design requirement.

How often should I conduct threat modelling on my application?

Given the rise in security risk and awareness among startups and SMBs over recent years, threat modelling is becoming routine for teams looking to get a better sense of their application/network security for activities such as:

• A new product goes to market.
• Introducing a new deployment model.
• Improving security hygiene best practices before an investment round or M&A.
• Improving their overall product security once initial GRC needs have been met and maintained.
• As part of your overall application security

As a best practice, full initial threat modelling should be performed and repeated annually as a security requirement. Delta threat modelling should be performed on any newly proposed feature or significant change during the design phase.

We offer professional threat modelling services as a key feature of our Penetration Testing as a Service core offering. Threat modelling is a collaborative exercise between Software Secured's pentesters and your Product, Development, Infrastructure and Security leads. The result includes an internal report and working document outlining outstanding threats and suggested mitigations; some clients also request external facing documents to leverage with their sales and marketing teams, proving security maturity to their client base while maintaining oversight on the commitments made to prospects as it pertains to data security.

 If you are interested in learning more or booking a threat modelling service, please book a call with us.