SDP 9 LEAST COMMON MECHANISM

Kip Boyle: Hi everybody. Welcome. This is Your Cyber Path. We’re the podcast that helps you start your cyber security career or accelerate the cyber security career that you already have. My name is Kip Boyle, and with me today is co-host Jason Dion. Hey Jason. Jason Dion: Hey Kip. Great to be here again. Kip Boyle: Yeah, so I’m glad you’re here too because listen, today we’ve got to talk about something actually kind of weird. Okay, so what we’re doing is we’re picking up with a series of episodes we’re doing on what’s called Security Design Principles. Now there’s 10 of them, and this all goes back to a paper that was published in 1975. I’m not going to rehash this in detail. We did a whole episode specifically on the paper, where it came from, who wrote it, and so on and so forth. But we’re getting very close to finishing this whole series. And today the one we’re going to talk about is called Least Common Mechanism. And it’s a weird one because we actually don’t use this very often in the real world. And so this may even be a short episode because we’re covering it for completeness’ sake also because sometimes it is going to come up and so you should know about it, but I don’t know that we have a ton to say about Least Common Mechanism. But I don’t know, Jason, I mean, when you first saw this, what was your first thought? Jason Dion: I first was going, “Huh, what are we talking about?” I was really, really confused and I had to read it three or four times before I could be like, “Oh, I know what we’re talking about now,” because it’s just not the way I normally talk about these things. So for me, it was just a very different and unique thing to look at. So yeah, it’s one of those ones that just sounds kind of funny, the way they talk about it. And even going to the original part in the paper, it’s a little confusing as you read it and it takes a little bit to unpack. So as you said, I think this will probably be a shorter episode because it’s not a very common one that we actually use these days, but with us, you never know. We could start talking and forty-five minutes later, we’re at the end of the episode, so we’ll see how it goes. Kip Boyle: That’s never a risk with us. Okay. Yeah, so Least Common Mechanism. And so I think maybe the best way to talk about this is just to give an example, a very simple example, all right? So here we go. Let’s consider the website of a large company that provides online shopping for their customers. It could be Amazon, could be Walmart, whatever your favorite website is where you can go and spend some money and get something cool. Now, let’s say cyber attackers want to extort this company behind the website for money, and the way they’re going to do it is they’re going to decrease the revenue that they can earn from the website. And so the easiest way to do that is to flood the site with a bunch of network traffic, a bunch of garbage, maybe they’ve got a botnet and they direct the botnet to just overwhelm the network interfaces of the website with garbage connection requests and stuff like that. And so it’s going to cause the website to severely degrade in performance. It maybe even failed to respond completely to somebody who wants to show up and buy something, okay, so legitimate customers can’t access the website. They get frustrated, they go someplace else, they take their business elsewhere. Now, here’s where the Least Common Mechanism comes into play. Because the website uses a single shared mechanism for everyone to use, cyber attackers can attack that one mechanism and bring the entire site down. So even administrators can’t get to the website if everyone’s going through the same network interface. So in other words, they have a single shared mechanism that everyone uses. And what this principle is saying is, “Okay, you don’t want to do that, right, because you’re making yourself vulnerable.” So you actually want to have separate mechanisms, one mechanism for people who want to buy something from you and a separate different mechanism that you can use to manage your website. So you have two classes of people on the website. Each one of them has their own path to the website. This actually is counter to some of the other principles that we aren’t covering in this series, but that you’ve probably heard like choke point, right? In order to simplify access control to an asset, you often want a single way to get to the asset so that you can make sure that you are authenticating and authorizing people. So anyway, this is one of the reasons why this is kind of an obscure one anyway. Jason, do you think that’s helpful? This example? Jason Dion: Yeah, I think it is. I think one of the confusions here though comes in, how would you implement it, right? Because when I first started hearing you talk about that, and you’re giving that example and you said, “Oh, we have this one choke point because the internet connection is there.” And I’m thinking, “Well, nowadays with a cloud-based architecture, I would never have that because I would have multiple connections.” Or even at my office, I have a microwave link, I have a cellular backup, I have a fiber optic primary connection, and I can shift from one to the other to the other. And that’s not what we’re talking about here, because that is not the idea of a Least Common Mechanism because we are… Having the redundancy is great and we want to have the redundancy, but what you’re talking about is alternate paths to get into that network to do different functionality. And so for example, if somebody goes to my website at diontraining.com as a student, they get one experience. But if I log in as the administrator, I get another experience. And I think this is why this one doesn’t come up nearly as often as it does in the 1970s, 1980s world, because back then each computer did a different function. And so I might have a server that does email and another server that does FTP or file transfer. I have another one that does proxying or news groups or something like that, right? Kip Boyle: Right. Jason Dion: And each of them is a single function, and none of them should be shared because if we have a Least Common Mechanism, they’re not all sharing the same. And if the email goes down, I’m not taking my file server down with it. These days though, we do so much of it in this consolidated, interconnected networking space that I just don’t see least common used as frequently as it was in the past. And that’s why I think I struggle with it when I was first reading this earlier today, Kip Boyle: And that’s completely reasonable. We have completely different tech stacks these days. When this paper was written, the internet was actually called ARPANET and it was experimental, and nobody was thinking about global, planet wide networks in the way that we experience them today. So this security design principle may be obsolete because of that. All right? But again, for completeness’ sake, we wanted to make sure you knew about it. I mean, hey, maybe this will make a great cocktail party story for you. I don’t know what kind of parties you go to where that would work. Jason Dion: And I think depending on the nature of the system you’re building, we do still use this, right? I’m struggling myself to think about in my own businesses how I would use this on a daily basis, but as I think back to some of the higher security environments I’ve worked at over the years, I could see that we’ve done these type of things and we have one way in and one way out for each user class, especially when dealing with cryptographic key storage and things like that. So I think there’s a place for it, but I just don’t think this is one that’s going to apply to every single thing we do. A lot of the other ones we talked about, they’re like, I just see every day, every system I’m dealing with, “Oh, I can apply STP 1 or STP 3 or STP 5. The STP 9- Kip Boyle: Right, open design. Jason Dion: … I don’t see it as much. Kip Boyle: Yeah, I don’t either. So let’s see if there’s anything else. I have some notes. Let me just look at my notes and see if there’s anything else that we wanted to say about this to help folks with it. So I didn’t give the actual definition out of the paper, so let me just share that with you. And what they say in here is that the protection mechanism should be shared as little as possible among users. So another way I say it is, avoid having multiple people sharing mechanisms to grant access to a resource. So if that helped you understand this a little bit better. I’m glad. I’m concerned that I’ve actually just confused people a little bit more by saying that. So if that confused you, just pretend I didn’t say it. Jason Dion: Yeah, I think probably one of the other ways that I think about this is that I avoid using shared user accounts all the time. And the reason for that is twofold. One is I want to be able to know who did something and have that non-repudiation. And so if Kip and I are both logging into the same email account, like support@yourcyberpath.com, right? And somebody responds to an email, I don’t know if I did it or Kip did it because either of us could have, but instead if he logs in as Kip and I log in as Jason, we know who sent that email. And so the other benefit of that is each of those accounts has their own permission sets associated with them, and they’ll be able to do different things on the systems based on what permissions they have. And so I think that also kind of goes into this idea of Least Common Mechanism because we have the ability to log in as Kip, log in as Jason, and if I forget Kip’s password, that’s okay. Jason can log in and reset it. Whereas if Jason forgets his password, Kip can log in and reset it, but if we had support only and we’re all logging into the same account and we forget the password, we’re now fully locked out of our systems and we’re screwed, right? And so I think that’s another way we can look at this. Maybe that makes a little bit more sense in a modern computing context. Kip Boyle: Yeah, I actually like that quite a bit. You know, Least Common Mechanism is a fairly abstract idea. I’ve been struggling to make it more concrete. I think you did a great job making it a lot more concrete by focusing on something that we do use today, which is user accounts that are unique to each individual. And thank you. I don’t want to risk this episode. I think we should end it right now. [inaudible 00:09:46]. We should end too right now. Jason Dion: Nope. I’m going to risk it. I’m going to go forward. We’re going to keep going. Not letting you off that easy, Kip. So, in your notes as you prep for this episode, I did see that you brought up a quote directly from the Salser and Schrodinger paper and you added a little bit of editing in here to kind of clarify it a little bit. And this will just show why this is such a confusing topic for a lot of people, okay? So it says, “In a multi-user system, given the choice of implementing a new authentication function that’s shared by all users or as a function that could be handled as though it were the user’s own, you should choose the latter course. Then if one or a few of the users are not satisfied with that function, they can provide a substitute or not use it at all. Either way, they can avoid being harmed by mistake in that function.” Now, what we’re really talking about here is that again, we want to have multiple ways of accomplishing something. So if one way gets locked out, one way gets blocked, one way doesn’t work for them, you’ve got additional ways to do it. Now, again, this is one of the things that you have to think about. How are you going to secure all those additional functions? We talk about the idea of principle of least privilege all the time. We talk about the ability of least functionality- Kip Boyle: Simplicity. Jason Dion: … and that’s important because the more simple it is, the easier it’s going to be to defend. And the more that we add in all these little backdoors, which again, backdoors are really popular in ’70s and ’80s and ’90s, we would never put a backdoor in today, but we did that back in those days because it gave us that additional functional level to be able to use under this idea of Least Common Mechanism. So who is this really going to apply to? If you’re working in a large organization that still has a bunch of legacy equipment from the ’70s, the ’80s, the ’90s, or the early 2000s, which I know it sounds crazy, but there’s organizations that still have this stuff running. Kip Boyle: I’m looking at you, big banks, insurance companies. Jason Dion: I’m looking at you US Military, right? And Federal Government. If you go and look at an aircraft carrier and their weapon system, it’s still using technology from the ’80s, ’90s, and 2000s sometimes because it still works and it would be too expensive to upgrade or modernize it, especially if it’s an older ship. And so a lot of these things, if you work on a SCADA system or an ICS system, it will have this idea of Least Common Mechanisms built into it. So it really is more of a specialized area for us in it these days than it used to be, but it’s just something for you to be aware of. And that’s why we wanted to bring it up in this episode as we’re trying to round out getting to the end of this 10 episode series of the Security Design Principles. And the next one we’re going to have next week is a different episode, but we come back to the last one. We’re going to be talking about SDP 10 to finalize this series and really wrap it up for us. So those are kind of the ways I think about this idea of a Least Common Mechanism. Kip, how about you? Any final thoughts as we start wrapping up this episode? Kip Boyle: Again, I don’t want to jinx it. I think you’re doing a great job of adding clarity. I don’t have any ideas how to make this more clear, and so I’m just concerned I’m going to muddy it up, so nothing more. Jason Dion: Perfect. Well, with that said, I want to thank everybody for listening to us on another episode of Your Cyber Path. This week’s episode of Your Cyber Path is actually brought to you by Akylade, which is a certification company that has the Certified Cyber Resilience Fundamentals and Certified Cyber Resilience Practitioner exam. We’ve talked about this previously, and if you’re interested in either of those exams, you can find out more at akylade.com, which is A-K-Y-L-A-D-E.com. If you want to find out more information from them, just scroll on down to the bottom, enter your email, and you’ll get an email from Kip or I, giving you more information about Akylade and how it can be a part of you and your future cybersecurity career, to help you learn more about how to use the NIST Cybersecurity Framework and the modern computing principles and risk management frameworks that we use today. Kip, any last words as we close out the episode? Kip Boyle: Everybody, I hope you have a great week and we’ll see you next time. Jason Dion: Thanks everybody. Bye.