) 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.<\/span><\/span><\/p>\nThreat modeling applies equally well to both development projects and design\/implementation projects for existing software products.\u00a0 <\/span><\/span><\/p>\nIf you already know about threat modeling, then skip to the section titled, \u201cIn the Wild.\u201d<\/span><\/span><\/p>\nWhat is Threat Modeling?<\/span><\/span><\/h1>\nAs 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:<\/span><\/span><\/p>\nS \u2013 Spoofing. The ability to pose as someone or something else.<\/span><\/span><\/p>\nT \u2013 Tampering. The unauthorized ability to change something.<\/span><\/span><\/p>\nR \u2013 Repudiation. The ability to disavow a transaction.<\/span><\/span><\/p>\nI \u2013 Information Disclosure. The unauthorized ability to view something.<\/span><\/span><\/p>\nD \u2013 Denial of service. The ability to degrade service.<\/span><\/span><\/p>\nE \u2013 Elevation of privilege. The ability to elevate capabilities.<\/span><\/span><\/p>\nThink of STRIDE as CIA (Confidentiality, Integrity and Availability) but more fine-grained, and from an attacker\u2019s viewpoint. <\/span><\/span><\/p>\nElements 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 \u2018Yes\u2019 then that threat must be mitigated, and the way \u2018I\u2019 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.<\/span><\/span><\/p>\nThis process continues until all STRIDE elements for each application diagram element are addressed.<\/span><\/span><\/p>\nIn the Wild<\/span><\/span><\/h1>\nThe 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\u2019ve learned from building threat models outside of Microsoft product groups.<\/span><\/span><\/p>\nObservation One: You WILL find Vulnerabilities<\/span><\/span><\/span><\/h2>\nIn every engagement, bar none, we have found insecure design issues that could render a system vulnerable to attack and compromise. <\/span><\/span><\/p>\nFor example, when building a threat model for a law enforcement organization last year, the client said, \u201cWe know we have an issue, let\u2019s see if the threat modeling process can find it.\u201d The issue was uncovered in 20 minutes in the threat modeling session, and we found three more issues! <\/span><\/span><\/p>\nIn 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\u2019s look at \u2018S\u2019 \u2013 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 \u201cSystem Nominal\u201d 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! <\/span><\/span><\/p>\nI have plenty more stories like this!\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span><\/span><\/p>\n