STRIDE Threat Modeling: What You Need to Know

STRIDE threat modeling is an approach to integrating earlier in your software development lifecycle (SDLC). As a threat modeling methodology, the STRIDE framework is used to map out your application based on it's 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 modeling 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 in ensuring secure application design.

STRIDE as a threat modeling framework

STRIDE was developed in the late 1990’s 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 includes:

• Emails or messages attempting to trick users to click 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 is 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 modeling 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 lacks the ability to 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 modeling methodologies beyond the STRIDE framework

One reason that threat modeling 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 modeling 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 modeling on my application?

• Full initial threat modelling should be performed and repeated annually.
• Delta threat modelling should be performed on any newly proposed feature or significant change at the design phase.

Software Secured offers professional Threat Modeling services as a key feature our Penetration Testing as a Service core offering. If you are interested to learn more or book a threat modeling service, please book a call with us.