Threat Modeling With STRIDE

STRIDE is a threat modeling program developed by Microsoft and first published in MSDN magazine (November, 2006), with Shawn Hernan, Scott Lambert, Tomasz Ostwald and Adam Shostack. STRIDE is broken down into the following 5 categories and their associated security property.

Threat	Desired Security Property
Spoofing	Authentication
Tampering	Integrity
Repudiation	Non-repudiation
Information Disclosure	Confidentiality
Denial of Service	Availability
Elevation of Privilege	Authorization

In the STRIDE threat model, you analyze components of a system and often break them down using data flow diagrams (DFD). Thereupon, you examine each component and determine if each of the STRIDE threats are applicable and then develop mitigations from there. 

Spoofing identity focuses on the authentication (AuthN) portion of authentication and authorization. A spoofing threat is one where an attacker can spoof or impersonate a legitimate user. In a standard web application, an example threat would be for an attacker to use a stolen password, or to perform a technique such as password spraying, in an attempt to gain access to the application. Today, the two primary mitigations for such an attack include multi-factor authentication (MFA) aka two-factor authentication (2FA) and single sign on (SSO) solutions. 

Tampering with data involves the malicious modification of data. A tampering threat is one where an attacker can alter the data either stored or being displayed to a user. Tampered data could live in a persistent data store or database, or it could be modified in transit. There are multiple mitigation methods that one can use for this type of attack and it really depends on the specific components that will be used. For example, to prevent modification of data in a data store, you may need to add data validation in various parts of the application. In the case of preventing data tampering in transit, TLS or similar should be used wherever possible.

Repudiation involves the denial of an action performed by a threat actor. For example, a threat actor is able to overwrite data and is then able to deny they performed such an action. One such mitigation technique for such a threat is verifying you have full audit logging capabilities that will also need to be vetted for this threat.

Information disclosure involves exposing information to users that were not granted access to see such data. An all too common case of information disclosure that happens is an incremental ID attack whereby an attacker is simply able to change the ID of the page they are on to show information for another user. There are many possible ways to mitigate this type of threat and each are highly dependent on the system that is being examined as there are many different ways to inadvertently expose data. A thorough understanding of your asset inventory, and public exposure are also highly important to help with mitigation for this threat.  

Denial of service (DoS) threatens the availability of the service. A DoS attack simply overwhelms the system preventing legitimate users from being able to interact with the system. Standard operating procedures for cloud environment architecture specify for scalable, replaceable systems that can meet demand. DoS threats have become so ingrained that companies like Netflix and others have developed chaos engineering to specifically inflict threats to ensure that mitigations have been put in place to prevent this type of threat.

Elevation of privilege is the final threat in the STRIDE model. As we started with AuthN, we now focus on Authorization (AuthZ). In this type of threat, an attacker is able to escalate or elevate their privileges from their standard controls. For example, if a system allows for editors and viewers in the application, an elevation of privileges would be for a viewer to perform an action to be able to give themselves permission to edit instead. One such basic mitigation would be to put in place checks to verify appropriate access levels with each request in a standard web application. Thorough testing of such features is also highly recommended to ensure that your AuthZ system is working properly.

STRIDE threat modeling replaced Microsoft’s earlier DREAD threat model methodology. As the threat modeling and secure software development lifecycle methodologies evolved, Adam Shostack and Microsoft found that STRIDE helped focus on the data flows, enabled engineers without security experience to participate and that STRIDE specifically worked for Microsoft in the clusters of threats they were finding. Specifically in relation to DREAD, they found that the ratings, although they appeared to be useful for quantifying risk, were not repeatable for software centric problems. Overall in presenting on STRIDE and threat modeling in general Adam Shostack has said, “I don’t believe that there is a right or wrong approach, only ones that are more or less useful.”

At Cyral, we are constantly working to provide actionable priorities to secure the data layer. With Cyral, we provide not only in depth monitoring of your most critical data repositories but also actionable items to help lower your overall risk. Gain instant insights that will allow you to prioritize and communicate your highest risks with Cyral.