dr knz @ work

The STRIDE threat model with examples

I like to think about computer security as the science of how things can go wrong with computers.

There is so much that can go wrong! In so many different ways! To avoid becoming overwhelmed, computer engineers need a systematic way to think about security, talk about it with each other and organize work to build secure systems.

For this purpose, I like to use and recommend the STRIDE model, which I learned from my friend @noopwafel.

STRIDE provides mental tools to think systematically about computer security and communicate those thoughts effectively with others.

STRIDE in short

STRIDE separates “things that can go wrong” in six categories:

Threat category In layman’s terms Property that blocks the threat In layman’s terms
Spoofing Mallory sends a letter to Ben and signs “Alice wrote this.” Ben believes it. Authenticity Ben sees Mallory’s letter and knows Alice did not write it.
Tampering Mallory borrows Alice’s letter from the postman, and erases every occurence of “the”. Ben receives the letter and thinks Alice writes poorly. Integrity Ben notices that the letter was modified.
Repudiation Mallory calls Ben in the middle of the night. The following day, Mallory says he never called and Ben thinks he must have dreamed. Non-repudiability Ben can see Mallory’s phone records and confirm that Mallory indeed called.
Information disclosure Mallory reads Alice’s secret love letter to Ben. Confidentiality Alice’s letter is hidden from Mallory.
Denial of service Mallory locks Ben in his house and breaks the key in the lock. Ben cannot get outside. Availability Ben has a second door at the back of his house.
Elevation of privilege Mallory opens an account at Alice’s bank in her name. Authorization The bank refuses to open the account without Alice’s consent.

The STRIDE model was invented by two engineers at Microsoft in 1999. See “further reading” below for a link.

General remediation methods and techniques

In computer systems, especially networked applications, some consensus has emerged as to how to systematically prevent threats:

Spoofing

How to provide authentication:

  • Certificate validation from recognized Certification Authorities (CAs): the authentication part of SSL/TLS.
  • Multi-factor authentication.
  • Shared secrets (e.g. passwords) — as long as they are complex and only used for one purpose.

Pitfalls:

  • secret-based authentication breaks without strong confidentiality of the authentication tokens.
  • authentication does not work without integrity (see below). Without integrity, it is possible to modify data in-transit after authentication takes place and effectively “own” the communication: this is a man-in-the-middle attack.
  • however, the converse is not true: it is possible (and sometimes desirable!) to build tamper-proof systems without authenticity. See off-the-record messaging for an example.

Tampering

How to provide integrity:

Pitfalls:

  • Checksum-based integrity, such as implemented in TCP or inside credit card numbers, is meant to protect against random faults and communication errors. Checksums are not a good basis to provide protection against tampering in secure systems.

Repudiation

How to provide non-repudiation:

  • Access logs: who was accessing the system at which times.
  • Audit logs: who was viewing or modifying which data at which times.
  • Append-only databases: all the intermediate states of data are preserved, information is not modified in-place.
  • Historical backups (for audit purposes).

Notes:

  • SSL/TLS does not have much to say about non-repudiation.
  • For some applications, the option to repudiate is actually desirable. To achieve this, forward secrecy can be used.

Information disclosure

How to provide confidentiality:

  • Encryption of communications: the confidentiality part of SSL/TLS.
  • Encryption of storage: filesystem encryption, disk encryption, RAM encryption.
  • Firewalling.
  • Preventing data connections to networks altogether.
  • Isolation of resources (CPU, memory, I/O) between separate applications to prevent side-channel attacks.

Pitfalls:

  • In storage systems, confidentiality exists at three levels:

    • the data values (“I don’t want Mallory to read the body of my e-mail”).
    • the inner metadata (“I don’t want Mallory to read the subject of my e-mail”).
    • the outer metadata (“I don’t want Mallory to know I have sent an e-mail to Ben”).

    Systems are usually designed for confidentiality of values and inner metadata in mind from the start, but outer metadata typically requires more effort and is thus easily overlooked.

Denial of service

How to provide availability:

  • Isolation of resources (CPU, memory, I/O) between separate applications to prevent DoS attacks:
    • Privilege domains in operating systems.
    • Containers.
    • Virtual machines.
    • Separate physical servers.
  • In networks: QoS, connection and data throttling.
  • Automatic scale-up (adding more servers) under load with load balancing.
  • Replication with automatic fail-over for storage systems.

Elevation of privilege

How to provide authorization:

Pitfalls:

  • Effective authorization is not possible without strong authentication.
  • Authorization is not possible without strong integrity of the authorization rules.

Further reading

Like this post? Share on: Twitter ❄ Hacker News ❄ Reddit ❄ LinkedIn ❄ Email

Raphael ‘kena’ Poss Avatar Raphael ‘kena’ Poss is a computer scientist and software engineer specialized in compiler construction, computer architecture, operating systems and databases.
Comments

So what do you think? Did I miss something? Is any part unclear? Leave your comments below.

Keep Reading

Published

Category

Research

Tags

Stay in Touch