During my first 7 years at Microsoft, I spent most of my time working on security features such as access control, authentication, cryptography and so on. The next 12 years were spent in product groups and the Security Development Lifecycle (SDL) team working on software design, development and testing practices across the company in order to help defend against security threats. The past year was a big change for me, as I am now working directly with Microsoft customers helping them implement security software development practices based on the SDL. One of the most valuable and important SDL practices is threat modeling which is a systematic way to find design-level security and privacy weaknesses in a system. It also helps guide a designer or architect to determine the correct mitigation(s) to use to reduce the overall risk to a system and the data.
Threat modeling applies equally well to both development projects and design/implementation projects for existing software products.
If you already know about threat modeling, then skip to the section titled, “In the Wild.”
As I mentioned, threat modeling helps you uncover potential insecure design issues in a system. The process of building a threat model is straightforward, and involves identifying the core elements of the system such as the processes, the data storage systems, how the data flows through the system and the external entities that interact with the system. Once this is known, the list of potential threats is automatically determined using the STRIDE mnemonic. The elements of STRIDE are:
S – Spoofing. The ability to pose as someone or something else.
T – Tampering. The unauthorized ability to change something.
R – Repudiation. The ability to disavow a transaction.
I – Information Disclosure. The unauthorized ability to view something.
D – Denial of service. The ability to degrade service.
E – Elevation of privilege. The ability to elevate capabilities.
Think of STRIDE as CIA (Confidentiality, Integrity and Availability) but more fine-grained, and from an attacker’s viewpoint.
Elements in the application diagram are subject to various STRIDE categories. For example a data flow between two processes (think: web browser to web server, or web server to database server) is subject to T, I & D. The next step is to determine which of these threats are a real risk. For example, do you care if an attacker can view (Information Disclosure) the data on the wire that flows from the web server to the web browser? If the answer is ‘Yes’ then that threat must be mitigated, and the way ‘I’ threats are mitigated is with confidentiality techniques such as access control policies or encryption. At this point, the appropriate mitigation is selected. This often requires using defenses and mitigations specified in the enterprise architecture.
This process continues until all STRIDE elements for each application diagram element are addressed.
The last nine months or so has seen me spend most of my time with our customers, and in every engagement we have built one or more threat models. I thought it would be worthwhile to explain some of the things I’ve learned from building threat models outside of Microsoft product groups.
In every engagement, bar none, we have found insecure design issues that could render a system vulnerable to attack and compromise.
For example, when building a threat model for a law enforcement organization last year, the client said, “We know we have an issue, let’s see if the threat modeling process can find it.” The issue was uncovered in 20 minutes in the threat modeling session, and we found three more issues!
In another example, we uncovered a very serious vulnerability. This customer had a system that used devices to monitor critical infrastructure. The data flow between their monitoring system and the remote devices was subject to tampering (T) and information disclosure (I) threats, but those threats were addressed using cryptographic means. The remote devices are subject to all the STRIDE threats because processes are subject to S, T, R, I, D and E threats. Let’s look at ‘S’ – spoofing. The devices can be spoofed. In other words an attacker could replace a valid device with a rogue device, and the rogue device could continue to send back “System Nominal” signals to the central monitoring system while the critical infrastructure being monitored is attacked. You have probably seen scenarios like this in the movies! Clearly this is a real threat that must be mitigated. But there was no good mitigation being used by the system. Spoofing threats are mitigated with authentication, but there was no device authentication whatsoever in this system. The channel was encrypted between the two end-points, so the monitoring system had private communication with, well, something!
I have plenty more stories like this!
Every customer I have worked with falls into one of two camps: the first has never used or heard of threat modeling, the second has built one or more threat models, and found it too hard. The good news is threat modeling is easy! If it’s hard, you’re doing it wrong.
A customer I am working with told me they had abandoned threat modeling because it was a waste of time owing to the investment involved. It was too complex, too time-consuming and provided little benefit. When I looked at what they were doing, they were drilling down to a FUNCTION CALL level! Remember, threat modeling is a design-phase task, not an implementation-phase task. You don’t need to go to a function call depth
After a little re-education, we spent a mere 45 minutes building a threat model for a critical application, and we uncovered three unmitigated issues. The customer is now a believer, and they now require threat models for all new applications.
I know this isn’t a true threat modeling topic, but the answer to many people’s threats seems to be “we use SSL/TLS” which unfortunately is rarely the correct mitigation for many threats. The problems arise when developers build a system and use SSL/TLS programmatically. SSL/TLS isn’t simple, there are many details programmers must bake into their code to check that SSL/TLS and the certificate used by the server and potentially the client are correct to fully mitigate threats such as information disclosure and spoofing.
Getting SSL/TLS wrong in code may not seem like a big deal, but it really is, especially if you want to design a robust and secure system.
If you want to learn more about threat modeling, take a look at the design section of the SDL web site. If you want learn EVEN MORE please feel free to leave a note below and we can get in touch.
Michael Howard,
Principal Cybersecurity Architect
Since 2019, Forest Blizzard has used a custom post-compromise tool to exploit a vulnerability in the Windows Print Spooler service that allows elevated permissions. Microsoft has issued a security update addressing this vulnerability as CVE-2022-38028.
Microsoft has been tracking activity related to the financially motivated threat actor Octo Tempest, whose evolving campaigns represent a growing concern for many organizations across multiple industries.
A set of memory corruption vulnerabilities in the ncurses library could have allowed attackers to chain the vulnerabilities to elevate privileges and run code in the targeted program's context or perform other malicious actions.
In a recent investigation by Microsoft Incident Response of a BlackByte 2.0 ransomware attack, we found that the threat actor progressed through the full attack chain, from initial access to impact, in less than five days, causing significant business disruption for the victim organization.
