Share via

Threat Modeling Again, STRIDE Mitigations

  • Article

I described the 6 STRIDE categories the other day.  In that post, I mentioned that there are "well understood" mitigations for each of the STRIDE categories.  Of course this list isn't exhaustive, many of these are obvious, and some don't apply, but when you're looking at providing mitigations to the threats that your threat modeling discovers, these mitigations provide a good place to start looking.

Spoofing

As I mentioned the other day, a spoofing attack occurs when an attacker pretends to be someone they're not.  So how do you stop a spoofing attack?  You require authentication (yeah, I did say that some of these are obvious:)).  Authentication takes many forms, there are a boatload of authentication mechanisms available (basic auth, digest, kerberos, PKI systems, IPSEC, etc).  Most of these apply to data transferred over the wire, but there are other mechanisms to ensure validity.  For instance, the Authenticode mechanism provides a way of validating that code has been signed.  Sometimes authentication isn't the right mitigation.  For instance, if you data flow diagram has a client DLL that is making an RPC into a service that you own, an attacker can spoof the client DLL - they can generate the RPC calls directly from their code bypassing your client DLL.  The mitigation for that type of attack is to add additional validation of the data transferred by the RPC in the server.

Tampering

Again, tampering attacks occur when the attacker modifies data in transit.  The standard mitigations for tampering attacks include digital signatures and message authentication codes.  Those work great for data transmitted on the wire, and are also valid for data stored in files on the disk.  One other mitigation for Tampering attacks are ACLs - for instance if only administrators need to write to a file or registry key, ACL it so that only administrators can write to the file/key.  Another way is validation of input read from the data source.  You need to be careful in this case to make sure that the validation doesn't introduce the possibility of a DoS attack (we had a bug in an early beta of Windows Vista where a corrupted registry key could prevent the audio service from starting - we had validation which correctly detected that a particular key was corrupted and failed to start because of it).

Repudiation

The standard mitigations for repudiation attacks include secure logs and audit records, coupled with using a strong authentication mechanism. 

Information disclosure

Information Disclosure attacks occur when the bad guy can see stuff they're not supposed to be able to see.  Standard mitigations include encryption, especially for data transmitted on the wire - for example, RPC provides a fairly robust encryption mechanism if you specify the RPC_C_AUTHN_LEVEL_PKT flag when establishing an RPC connection.  Other mitigations include ACLs (again).

Denial of service

It can be difficult to mitigate some classes of DoS attacks, but again, there are mechanisms that can mitigate many of the classes of DoS attacks.  For instance, you can use ACLs (again) to protect the contents of files from being removed or modified (which also protects against tampering attacks), you can use firewall filter rules (both internal and external) to protect against some network based attacks, you can use disk and processor quotas to prevent excess disk or CPU consumption.  In addition, there are design patterns that allow for high availability even in the face of active attackers (you'd have to ask server people for details, but they DO exist.

Elevation of privilege

To mitigate against EoP attacks, once again, you can use ACLs and other forms of permission checks.  But (IMHO) by far the most effective source of protection against EoP attacks is input validation - if the input is verified to be correct, it's harder to cause problems (not impossible, but harder).  On the other hand, you also need to be very careful about your validation logic - it's quite easy to get it wrong.

 

As I said at the beginning of this discussion, these are just rough outlines.  Many of them don't apply.  Since I'm working on building the PlaySound threat model, I'll take two examples from that threat model:

  • For the PlaySound API, repudiation threats aren't particularly applicable.  As such, Repudiation threats are considered to be an acceptable risk.
  • Tampering threats aren't particularly relevant to any of the data flows, because they're all in-proc.  The only way that an attacker could manipulate the data flows is if they had injected code into the current process, and in order for them to do that, they need to be running at either the same or a higher privilege level - the Win32 process object model protects us from those threats.

 

Next: How do we use STRIDE?

Comments

  • Anonymous
    September 05, 2007
    The comment has been removed

  • Anonymous
    September 05, 2007
    Seriously, who cares? Shame on your company Larry: http://www.neowin.net/forum/index.php?showtopic=584427&hl= This tool was of great help to admins of SOHO networks with slow Internet connections and now it is gone. I already asked Raymond the same thing and now I am asking you -- do us a favor and please don't blog about security issues anymore. Your company obviously doesn't care if we update our Windows' with those latest patches or not.

  • Anonymous
    September 06, 2007
    Igor, I care about this stuff passionately.  And I blog about what I care about. I have no idea what the deal is with autopatcher, and have no opinion one way or another.

  • Anonymous
    September 06, 2007
    Larry, Will your follow-ups on STRIDE cover a bit deeper the mitigations ? One of our book-of-the-quarter choices was "19 deadly sins of Software Security". The authors really harped on some of the points you made (authentication, encryption, etc) saying: "Lots of folks say use it. The problem is everyone uses it wrong." Meaning encryption in the wrong places, authentication that is spoofable etc.  Just realizing the need is 10% of the battle. Correct implementation is where we earn our pay.

  • Anonymous
    September 06, 2007
    A good point.  If I get the bandwidth later on, I'll spend some time talking about that.  I liked the 19 Deadly Sins book - IMHO it wasn't nearly as good as Writing Secure Code but it DID provide a good overview of the problem space. You're right that a good mitigation is critically important and that a bad mitigation is sometimes worse than no mitigation.

  • Anonymous
    September 07, 2007
    In my last couple of posts , I've talked about the STRIDE categories. As I mentioned, STRIDE provides

  • Anonymous
    September 11, 2007
    Adam Shostack here. I've been meaning to talk more about what I actually do, which is help the teams

  • Anonymous
    September 18, 2007
    I've been writing a LOT about threat modeling recently but one of the things I haven't talked about is

  • Anonymous
    October 01, 2007
    I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah,

  • Anonymous
    October 01, 2007
    I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah

  • Anonymous
    October 01, 2007
    The comment has been removed

  • Anonymous
    October 01, 2007
    Thomas: The DRM team has their own set of threat models that are about DRM breaches.  But a DRM breach won't generate an MSRC advisory (it might generate a WU download, but MSRC doesn't care about those).  The threat modeling process I described is about analyzing the system to mitigate the security threats to a system. In all honesty, I intentionally chose an example that only peripherally involved Microsoft to point out that this process is universal, and has benefits outside of Microsoft. Microsoft has already done many articles disecting Microsoft flaws (Michael Howard has done several on the .ANI vulnerability, for example).  But security is an industry problem.

  • Anonymous
    October 02, 2007
    The comment has been removed

  • Anonymous
    October 02, 2007
    Thomas: Actually, for the Vista audio stack, DRM doesn't really affect the design at all.    There are a couple of APIs added that allow the player to interrogate the state of the audio stack and that's about it. The player itself is complicated by DRM, but not the rest of the multimedia playback infrastructure.