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.
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.
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).
The standard mitigations for repudiation attacks include secure logs and audit records, coupled with using a strong authentication mechanism.
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?