Security 4 Nø0bs — Keepin’ it in S.T.R.I.D.E.
Security 4 Nø0bs — Keepin’ it in S.T.R.I.D.E.
The basics of threat modeling and how it benefits Pen Testing
Hola Friends,
If you’ve been following along, we have discussed scope, ROE, and most recently, recon essentials. We have completed the recon phase of the pen test for Altoro Mutual¹, and have mapped the urls, open ports, and their tech stack.
It’s time to take a quick look at threat modeling and how it can help us gain a complete understanding of what features are important to the Client and/or how to structure our test effort to prioritize accordingly then execute efficiently and effectively.
** Disclaimer — Threat Modeling is an exercise that occurs early in the development phase of a project, by a separate team. The purpose of this post is to discuss the value of a threat model to Pen Testing, and not how to perform a threat model for the app.
What is threat modeling?
A very high level definition of threat modeling is decomposing a site down to it’s core elements or features and then interrogating these features for potential security vulnerabilities. In other words, we inspect a feature and ask, “what is the likelihood of x happening? and how could it be avoided?”
The Pen Test Standard (PTES)² outlines the process of threat modeling as:
- Gather relevant documentation
- Identify and categorize primary and secondary assets
- Identify and categorize threats and threat communities
- Map threat communities against primary and secondary assets
For our project — Altoro Mutual — we’ve outlined the features to be:
- A series of static web pages
- A login form
- A subscription input
- Urls with distinct parameters
How to model threats
There are several ways an application can be modeled for threats. These mnemonics help formulate how the features are dissected and analysed.
S.T.R.I.D.E³
STRIDE stands for (S)poofing, (T)ampering, (R)epudiation, (I)nformation Disclosure, (D)enial of Service, (E)levation of Privilege, which are the types of attacks that may impact a feature. Based on our inspection of the application under test we can see where some of these attacks can happen. We can ask questions like:
- Given the user is on the login form, When they log in, is there a chance that their PII is leaked?
- Is the login form susceptible to username harvesting or password spraying?
- Is the email input sanitizing invalid inputs?
- Can the url parameters be tampered with?
We’ll take questions like this and formulate a plan of attack.
D.R.E.A.D⁴
DREAD stands for (D)amage Potential, (R)eproducibility, (E)xploitability, (A)ffected Users, (D)iscoverability, and helps define the overall impact of the potential vulnerability discovered with STRIDE.
For example: we’ve determined the login feature is vulnerable to username harvesting. Based on this finding, we can investigate this vulnerability for the following:
- What is the damage potential for password spraying?
- How easy it is to reproduce?
- What is the exploitability of this vulnerability?
- Who are the affected users?
- How easy was it to discover this vulnerability?
DREAD can be scored in several ways, but the most common is a qualitative low, medium, or high. The cumulative result will determine the threat level.
Putting it all together
When we combine STRIDE and DREAD, we can formulate a list of prioritized features that need to be tested. Time may not allow for a comprehensive threat model, but a high-level understanding of what the priorities are is a good strategic approach.
Ideally, the Client will have a set of business-critical features or functions; high-value workflows as well as a proper model. If no threat model has been provided, we can inspect the application and build a model with which to frame a plan of attack.
Once we’ve determined the potential vulnerabilities and their threat level, we will employ this model as our baseline. From there, we will conduct our tests and reconcile our findings against the baseline.
For Altoro Mutual, the Client has a vested interest in keep customer PII safe. One of the many scenarios is as follows:
- Feature: Login
- Priority: High
- Threat Type: Information Disclosure
- Vulnerability: The login feature is susceptible to username harvesting
- Threat Level: Critical
- Test approach: intercept the login request and inspect the payload, hoping that user credentials are not plain text in the response body.
Conclusion
Threat modeling is a key step in the Pen Testing process, but where it is most invaluable is at the earliest phase of the Software Development Lifecycle (SDLC), serving to catch security vulnerabilities early.
The Threat Model asks the question, is this feature vulnerable to this attack?
For Pen Testers, a comprehensive threat model is a useful bit of information serving as an instrument of insight into what features are highest priority, and what the attack surface looks like.
Knowing what the Client has considered to be business-critical and what is non-essential helps optimize the test effort. Testers can leverage the threat model information and frame their attack approach.
Until next time …
ciao for now