Hello, and welcome back to CS615 System Administration! This is week 11, segment 2, and we continue our discussion of System Security. In our last video, we talked about the concept of "risk assessment", and we concluded that rather than try to "make a system secure" we should instead be a bit more realistic and perform a proper risk assessment, whereby we seek to identify specific risks that we can then try to minimize. But we noted that in order to be able to do that, we'd need a "threat model". So let's talk about _that_. In this video, we'll define what a threat model is, how we can formalize this model, and most importantly, that it's imperative to keep the attacker's motives and capabilities in mind. Much of the content here in this video is derived from an introductory conference talk I gave a few years ago, so you can also refer to the blog post write-up included in the links for additional context. --- But ok, so let's get started. Similarly to how we perform a risk assessment, for a proper threat model, we also need to begin by - identifying just what exactly it is we're protecting. As we mentioned the last time, the different assets we have will likely lead us to identify different types of threats and vulnerabilities, but we didn't really discuss just - who it is that might attempt to exploit a given vulnerability, and that really can make an important difference in determining your mitigation strategy. It's important to keep in mind that your attackers are actual human beings with - very specific goals. You are not attacked willy-nilly, but generally with very specific intentions and desired outcomes. That is, different attackers - have different motivations, and, perhaps more importantly, different attackers - have different _capabilities_ to execute types of attacks. We'll get back to this in a few minutes, but hopefully it's obvious that an individual frustrated teenager has a different objective and ability to harm your assets than a nation-state attacker with a literal army of highly trained experts and a military industrial complex at their service. And perhaps this also gives you an idea that - there are some things you simply _can't_ defend against, and that it's not useful to waste resources against something that you can't do anything about. --- In this context, I always like to refer to this wonderful article published a few years ago in the Usenix "login" magazine by James Mickens, which summarizes the concept of a threat model rather succinctly: If your concern is that a scorned lover breaks into your email, change your password; if your concern is that criminals are trying to take over your account, don't click on links sent to you via email that then ask you to log in to a site without using your password manager or multi-factor authentication, but if you are facing a capable and motivated intelligence agency, chances are you aren't going to be able to defend yourself. Well, now that of course is a bit nihilistic, and while this is true for most people, for system administrators and people working in the information security industry, we actually _are_ interested in defending against such adversaries as well, so it'd be nice if we had something a little bit more formal to define our threat model process, an approach we can follow beyond passwords and magical amulets. So let's try to break this down a bit: --- First of all, we begin by identifying the possible threats we know about. Then -- and that's right, we're back to drawing Venn diagrams, --- we're looking at what kinds of threats we actually care about. For example, we may not _really_ care about the physical value of the hardware in question. That is, if an opportunistic robber manages to scurry off with the servers in question, we don't really care about the monetary loss of the hardware. It's the data we're primarily concerned about, say. --- Next, there are some threats that we can defend against. This is the tricky part: we have to be honest with ourselves and decide, consciously, what our defensive capabilities are. For example, when outsourcing hardware management to, Amazon EC2, we understand that it's possible that a capable adversary may legally force Amazon to install a backdoor in the hypervisor that our VMs are running on, but we implicitly accept this threat as something we cannot defend against given our current capabilities and infrastructure requirements. Accepting certain threats as outside the realm of what we can defend against does not mean we simply throw our hands in the air and give up, but rather that we are being realistic and decide not to waste time and money on efforts that would ultimately be futile. --- So from these circles, we build an intersection of threats we then decide to defend against. Necessarily, that is a subset of all the threats we know, and an intersection of threats we care about and can defend against. --- That means that there will be some threats that we know about, but don't care about, or some threats we don't know about but wouldn't care about if we did; in those cases, that's not a problem, since we have consciously placed those to be outside of our threat model. --- The threats that we know and care about but decided not to do anything about are then what is commonly termed the "accepted risk" -- you understand that there _is_ risk, but you are willing to take it. --- Sometimes this decision is forced on you, simply because you _cannot_ defend against this threat, as in the example I gave a minute ago regarding a hardware compromise of EC2 VMs. --- So by and large the objective of your threat modeling exercise is to increase this intersection wherever possible, and you should be careful --- not to waste time and effort on threats you can't defend against anyway, --- especially if you don't even care about a given threat. --- Although sometimes you may deploy defenses just because you can, but the biggest issue, of course, is --- that there are some things you don't know about, and it's particularly hard --- when there are threats that you _could_ defend against had you only known about them. For this reason, it's so vital that as System Administrators we continuously keep up to date with the developments in the industry and the information security space. But all this is still very abstract, so let's take a look at a --- more formal model that can help you identify the different threats. One of these models is "STRIDE", which maps specific threats by category to a given system property: - Spoofing, for example, is a threat against the Authenticity property, - Tampering against Integrity - Repudiation against Non-repudiation - Information Disclosure against Confidentiality - Denial of Service against Availability - and Elevation of Privileges against Authorization. For each property, you can then begin to enumerate vulnerabilities. --- which might look like this. As you can see here, you might break down your data model into the different properties, and identify where threats against the "Confidentiality" property might manifest. --- Each of those areas then can be broken down further to identify much more specific threats, --- which can be done with increasing detail as needed on each layer, --- Until you've mapped out a nice graph of all the things that might go wrong. Cool, so this allows us to zoom in and out of different system components, without getting bogged down in trying to "Secure All The Things". But in this part, we are merely enumerating threats. How do we figure out what to focus on, then? --- For this, we can use the 'DREAD' methodology. (Yep, infosec geeks like acronyms, what a shock.) DREAD allows you to assign to each threat a numeric value determined by asking these questions. Here, we assign a numeric value to each of the attack's - Damage, - Reproducibility, - Exploitability, - Affected Users, - and Discoverability. Some people then also like to add --- another factor: how hard it iѕ to detect the given compromise. You can then assign values to each vulnerability based on these factors and the value of the asset. For example, pick a number between 1 and 10 to assign to each, average the DREAD+D score and multiply it by that value. The resulting scores should give you an idea on which areas you should focus on. --- Here's an example DREAD+D spreadsheet. I have a link to the Google sheet in the slides, so you can check it out or copy it to play around with yourself. You see that we have here a definition of the assets in the - "integrity and confidentiality" category, where we are identifying different trust boundaries and then assign them a numeric "importance". This can then help us prioritize our defenses. We also iterate over the list of possible threat actors, which helps us clarify just what different objectives our adversaries might have, and what methods they might commonly use. Each threat actors has a number of additional attributes that help us clarify what they might be capable of and how they might usually act. Now with all this defined, we then use DREAD+D over here on the left to itemize the individual threats and then assign them numeric values for each of the Damage, Reproducibility, Exploitability and so on. Averaging these numbers and multiplying by the asset importance then yields a final numeric score, which tells us that our most critical area to focus on here would be defenses against SQL injections, library vulnerabilities, and account compromise. --- And of course no discussion of a proper threat model would be complete without a reference to this xkcd comic. I think it's great because it shows so succinctly that there are certain threats you can't well protect against. Strong cryptography only works against cryptographic attacks; sufficiently motivated adversaries will find the weakest part of the system, frequently the human component, and attack that. --- By the way, the human component is not only easily attacked with actual physical violence, but offering large sums of money can also easily get you a compromised account -- which of these methods is employed depends again on the attacker in question. It's another example of how attackers will go for the lowest hanging fruit. Attackers will continue to employ the cheapest, most effective attack until it ceases to be that. Nobody is going to burn a $1M 0-day if they can compromise your infrastructure with a few simple PHP or SQL code injections. --- That is, your attackers also have a cost-benefit calculation they themselves follow: they also have something to lose, and they will act rationally within their moral and economic frames. Attackers will continue to pursue a given angle -- an attack vector -- for as long as the value they derive from it is larger than the cost to them. The more time and effort they have to spend on an exploit, the less likely they are to continue to use it. --- One way to shift this in your favor then is to raise the cost of the attack. Make it harder for them to get to the system. Multi-factor authentication, for example, significantly raises the cost of attack. --- But here's the other thing you can do, and that’ something we all too often forget: we can reduce the value of the asset. Anonymize your user data. Delete your users' private data after certain periods of time. Expire authentication tokens or key materials. Reduce the lifetime of your TLS keys. All of this is super effective. --- So, to summarize our threat model process - identify assets, assign values Note: these values can be largely arbitrary, but you should be consistent within your organization and threat model as to the scale. In my example, I picked numbers from 0 to 10; you could use a larger scale if you need more granularity, for example. - use STRIDE to identify threats - and DREAD+D to derive a threat score. If you're consistent in your use of these numbers, you then get a neat little list of things sorted by priority, what to focus on - in your defenses. Now the most difficult part in threat modeling is retaining your focus. As we've seen in our examples, you can zoom in and out on various components, and while you frequently outline your threat model in abstract terms, you may need to go into specifics as you translate it into specific recommendations. --- When you try to perform these assessments, it's good to keep in mind that you can't defend against all threat all of the time. Prioritize and pick your battles. - Remember that attackers will always go for the lowest hanging fruit, so don't try to shoot for perfect security everywhere, but stop the bleeding first. Focus on what matters. - Raising the cost of attack – not eliminating the entire threat – is frequently sufficient, because your adversaries are people, too. They will make rational decisions as they pursue their goals. Understand their goals and objectives, and you can better focus your defenses. Ok, I think this about wraps up our quick intro to the concept of threat modeling. With that now in our tool belt, we'll take a look at a few core principles in information security in our next video, where we'll discuss the Zero Trust model and look at how cryptography can help us raise the cost of the attack. Until the next time, thanks for watching! Cheers!