Spot the Threats
Learning Objectives
After completing this unit, you’ll be able to:
- Describe hacker behavior.
- Define the STRIDE mnemonic.
- Analyze your architecture to identify threats to your security objectives.
How Do You Think Like a Hacker?
In defining your security objectives, you’ve defined the assets you need to protect. Now it’s time to actually think like the hacker who is after those assets.
When doing this, it can be helpful to think in terms of attacker archetypes: the most common examples of attackers out there. These include hacktivists, cybercriminals, and cyber warriors.
Hacktivists
These attackers want to damage a company’s reputation to make a statement or to further a political agenda. They generally rely on their own skills and freely available or open source hacking resources. Hacktivists care about being seen or detected in the end, so they consider activities like destroying data or damaging systems.
Cybercriminals
Your customers’ data has value, sometimes directly, like payment card information (PCI). If attackers working together stealthily obtain that information, they can turn a profit on the black market. If the information has intangible market value, they may hold it for ransom, as in ransomware campaigns. These attacks can be broad or targeted at a specific organization.
Cyber Warriors
You provide value as an organization by maintaining your rights to intellectual property. If a nation-state gains access to this intellectual property or hinders your ability to apply that knowledge, they can use it to advance their government’s interests. Such cyber warrior attacks are thus highly targeted, and, unlike the work a hacktivist does, a cyber warrior’s efforts have to slide under the radar.
Thinking like an attacker means asking these questions.
- How can your identified attackers abuse a system to get the goods or otherwise cause mayhem?
- What can plausibly go wrong, given known types of attacks?
Hackers choose attacks economically—they use methods with a reasonable cost and the most likelihood of success. Expensive, impractical attacks are unlikely. So what kinds of attacks can you expect? This is where STRIDE comes in.
The STRIDE Mnemonic
Even security experts can get stumped when trying to identify all plausible threats. If you’re struggling to come up with anything, it’s time to hit your STRIDE.
STRIDE is a mnemonic that stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. These are all different classifications of common threats, which can help jumpstart the brainstorming process when threat modeling. The following table explains STRIDE in further detail with specific examples of threats and their mitigations.
STRIDE mnemonic |
Class of Threats | Example Threats | Mitigations |
---|---|---|---|
SSpoofing |
An attacker pretends to be someone or something that they're not. |
Changing display names or identities |
|
TTampering |
An attacker can modify or delete data. |
Intercepting and modifying a data |
|
RRepudiation |
An attacker can perform some action and deny it later because there is no record or evidence captured. |
Deleting or editing records without a log entry |
|
IInformation disclosure |
An attacker obtains access to data that should be protected. |
Exfiltrating data from a database |
|
DDenial of service (DoS) |
An attacker does something to degrade a service or deny it to other entities. |
Flooding a host with network data |
|
EElevation of privilege (EoP) |
An attacker figures out a way to do something or obtain access to something despite not having the permissions. |
Finding hidden administrative user interfaces |
|
Of course, the examples in this table are just that—examples. There are more threats than those that neatly fit into the STRIDE classifications. At the end of the day, if your identified attackers can do it, it’s a valid threat to identify.
It’s OK: Break the Rules
You follow the rules most of the time. Now is the time to put on your attacker hat and break them! List everything that can realistically go wrong while looking at your architecture and security objectives. Remember, your goal is to be realistic. Don’t get stuck thinking about unrealistic and implausible attacks. However, if someone on your team says, “That's unlikely!” in response to an otherwise realistic threat, write it down anyway. Given enough time, unlikely threats, but realistic threats can still happen.
Let’s return to the example of a simple blog system to see what this looks like.
In the following diagram, the admin creates authors by entering their email addresses (1). The system sends the authors a reset token (2) the authors can use to set their initial passphrase (3). They use their email and passphrase to create or edit a blog post (4). Anonymous readers can see the blog post rendered as HTML (5). The entities (administrator, author, and anonymous reader) exist outside of the web server trust zone.
In this type of system, attackers come from outside the web server trust boundary, so it makes sense to look for threats at the numbered interaction points. Try to identify at least one threat at each point. Keep a table or spreadsheet to help you stay organized and to minimize your data-entry effort. Don’t try to file bugs or work items just yet!
Here are some example threats identified for the numbered points in this sample data-flow diagram.
Numbered Point | Class(es) | Threat |
---|---|---|
1–4 |
Information Disclosure, Tampering |
An attacker alters a cookie to enable a specific feature, such as your private user profile. |
1 |
Tampering, Elevation of Privilege |
The cookie for the administrator can be tampered with or stolen to let the attacker access the administrative console. |
2 |
Spoofing, Elevation of Privilege |
An attacker intercepts the transmission of the reset token and uses it to set a passphrase, taking control of the author's account. |
3 |
Spoofing |
An attacker gets access to an old reset token in an email to an author and uses that to change the author's passphrase. |
4 |
Spoofing |
An attacker uses a legitimate set of credentials but spoofs the author= field in the request to make it appear as if another author wrote an incendiary blog post. |
4, 5 |
Tampering |
A malicious author injects bad JavaScript into the blog post, which is served to users to perpetuate Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), and other attacks. |
5 |
DoS |
An anonymous user floods the blog server with requests, slowing the site down for everyone. |
5 |
Information Disclosure, Tampering |
HTTPS is not being used, letting the attacker insert malicious JavaScript replacements for posts, redirect the user to a malicious site, and so on. |
You’re done with this step when your team feels certain there’s nothing left to add. It’s best to do this together in a meeting, but you might need a subset of your team to work on this to move forward efficiently.
Knowledge Check
Ready to review what you’ve learned? The knowledge check below isn’t scored—it’s just an easy way to quiz yourself. To get started, drag the term in the left column next to the matching description on the right. When you finish matching all the items, click Submit to check your work. To start over, click Reset.
Great work!
We’ve learned how to identify the threats! In the next section, we’ll cover what we can do to mitigate these threats.