Threat scenarios

When analyzing security features, we often look at them in black and white terms: either they can be broken or they can't.  DES is crackable but as far as we know AES is not so we recommend AES.  This is useful when we're making general recommendations because we don't know what threats everyone is going to be concerned about so it's safer to assume that we'll always need to protect against a skilled, well-funded attacker.  In many cases, however, that assumption is not true.

At Passwords 13, Steve Thomas, a.k.a. sc00bzT, gave a presentation about building a cheap hardware security module (HSM) to store and protect passwords.  During the talk, someone mentioned on IRC that what he developed wasn't a true HSM since the hardware was not tamper resistant.  While that is a valid concern, others correctly pointed out that it may not matter depending on your threat scenario.

Since it has no physical protection, Thomas's HSM is vulnerable to hardware tampering.  It should not be used in situations where that is a valid concern.  If you're worried about foreign governments bribing your employees or about a rogue employee (e.g. at a bank) being able to sell those credentials, then you should consider laying out the cash to get a tamper-resistant HSM.  But, if you're mostly worried about outsiders using SQL injection to dump your password hashes, this solution is perfect.  It's cheap and it solves the problem.


In a similar vein, Google recently explained why they do not use a master password to protect stored passwords in Chrome:

...the conclusion we always come to is that we don’t want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that’s really what they get.

The Wired article points out that, in an absolute sense, this is true but that whether this offers some protection in practice depends on your threat scenario.  If you're worried about professional attackers, then Google is right.  But, if you're only worried about a jealous lover or nosy family member, a master password does provide meaningful protection.

These anecdotes both illustrate the importance of threat scenarios.  We don't defend against vulnerabilities, we defend against attacks made by threats.  A SQL injection vulnerability is only significant because someone is out there ready to exploit it and because this action would be harmful to us.

Definition: A threat scenario is a scenario where a threat actor exploits a vulnerability and this has an impact (consequence) that we want to prevent.

Consider this: I scrap together an internal-only web application that users can use for generating reports.  The application has read-only access to a database which contains no confidential information.  Does it matter if the application is vulnerable to SQL injection?  No.  We don't care if the information is revealed because it's not confidential so there is no impact.  And, if the information has no value to an attacker then there isn't a threat (because there is no motivation).

What if the database contains confidential information but all of the users have legitimate access to it and the SQL injection vulnerability is only available after the user has logged in?  Again, what threat scenario would be be protecting against?  Any threat actor who can exploit the vulnerability already has access to the information.  Our efforts are better spent somewhere else.

The first step in determining your threat scenarios is to identify your threats.  Who are you protecting against?  What resources and skills do they have?  What are their motivations?  What are their goals?  The answers should depend on the nature of your organization.  If you're working for the Department of Energy, your threats should include state-sponsored hackers in search of information about nuclear energy.  If you're working for the local high school district, you will be much more concerned with teenagers who want to show off or perhaps change their grades.  These two threats require vastly different measures (and budgets) to defend against. 

Then, as you identify real or potential vulnerabilities, analyze them in the context of your threats.  What resources (skill, money, equipment) are required to exploit this vulnerability?  Do any of your potential threat actors have the required resources?  Will they be motivated to use them?  What is the impact if they do?  If  your threat actors aren't capable of exploiting the vulnerability, then you don't need to fix it.  If the impact is negligible or is less than the cost of the fix, it's not worth fixing.
 
A K-12 school district does not need to worry that their data or network traffic is insecure because it's "only" encrypted with DES.  Nation states can brute-force DES pretty easily but most teenage hackers, low-level identity thieves and disgruntled teachers (threats a school district would actually have to worry about) don't have the resources or skill to do so.  For instance, a GPU-based rig that can break DES in a month would probably cost tens of thousands of dollars to build and the threat actor would need the know-how to build the rig and to write the software to use it.  It's not impossible that one of these threat actors would build such a rig, but it's highly unlikely.  Most (99.99+%) don't have the skills/resources and, even if they did what are they going to gain to make the investment worthwhile? 

On the other hand, a bank using DES to encrypt and MAC wire transfers should worry.  The bank's potential threats should include professional thieves who are able to invest in or commit resources to an attack provided that the cost/benefit analysis is favorable.  These thieves may be able to purchase expensive equipment, sign-up for cloud computing services (probably using stolen credit cards) and/or purchase time on a large botnet.  If these thieves think they can modify or generate wire transfers in order to steal millions of dollars, it would absolutely be worth breaking DES to do so (provided there isn't a cheaper or easier alternative).

The motivations and goals of a threat actor are important. Threat actors will not be interested in everything that an organization has to offer.  A university might need to worry that state-sponsored hackers will try to steal information related to its government-funded research, but not that they will steal Visa numbers from the bookstore or try to change student grades.

We need to build reasonable threat scenarios that connect threat actors with attacks/vulnerabilities and then determine the impact of those attacks.  When developing scenarios, consider these questions:

1. Who is the threat?
2. What resources does the threat actor have?
3. What motivates this threat actor?
4. What is the vulnerability?
5. What resources are required to exploit this vulnerability?
6. Does the threat actor have these resources?
7. What is the benefit to the threat actor if he exploits this vulnerability?
8. Does this benefit align with his motivations/goals?
9. Does the benefit justify expending these resources?
10. What is the potential adverse impact to the organization?

For a formal approach to developing and assessing threat scenarios, see Bruce Schneier's paper on Attack Trees.