Blog 6

The heart of the Secure SDLC, and my favorite part, is the Threat Model. This is a document where all the security threats are identified at Design phase, before any coding begins. To build it, one takes the application architecture diagram and asks some simple and – and this is key in my view – standard questions. Here is a short description of how it works.

The architecture diagram is built of four core elements:

• Processes (like a web service)
• Data Stores (like a database)
• Data Flows (data moving between two elements)
• External Entities (anything outside our control that interacts with the application, like users)

Each element is subject to certain security threats. We used the STRIDE model for listing these threats – it stands for:

• S: Spoofing – the ability to pose as someone or something else
• T: Tampering – the ability to change something without authorization
• R: Repudiation – the ability to disavow a transaction
• I: Information Disclosure – the ability to view something without authorization
• D: Denial of Service – the ability to degrade a service
• E: Elevation of Privilege – the ability to elevate capabilities

As mentioned, each element of the application diagram is subject to certain threats:

• Processes are subject to all of them, the entire STRIDE
• Data Stores only to TID, and if logs are stored, then also to R
• Data Flows only to TID
• External Entities only to SRD

And each of these threats is mitigated by certain controls. For example, Spoofing is mitigated using authentication, Tampering using integrity controls, etc.

Then, one puts the threats and corresponding controls to each of the elements in the architecture diagram. And because there are always the same threats per element, it is very easy to build.

There a few more things that go into building a complete Threat Model, such as identifying the Attack Surface, i.e., the authentication level (admin, user, anonymous) and the access type (remote, local), and identifying the sensitivity or classification of the data that is being handled (confidential, internal, etc.), but this is in a nutshell how one is built. I think this is a brilliant way to ensuring security is included since the very design of the application.