Threat Modeling Again, STRIDE Mitigations

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.

we recently switched to Authenticode to verify program updates that we downloaded automatically. Before, we used a proprietary private key authentication via CryptoAPI, with the self-issued certificate compiled into the program. But Authenticode certificates issued by Thawte or others expire every year or two, so instead of doing a binary compare of the certificate, we now have to use the organization string. To me, this seems to be quite prone to imposter attacks, basically someone going to Verisign pretending to be us by faking some documents. Any thoughts?

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.

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.

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.

If a user runs as an admin, they don’t need to tamper with your data store – they can do anything that they want with the computer."""

I think I (unfairly) criticised the article for being tactical ("you might as well trust admin, cos if admin is compromised you’ve already lost") rather than strategic ("how can we get users to stop logging on as admin").

There were quite a few suggestions on using ACL’s and admin privilege to make trust decisions. I’d be hesitant to assume that, jsut because something _looks_ secure, it is. Someone might be able to execute a limited privilege escalation to make data look trusted, and then in turn exploit this trust to further attack the system.

In both cases the attacker makes the system behave in a way it shouldn’t. The same vulnerability that allows someone to breach the system to circumvent DRM may allow someone else to breach the system to compromise the users security; formatting bugs were just bugs until someone started using them to smash the stack.

"""I could have picked on the Apple .DMG file woes just as easily """

That’s kind of my point: why pick on someone else’s products?

In your article you even point out that, having no connection to the FireFox team, you’ve had to guess at some of the detail.

Wouldn’t it make more sense to talk about an in-house vulnerability, where you (presumably) _could_ get access to the developers and make the article much more informative?

Again, I was (wrongly?) looking for a strategic, company wide approach. Dispassionately dissecting a Microsoft flaw would have given the article (and Microsoft’s security push) more credibility. Instead, it just looks like one more FUD campaign…

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.

To me, DRM is the ultimate security challenge: defending the system against the user. The attacker not only has full access to the system, they have the complete cooperation of the legitimate user (as they are the same person).

Excluding it from consideration feels like cheating.

Also, I assume that DRM places constraints on your design.

DRM might require you to accept/produce/keep a token to get permission to play something. This adds more entities, more boundaries, more data, more paths….

DRM may also also introduce time constraints, a whole new can of worms.

At the very least you have to evaluate your design in light of those constrains to make sure you don’t break DRM.

I agree that security is an industry problem, though something about glass houses comes to mind…

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.