Hello, and welcome back to CS615 System Administration! As we're slowly approaching the end of the semester, it's now time to come back full circle and focus on one of the topics that we had mentioned way back in our very first video as being essential to the job of a System Administrator: system security. Throughout the semester, we have repeatedly hinted at security aspects of the topics we covered, and of course it's impossible to adequately cover in sufficient detail a topic as broad as "security" in just a few short videos, but as previously discussed, we are aiming to provide just enough information on a given topic to give you an idea where to look for more, to realize what aspects are the most important to understand. So let's talk about System Security... --- Unfortunately, I first have to disappoint you. As much as I'd like to, I won't be able to tell you - how to make your systems "secure". There simply isn't an easy formula, no free lunches. Throughout these videos, I hope that you will understand why that is. I also won't tell you - how to break into other systems, although of course understanding how to do that is often more than just a side-effect of understanding how to defend a system against compromise, and of course you _will_ learn a few things that are going to make it easier for you to break other systems -- such is the nature of system security. But either way, - I obviously can't tell you everything you need to know about this topic. You can take other classes that focus on many aspects of information security; you can get a degree or major in Cybersecurity, and you can work for many years in the industry and still not know everything there is to know, so here, once more, we're merely scratching the surface. So what good are these videos to you, you ask? Well, - here are a few things that I _will_ tell you, that I hope you _will_ be able to take away from this. - As I mentioned, I hope that these videos will give you enough information to start looking, to give you the - keywords and concepts that you will learn are critical. I'll try to address - a few of the problems with information security, the industry, and how we apply security concepts, since that is important to know about as well, and along the way I'll try to throw in - a few "always" and "never"s that, naturally, always, always come with exceptions and thus aren't really "always" and "nevers", but as rules of thumb -- rules of thumbs? -- are going to be good for you to keep in mind in your career from here forward. So why don't we start out with one these pearls of wisdom, shall we? --- Here we go. And this one's a doozy: Security is not an end-goal. I know, I know, not what you want to hear. Especially not if you're a cybersecurity major or otherwise involved in infosec. But it remains the truth: security is, by itself, not an end-goal. It's not an outcome. It's not something that's valuable all by itself. Instead, - security is a _property_ of a system. A property that may help increase your resilience against specific risks. And this property comes at a cost, so you are -- always -- trading off advantages against disadvantages. We'll talk a bit more about this concept of specific risks in a moment, but perhaps we should begin by sorting out just where exactly this mystical security property of "security" is applied? --- Well, it won't surprise you to know that security spans all the layers of the stack. We had already mentioned early on that security is something that cannot be added on at the end, that it needs to be an intrinsic property, part of the system, so of course we need to consider security at each layer. And we already did indeed do so, didn't we? Let's look back at the materials we've covered this semester: --- When we talked about disks and storage solutions in week 2, we discussed - the different storage models, and we noted how the abstractions from DAS to NAS to SANs and finally cloud storage incurred increased complexity and of course exposure of the data. When we talked about local filesystems, - we noted that you can increase the system's security by applying different mount options, such as mounting some file systems as read-only, some with the 'noexec' or 'nosuid' options and so on. When we talked about filesystem basics - and software types, we noted that even the firmware on a harddrive -- the integrated device electronics that give the IDE drive its name -- can be compromised, and we - played around with our shared file system looking to see just what might happen if we used up all the filespace or all the individual inodes, and - of course we discussed the standard properties of the Unix filesystem inherent in it being a multiuser system and thus requiring file ownerships and permissions, but also noting the availability of extended filesystem access control lists or ACLs. Following that, - we discussed software installations, which of course is a topic rife with security implications; the separation of privileges via - VMs and containers just like - patch management and - package integrity assurance are just some example. Talking a bit more about multiuser fundamentals, we spent some time in class discussing - different trust models - authentication methods, - as well as how users might wish to raise their privileges, all of which can of course be abused and has inherent and obvious security implications. --- When we talked about networking, we illustrated the visibility of meta information in each layer and we - saw that simply by using tcpdump, we can view not only all the data on our host, but also some of the data that is going by on the network, - which of course carries with it implications around what is possible if you're on the same layer two network segment as an attacker. We also talked about the - physical nature of the internet, and how the political landscape can shape - what traffic is allowed to pass certain networks - and whether or not the traffic can be inspected in transit. After that, we talked about the DNS - and of course quickly realized that if you can control the zone, then you control just about every other aspect of the traffic, which is why - attacks on the places where your nameserver records are registered become so interesting. We saw that the - DNS is used for all sorts of side channels providing additional information, often times with an authentication context, and we noted that unfortunately - the majority of our DNS traffic is unprotected and unauthenticated, but we did hint at some of the methods to remedy this, such as DNSSEC, DNS over TLS, and DNS over HTTPS, ...which gets us to HTTP, which we - noted as the universal entry point across all networks. We discussed how HTTP nowadays is no longer just static documents, but - code dynamically executed both on the server and the client side, with all the security implications, and we talked about how outsourcing your traffic to, say, - a CDN can have both security and privacy implications. --- Knowing how we can observe plain HTTP text using tcpdump(1) and thus seeing traffic on our network, we then talked about HTTPS and TLS to encrypt traffic in transit, leading us to - authentication of the servers via the - PKI sitting on top of a surprisingly large number of certificate authorities, and we briefly hinted at - some of the flaws we encountered in the development of the TLS protocols. When we talked about SMTP, we covered - email as an attack vector itself -- spam and phishing - which uses, or rather: abuses how the simple mail transfer protocol works, as it was developed in an era of open networks, from where we then go to discussing - the use of STARTTLS, the opportunistic approach to encryption it uses, and -- again -- the various related DNS records attempting to provide another layer of security and authenticity not included in the original protocol. - In class we then talked about developing tools, writing code, and programming in a sysadmin context, where we can utilize automation as a protective mechanism, but - need to be aware that choosing the wrong tool may lead to critical security issues, requiring - us to understand our languages and frameworks and - striving to reduce our attack surface by focusing on simplicity, since inevitably - all code we write will include bugs and we need to be careful not to introduce security vulnerabilities as we deploy our automation. --- When we talked about disaster recovery and monitoring, the connection to system security is obvious, as some of the disasters we have to prepare for include security breaches, but on a more general note, - of course any data loss is a security failure. We talked a little bit about malware that - may infect the backup systems or the backed up data itself, and brushed upon the concept of encrypting data at rest as part of our backup mechanism. In a monitoring context, - it is obvious that our ability to detect undesirable events are critical to system security and our defense capabilities, and we - need to remain aware of the sensitivity of the data we are logging, as this may contain passwords or other confidential or otherwise private data, which - may have implications on your ability to outsource monitoring to a third party provider. Finally, in our last videos, when we talked about - configuration management systems, we illustrated the use roles and service definitions, which may allow us to provide more fine-grained access controls and service profiles, but we - also noted the inherent power and thus risk in using a configuration management system, where the - CAP theorem may have direct implications on the security of your systems. So yes, as promised at the beginning of the semester, we really did include some aspects of security in every single class, and if you go back to the earlier videos after we have concluded our mini series here, you'll hopefully find a lot of ground that we did cover here as well as a lot of areas where you may now see further need to deep dive into the security related aspects. As we've found out - system security really touches everything, every topic, every problem we face, and every solution we develop. --- But... wait, so what is "security" anyway? I know, let's ask the dictionary! - Of course first of all we find that security is defined recursively as, well, "being secure", so yeah, thanks a lot Collaborative International Dictionary of English. But ok, Webster down here has a better definition: "freedom from risk" That's a pretty good, terse definition. Now within a computing context, there's a bit more to it, though. Specifically, we see a good break down here in this entry into confidentiality integrity authentication access control nonrepudiation availability privacy physical security operational security personnel security system security and network security [pause] It also mentions that encryption is one of the methods we may use to achieve _some_ security in _some_ areas, which I like quite a lot, because it's important to not _equate_ encryption with security. [continue] Oh, and of course we shall note that there is a town called Security in Colorado, population almost 30 thousand, but, you know, that's really not relevant here. But ok, so this is actually quite useful. In the next few videos, we'll actually break down several of these important aspects, but I do want to go back to the first useful definition we had seen: - Freedom from risk. This is the second time we're seeing this emphasis on _risk_, so... --- perhaps let's go and see what _risk_ is. - Ok, so hazard, danger, peril. That sounds about right. More specifically, risk is defined as a source of danger, a _possibility_ of incurring a loss. And that's really important: a risk is not a guaranteed disaster, it's the _possibility_ of something terrible happening. But to assess the impact of a given risk, --- we then need to determine what specifically is _at risk_. And there really is a number of things that we might be in danger of losing, such as - _access_ to data, such as in the case of ransomware; Or we might be concerned about - the integrity of our data, worrying that somebody might have _changed_ it. Or - we might worry about the availability of our data -- think Denial of Service. Anything bad happening to our data might also bring with it indirect consequences, such as - a loss of your reputation, meaning you'll likely lose users or clients, and of course - money makes the world go round and we might fear the loss of our sweet, sweet dollar bills due to any of the above. And in some cases, we might even - be concerned about the physical value of certain things, and in the data driven tech world that's an entirely different threat compared to the value of the data access or integrity. - But so you see that there are clearly different things that might be _at risk_, and each one is equally clearly put at risk -- and thus should be protected -- in a different manner. So in order for us to make any progress in our effort to "secure" something we kind of have to --- as boring as it may sound, perform a "risk assessment". I know, I know, that sounds like a term that could put you to sleep all by itself, but stick with me here for a minute. What do we mean by "risk assessment"? Well, first of all, we need to determine exactly _what_ it is that's at risk, as we just said. That is, we identify that which we want to protect: our assets. --- Each asset has different threats, so let's go ahead and identify those for each. That is, we need to determine for each asset just what exactly might pose a danger. --- Each threat may manifest itself in different ways. We call those ways "vulnerabilities", i.e., weaknesses in a system, a way to abuse a protocol, a tools, or even a human behavior. But each of these vulnerabilities being exploited is not a given, and not each one, when exploited, necessarily leads to a complete compromise, which is why --- we need to determine, or at least estimate, the probability of the damage, including whatever possible mitigations we may have put in place. For example, if we are concerned about data loss, but we have a filesystem that takes snapshots every minute, the probability of actual data loss is somewhat reduced. On the flip side, we have to also consider what we do when we do suffer the damage: --- How do we recover? What do we have to do to get back up and running? Do we have to rebuild systems, replace hardware, run ad campaigns to try to reassure our users of our trustworthiness...? All of this gives us an idea of how bad things might be if such a disaster were to happen, so then we need to go around the other way and ask ourselves --- how much would it cost to protect against this threat? _Could_ we protect ourselves against this scenario? What if we had unlimited resources? What are the costs of mitigating strategies to put in place? So with that cost calculation, we then come up with a few rough numbers: the cost of a disaster -- that is, how much it would cost us if it were to happen; the probability of it happening; and the cost of defending against this scenario. And with these numbers, you can then make a fairly reasonable, logical decision and determine whether it makes sense to invest in the defenses for the given scenario. --- So in other words, the way we determine "risk" is to assess the _likelihood_ of a threat _successfully_ exploiting a vulnerability and the estimated cost (or potential damage) both in the short and long term you may incur as a result. And that's a risk assessment. And it sounds straight forward, and sometimes it really is, but of course often times it takes some practice to really identify all the relevant -- and eliminate the irrelevant -- factors here. But the key take-away here is that a risk is _specific_, quantifiable. --- And most of the time when we are facing discussions around "security" in the abstract sense, it's all too easy to fall into the trap of only talking in a hand-wavy kind of way about very vague, theoretical problems. There's a lot of Fear, Uncertainty, and Doubt that can enter this discussion, so always keep in mind that in order to be able for you to address, mitigate, or minimize a risk, - it needs to be specifically scoped, well defined. Only then is there anything you can _do_ about it. --- So how, then, do we _secure_ a system? Well, the answer is: you can't. There's no such thing as a "secure" system, since, as we mentioned at the beginning, "security" is not a property of a system, and we rather need to be specific about what we mean. So instead of trying to make a system "secure", - we can only minimize or address specific risks in a variety of ways: - We can try to close the attack vector; - we can try to eliminate the vulnerability that allowed the threat to manifest itself; - we may try to reduce the attack surface even if we can't eliminate the vulnerability or close the attack vector; - or, and this is another powerful mechanism that's very often overlooked, we can change the economics for the attacker. Because remember: just like we perform a cost-benefit calculation when assessing our risk, so do attackers perform a cost-benefit calculation whether it is worth their time to attempt to exploit a given vulnerability, for example, and if we can raise the cost for the attacker, then they may pursue a different venue or be forced to retreat altogether. But in order for us to be able to do any of the above here, we need to not only understand our risk, we need to understand our attacker, their motivation, their goals, as well as our own capabilities. - That is, we need to develop and utilize a "threat model", which is a formal way of assessing just who exactly is likely to try to pursue which attack vectors to which ends. But more on that in our next video -- thanks for watching! Cheers.