Skip to main content

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.

A cybercriminal is on a computer stealing credit card information by exploiting a security bug.

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

S

Spoofing

An attacker pretends to be someone or something that they're not. 

Changing display names or identities



  • Authentication and anomaly detection
  • Security-first user experience design
  • Authentication encryption to support antispoofing
  • Antitampering and anti-information disclosure properties

T

Tampering

An attacker can modify or delete data. 

Intercepting and modifying a data

  • Data input validation
  • Cryptographic signatures
  • Error-detection codes; for example, hash-based message authentication code (HMAC)

R

Repudiation

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



  • Database event logs
  • Application event logs
  • Authentication logs

I

Information disclosure

An attacker obtains access to data that should be protected.

Exfiltrating data from a database

  • Encryption
  • Network boundary enforcement
  • Constraining information outputs

D

Denial of service (DoS)

An attacker does something to degrade a service or deny it to other entities.

Flooding a host with network data


  • Flood control
  • Governors (resource limiters)
  • Monitoring
  • Performance tuning or scaling
  • Availability and reliability enhancements

E

Elevation 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


  • Authorization
  • Permissioning and anomaly detection
  • Role-based access control
  • Network access control lists
  • Ensuring permissions are consistently applied across the entire system

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!

A system diagram outlining a simple blog system.

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.

Resources

Comparta sus comentarios de Trailhead en la Ayuda de Salesforce.

Nos encantaría saber más sobre su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios en cualquier momento en el sitio de Ayuda de Salesforce.

Más información Continuar a Compartir comentarios