 It's noon. Let's get started all the way through this section today. But who knows? So can somebody summarize where we left off on Thursday? We were defending a house and deciding what that meant as far as what we had to defend against. That went into what our goals would be and now our policies and how we're going to structure those policies. So we came up with policies, what we wanted to be allowed or not allowed in our house scenario and we discussed and came up with mechanisms to try to enforce that. And then we talked about some of the pros and cons of those mechanisms. Sometimes they didn't line up exactly or do exactly what we want, but they were pretty good nonetheless. What about the different types of security policies? How to actually define security policies? The policy language, what do we talk about policy languages five days ago right now? Yeah, so example was xml is a policy. So xacml is a policy language. And the idea there is you kind of have both world parts. Yes, there is some English natural language in there, but if your policy is explicitly defined in a machine readable format so that other systems can consume them and use them. Perfect. All right, so how do we know if our security policy is correct? What do we mean by correct? Yeah, so it does what we want it to do, right? So kind of similar thing when we think about our programs being correct or not, right? They do what they're supposed to do and what else? Is that it? Does it just do what it's supposed to do? It doesn't introduce any more. It doesn't do anything else that it isn't supposed to do, right? So you've got a door that lets you in if you have the key and that would do what it's supposed to do, but if the door just happens to swing open if you breathe on it, then it's probably doing more than you want it to do and so it's not really what you want, right? So how can we determine if our security policies are correct? Is this easy? Sounds easy, right? Do you know when your, how do I know when your programming assignments, your professors in class, how do they know when your programming assignments are correct? They use test cases, right, to do what? It produces the correct answers, it produces what it's supposed to produce as outputs. For all inputs? Not for all inputs. They test if certain outputs fail based on that kind of stuff, certain outputs pass based on the inputs and all that kind of stuff. Right, so the test cases are defined inputs with known outputs and the policy is essentially there that if your program has given this input, produces this output, then your program is correct. Does this prove that the program is correct? No. Can't test every case. You can't test every case, right? So there could be a case that you're not testing, which I know from a fact happens a lot of times in programming assignments, you say, oh I'm failing these test cases, why my program looks correct to me, we tap. I mean it's a black box approach, you actually don't see how the code's functioning, so technically you could be programming it to take known outputs and outputs, but you're supposed to know it, but can't handle situations outside of that selected situation. Right, exactly. So this brings up the case where you have, and I've actually seen some, well, not too much of this, but you could just write a big switch statement that if it sees this input, output this output, if it sees this input, output this output, so you haven't really built anything except to solve the past these test cases, yeah, in fact. Your security policy could be used for something that was unintended for a key to elaborate? You were expecting people to come through building, but it's not really different for their children. For a human dressed up as a dog or inside a trojan horse. It's a trojan horse idea, right, so something that does not look like a person that maybe now made a security policy, so what would that, what's the problem of the security policy there? Is it a problem of the security policy or is it a problem of the implementation of this policy? I mean I would think it'd be a little of both, right, like, because not in order to, you just have to be thorough on what inputs you think you might be getting. You have to try to think how your program would be broken and etc., and so in both implementing the policy and the policy themselves, you have to try to be thorough and specific with it. Right, so yeah, so there's kind of, well, when you say, hey, only authorized people are allowed to enter or exit a building, let's say, going back to our building analogy, there's an implicit assumption in there that you can define, you can identify and know what a person is. Right, so this kind of is that idea about what if a dog, you know, real dog shows up, or what if a mechanical dog shows up, or what if a drone shows up, what if a human dressed up is one of these things. Right, so if we think, okay, if we want to talk about the correctness of our security policy, did we make any assumptions, so in our housing example, did we make any assumptions there, so we just talked about the people, defining what people. I assumed it was in the United States. We assumed in the United States, how does that change your assumption of the correctness of the security policy? Other countries are less civilized than ours, unanticipated events are now authorized persons that list might change more frequently based on what the government says in another country. Interesting, so yeah, we'll talk about that in a second, but we can generalize that, because laws are different in different countries, so we've been talked about authorizing fire personnel, law enforcement officers to enter our building, or our house, right, so that means change depending on the laws of the country. Well, going back to the dog, like the human in a dog suit, we kind of assumed that everyone is who they say they are. We assumed that a police officer is a police officer, firefighter is a firefighter. Yeah, so we assumed that we have some way of actually identifying that people are who they say they are, me, so yeah, so that's difficult, right? So somebody can, this actually happens when I get interviewed by FBI agents for security claims just for the students, they'll come and they'll be like, hey, I need to talk to you about something, so I'm like, oh yeah, I'm a federal agent, here's my, you know, my badge, okay, what am I supposed to do with this, like I'm not a, it's gonna be 100% fake, I'm gonna keep the card, I remember the person, but you know, I'm not going out and verifying that on some database that it's actually this person who they say they are, they have this badge number, I mean, all that could be fabricated for all I know, but I'm not saying anything crazy to them, so it's okay. What else, any other substance? For instance, there's like, you know, that we're in there only one country's law, so if you're talking about a house, it's a kind of situation, because I know there's some houses here that are literally on the border of a few different countries, and have to actually deal with a law that's literally in one country and once I pass it to another country, that's crazy. Yeah, I wonder if you get in trouble by moving goods across the borders, so okay, so you've got laws that are definitely more complex, you can even take the US case and say, well maybe the house is in the US and it's actually on embassy property, so technically that's not our sovereignty, and there's all other laws and things that apply here, I don't know, all kinds of crazy stuff there, so what other, what other assumptions? Yeah, so we had, we definitely assumed things about the environment, and if we were really serious that, hey, these mechanisms are key to ensuring our security policy, we need to know how those mechanisms can fail, and what assumptions those mechanisms are based on, because that is something that an attacker could potentially cut, so what happens if they cut the power to our house and our security system goes down and our awesome smart lock system also goes down, right, do the doors just wide open at that point, what happens? So kind of these, these, we talked about a couple of things, right, so we're assuming essentially that the policy is correct, so this kind of goes back to the people and being able to identify people, right, so there's an assumption there that the policy is correct, so how do we verify that the policy is correct, was that, so one thing would be test cases, like a program, so how would you create test cases in this scenario, what was that? How would you create a test case for this, like a program is easier, you have input, you have a program, you feed them, but to the program you say, if the output is what I expect, then the program casts this test case, so how can you do this for a security policy? Higher or somebody to do it for you, that's what I'm training you to be, so you can be higher. I wasn't going to say that. Higher someone to break in? Yeah, okay. You have to access the database, like you have a database that you're constantly getting validation and checks from. Validation and checks from where? Well, like you have a database or in the case of like how do you know this, our policy is correct, and you want to, you need to have store who are valid, like who are valid, so the policy is like, hey, go to check this database, like you said, you can't just say it without that. But how do you know that that policy is correct of stating that the people in the database aren't authorized users? Yeah, the back. So, if you have a policy and the policy is to try and prevent something from happening, then you should try to execute that because I think it's trying to prevent to see if the policy actually does prevent it. Well, does the policy itself actually prevent anything from happening? No. No, because the policy is just what? Words or a mathematical formula, right? A policy is just a statement of what is or is not allowed. So, we can think about this in two ways, right? So, we can use that idea, but apply it instead to a concrete implementation of the mechanisms enforcing the policy. We can instead take that idea and apply the threats that we've already thought about and work through in our heads, okay, would this policy counter this threat? Would this policy counter this threat? So, essentially the threats that we've already come up with can be our essentially our test cases to try to say whether the policy is correct in some sense. And remember, it's correct against our threat, what we consider we'll get into risk later, but it's all contextual, right? So, depending on where the house is located, we may have different threats that we care about. If I'm storing, like if you think of Fort Knox essentially as a house, right, that needs to be secured, they have a completely different threat model than you would have in your apartment, right? So, they're considering thinking about different threats than you are. So, we have the policy is correct. So, we can test the policy. If we have the policy written in a mathematical language, then what could we possibly do? Build the mechanisms described in the policy and test those? Is that kind of the same thing? Not yet. We can write proof. So, if it's mathematically described, we can try to actually prove that this policy is correct. What's the difficulty there? Was the response being able to do a proof? Yes. In general case or in a specific case. So, you could do this, right? But what's the difficulty? What are you trying to prove? Yeah. Yeah. So, it may not be, well, so you have to think. So, we've lifted the policy into kind of this abstract math language, right? So, we can manipulate the policy. What else do we have to lift into math? So, we have the policy is formally defined. What are we trying to prove? That doesn't work. We said it. Not thinking about mechanisms now, just policies. That is correct. That's correct, right? So, remember, talking about working is just different than correct. It's similar, but, right? But we want to prove that the policy is correct. So, we've lifted the policy into a mathematical language. What do we need to do with our notion of correctness? We need to actually be able to describe that mathematically, right? Because we can't prove something that we can't express in our mathematical formalism. And so, therein lies the problem, right? So, if we can accurately specify our notion of correctness in mathematical terms, and we're confident that that mathematical expression is actually what we want to prove, right? This is always the problem when it comes to using math and using formalism to try and prove something. You could prove that this system, this policy is correct. But if your correctness notion is not exactly what you want, you're still kind of the same problem. So, these are all different sides of the same coin that can help you think about this kind of thing. So, then, there's the other aspect that we've been talking about is that the mechanism actually implements the policy that we want, right? So, now we actually have a system, we've designed mechanisms to implement this policy. How do we know that those are correct? So, what do we care about with the correctness here? So, that the mechanisms you're using actually work for the policy objectives? Yeah, so that the mechanisms that we're using correctly enforce the policies. So, this kind of already assumes that the policy is correct, right? So, here we're just focused on, do these mechanisms actually implement the policy? So, how do we do this? So, we've talked about some ideas, but... So, how would we... How would you try to convince me that, yes, your mechanisms are correct? Well, just test case, like, take the house analogy. If you're trying to keep somebody out of the house, by using a key, you send people to the house to try to get in the house. Without a key, yeah. Or if you're trying to keep somebody out of your website, you send people there to try to get in. Yeah, any other ideas? So, we can maybe, similar to the test case, we can actually create real threats and launch them at the system, control threats that we control, right? And see whether they can bypass the mechanisms and ultimately bypass and invalidate the security policy. Is that all we can do? What's the problem with that approach? Oh, sorry, can I get it back? Yeah. I was going to say you have to make your weight and development. So, there may be correctness in the mechanism itself, right? That's a good point. So, we care not only does the mechanism enforce the policy, but does the mechanism actually do what it says it does? This would be, especially if you're buying something non-standard, right? So, if you're buying a lock for a door, I think you can be roughly safe that it does what it says it does. If you're buying some software security product that's telling you it's going to find every single intrusion into your database, that may be a claim that you want to verify or get some notion of how good it actually is. So, you can separate the marketing claims from what it actually does. It's a great point. So, yeah, so this, I don't know that I'd necessarily say that. I think you need to have a notion of correctness that the mechanisms are working together properly, right? And as you have more and more mechanisms that are interacting, now you need to verify not only do they each work correctly individually, but that collaboratively they also work together, right? You may have 10 different mechanisms, but if they all rely on, let's say, your security camera, then if I hack in your security camera and disable that, then the other nine mechanisms are useless, right? So, you want to understand these intermixings of these mechanisms. Can you say possibly in that the mechanisms themselves also need to be secure because if they're not secure, then they could actually be involved in security? Yes, I would say that, I would phrase that more by going back to the notion of correctness of the mechanism. Yeah, so the mechanisms do what they say they do and nothing more. I think that kind of encompasses security in there, but that's a great point, yeah. Yeah, you'd want to. So, a mechanism that is faulty or broken could, at the best case, is useless at the worst case that allows an adversary another avenue into your organization. So, it could actually negatively impact security because you install this stupid security camera that is accessible from the internet, but with a hard-coded password, right? That would kind of be a good example there. Cool, so we can, so we talked about, we can actually instantiate, like pay someone, so this is consultants coming again, right? You could pay somebody to test your system to try to break into it, to try to violate a policy. What's the downside there? It's expensive. It's expensive, yes, that's probably, hopefully why a lot of you are in here and are going to be pursuing a security job because it's a field that pays a lot because you need a lot of expertise and how to bypass these things and you need this adversarial mindset. So, it's expensive, what else? Yeah. You can break something? They could break something, yeah, so you could actually maybe damage the system or cause something to go down, yeah. If they, like, report or tell the people this, that have made any various purposes before you're able to have it. Yeah, so there's trust, that's actually part of what you're paying for in your payment is you're paying not only for the form of the service but their silence of the results that they found. So usually as part of your agreement with the company, it would be confidential, but you have to imagine what's this coming, you know, maybe you're such a high-value target that it's worth them burning their entire reputation to break into your organization. I mean, I think we're assuming that they are more skilled than we are by the fact that we're hiring them, but how do we verify their correctness? Yes, there's actually a huge problem with hiring security consultants, is they can, just like the PR of some security product, can tell you it's amazing, it has 100% effectiveness. So, I mean, you can stand up in front of me and say, I'm a security expert, I have my CISSP certification, I have these five other certs, I've been doing this for 10 years, and you pay them, you know, 200 grand or something, and then they just go and run a tool against your website and print you out the exact report from that tool and take the job you got somebody to actually just like press a tool against your website, but they didn't actually use their full knowledge and capabilities as their own. Yeah, in the back. You have a policy for bounties, like for instance, if someone actually does hack and do it and they say, well, I found this, plug in your system and you pay them something. Yeah, that's interesting. So, we could, to generalize that a little bit, so we could maybe create some policy that said, hey, if you bring into our system and you do no harm and you tell us how you did that, if we agree with your findings and we fix it, then we'll pay you some monies. That can be a way to kind of open up, rather than hiring one person, you can kind of just leave that out there. What does it say about security of your system, that in general? So, these ideas of hiring or getting somebody outside to try to find a flaw in your system. Yeah. Reduce the risk. Reduce what risk? Of being incorrect. Of being incorrect, what was? So, of the implementation of the mechanism and security policy. So, if they do in what, so if they come back and say we didn't find anything, it would. Right. It doesn't guarantee it. It doesn't guarantee that there are no flaws in that implementation, but it does reduce the risk, hopefully, if they're credible and meet all the other stuff that we talked about, that they've reduced the risk that there is, that it's not correct. I see. So yeah, I think the way of, I wouldn't say it reduces the risk, necessarily. I'd say it increases your assurance that the mechanism's actually enforced your policy correctly. You may also say something about the company itself if they find something or don't find something, right? So, just because they can't find something doesn't mean somebody else or bad guys cannot find other ways. Yeah? I think that one of the issues of, so you build a whole system and you hire somebody to test it, you've already spent a ton of money in development and you don't even know if it's secure or not. Yes. Like, so why not build something secure up front? Yes. Do all that before you have to get to the point of penetration test? 100% agree. So, this is kind of, it goes back to what we talked about policies, right? We can think about the threats, articulate the threats against them and be explicit and argue that, yes, this policy will combat this. We can do the same thing with the mechanisms, right? I mean, we can kind of take an idea, okay, if the mechanism we're assuming it does X, Y, and Z, and if it does, then that prevents this threat. It prevents this other threat. So you can go through the threats that you've identified. And yeah, so going back, you want to do this at all stages, right? So you want to, you can analyze the security of the design of a system. You can, and we'll talk about all these different aspects. That's a great point. Yeah, so if your only idea of security is, hey, I'll build something and then somebody else will tell me later if it's secure or not, I guarantee you they will say it's not secure, right? You have to think of, and you have to think about this at every stage of the, say systems development lifecycle. So trust. Who do we trust? So if we put locks on the door and we say that these locks, so our policy would be something like only people with the key could access our house. So we talk a lot on Thursday about this means that we have to trust the people we give the key to, right? That they won't give it to anybody else. We have to make sure that we keep the key safe. Who else do we have to trust that I don't think we talk about? The person who made the lock. Yeah, why do we need to trust that person or company? What are you worried about with them? Make sure they don't have much extra keys sitting around. Yeah, that they didn't make an extra key that they have. So that's really good. So the person who made the lock, who else? People who have keys, who else? Anybody that would be locked out of their house? What do you do? We call it a lock set. Then what does the lock set do? Crawl through the dumps in the lock. Huh? Yeah, comes to your house and has professional tools to pick your lock, right? And let you into your house. Right? So what are you trusting there about your policies and your mechanism in respect to the lock set? He won't come back later and make himself at home on your own? Yeah, well, I guess you're assuming that they could do that at any point, right? Regardless of whether it's before or after you hire their services, right? But you're trusting, essentially, yeah. Yeah, you're trusting that they're going to verify that you actually lived there before they let you, right? I don't know. I think it probably varies state to state about what the actual requirements are. Maybe it's an ID that you can show that has your address on your driver's license. Again, we get into trust issues because then you have to trust that like, how does a locksmith verify that your driver's license is not a fake and a difficult problem. So there's trust built in, right? So why do we care about understanding the trust here? Yes, either so it doesn't conflict with our policy or that we're aware of it when we think about it and consider the threats, right? So maybe for our house, we're okay with trusting locksmiths, right? We would want to be okay trusting locksmiths and that is fine. That's part of our security analysis and we'll get to like risk, risk analysis, right? A tie value target may not want to do that. So they may want to get locks that are anti locksmith proof or something. I don't know if those exist, but you know you could try. Or you could add other mechanisms on top of that that would tell you if a locksmith was about to get in your your place. So mechanisms, we talked about different types of mechanisms. The one that we focused on a lot is technical, right? So this would be a lock, some piece of software, some part of the operating system. So what are other types of mechanisms? Do we even care about them? With TV on. And having toys coming from inside of the house that you're about to break in if you might be good to turn. Yeah, so it has some technical component, but it also requires a behavioral change on the part of a person, right? A person has to actually turn that on before they leave. Any other examples? Yeah. Do we have like a guard or someone watching it? So like a yeah. So some I know some communities will have this. They'll have a security person like driving around or don't vote the proper term for those people. I was going to say rent a cop, but I'm not sure where that falls on the correctness scale. Yeah. So you may and so then you're trusting that this person is actually going to do their job and actually drive around not saying what place is going to call in anything bad that they see. It isn't going to be bribed by some criminals to get free access to the whole place. Yeah. Absolutely. Yeah. So you're trusting kind of the judgment of that that person of when to escalate things. What other non-technical mechanisms do there be? Yeah. I think we saw this last week when we can have psychological mechanisms where you could sign stuff like the alarm systems that we built in here. Yeah. Yeah. So psychologically trying to that technically won't prevent or protect anything, but are trying to manipulate the psychology of your attacker to try to say like, I know you will get caught and that way that's a good example. Yeah. Maybe like so if you're like posting a Facebook when you're on vacation and it makes you a target it's not like you're doing that. Yes. So that would be so changing your behavior. Just I think about this all the time whenever I like call on a Uber to come get me to take you to the airport. You're like casually chatting because you're a person and they're not self-driving cars yet. And they and they say, oh yeah, I'm going on a trip and then you realize, wait a minute, they literally just picked me up for my place of residence. I told them I would be gone this weekend. Man, luckily I don't look like I have much. So yeah, and people would do this. There's I think bots that they can write and do that will track your location that you're posting from on Twitter. If it's not where it normally is though criminals will know, hey, you're actually out of town. And so they'll try to hit or rob your place then. The location. The location of the house because I think there's some house with a breakdown that you need to treat or something versus a silence. Yeah, so hiding information. So that would be a less technical. Maybe we have big bushes around the perimeter of the property so that people can't actually see where the house is. So they can't plan how to break in. What about anybody? There's somebody here who worked in a bank. Don't they call anybody out? I just I feel like so what so what were the what were the mechanisms in place to make sure you couldn't steal money from the tilt? Oh, I remember to the stage I killed my manager and we needed two keys to help her go. Yes. So perfect. Right. So I'm like this thing. I don't get pause. Not stop. No, this is great. So this is not really technical mechanisms. Well, the two keys are definitely technical mechanisms. But the fact that every time you went to the state, your boss had to be there. What does that ensure? That either one doesn't steal any of the money. Right. So this is the employee checking on the boss and the boss checking on the employee. Right. So this way is one of them is compromised or wants to steal money. Right. The other ones there to verify what happens. This actually happens a lot in a lot of different scenarios where you need two parties to do something or to authorize something. So that way they go a system of checks and balances. Any other ones you want to share? So they say I'd like email my boss every day and they'd even advise off of this time I'd get it written off and written off. Yeah. So this was part of their policies. Right. It's not a technical thing. It's a procedure as part of the organization. Every day you're going to they're going to make sure that your amount matches. Right. What the machine says you should have and what's actually in there. Right. So they're keeping tracks. They do daily audits to make sure. And if it's off by even a cent. Right. You can get written up and you can get eventually fired from the job. Right. So they're building in procedures as mechanisms that are procedures and not necessarily technical mechanisms. Yeah. So in some places if you assume a sign that says they don't give you a receipt with your food then you get a free meal to notify the manager. It's because they want them running everything through the till so that they calculate how much money is supposed to be there at the end. If they're skimming money they don't put a transaction then get the food for the two. So the receipts are a secondary source for verification that everything's going through the till. Yeah. So that's yeah. So then they're incentivizing customers to demand receipts so that that way the teller doesn't accidentally forget to ring something up in which case the numbers don't matter. Yeah. These are all good. So yeah. So it's important to think about these things. Right. Because not everything can be technical. Right. We can maybe try to ensure that two people are there to open up a safe because we can force them to have two different keys that are farther apart than a human. Right. So it's not there's one person. If you've seen I don't know if this happened to any more but old movies when they launched nukes right it's always two people need to turn the key at the same time. Right. And so therefore that way one crazy person can't just launch well can't just launch nukes. Actually a new clear rushes the marine in the area and then the second officer imputes a bunch of nukes after after they have they went they lost the radio and the second mate said I'm not and that way he was like he is a lots of nukes. That's the only thing kept us from people here in the organization it was one guy who said no. That's crazy. Yeah. So yeah it's good you know good that we have these mechanisms in place. So we talked kind of about the correctness of mechanisms. So how do we know if our mechanisms are actually effective and what do we so kind of we talked about that they're correct that they do what they say they do and really what's the goal of a mechanism to do a job. They do a job to use to implement some policy. Right. So the effectiveness of a mechanism depends on the policy that you're actually using that you care about. And so there's three we're going to talk this actually going to help us we're going to build up some definitions that are going to help us later on when we talk about So if a mechanism. Well, so we'll just define these things. So a mechanism is secure. So you think about I think about different sets and different spaces. It's really all the book boils it down to kind of set theory which makes a lot of sense to me. So let's draw pictures. Although I'm a bad artist you're stuck with it. So All right. So let's say the policy has some shape that's circle ish. Right. So the policy defines what what is and isn't allowed. What is and is not allowed. So everything inside the circle is what allowed allowed and everything outside is unallowed. Right. So this is kind of another way you can think about the policy mechanism dynamic. Right. Is the policy defines what states are secure states and what states are insecure states. And we're using very I mean this is getting very abstract. Right. We're not defining what the state is. We're not defining we're just saying that the policy is a way to tell you whether the current state or whether a state is secure or not secure. Right. So in the house example everything inside the circle would be only authorized people are inside your house and outside that circle would be anyone who's not authorized is inside your house. So the mechanism carves out and kind of enforces some sub well some subset of the spaces that are possible. Right. So a mechanism essentially restricts what states the system can move between. So if oh that's not right. So if I have a mechanism like for our house example I don't know if it could let's say I hire a person why should I make up we actually make up. So if my mechanism is a subset of the secure states what does that mean about my mechanism. It's what it should be secure. It should be secure right as long as we start in one of these states. Right. The mechanism allows us to go anywhere in here well except there it allows us to go anywhere in here but does not allow us to go outside. So all of the states that the mechanism allows that the mechanism allows us to go into are secure. What's the problem. Not all of it's well not all the policy set is covered by the mechanism. Yeah there are other states that are secure that our mechanism does not allow us to reach. Right. So our mechanism in this case would be I think a restrictive would be a good word for that. Right. So our mechanism is actually restricting the states we could possibly be in. So the mechanism is definitely secure. Right. And it's secure because why. Some stuff of the secure set. That doesn't allow exactly. So you do think of it as it contains only the subset of the secure states or you could say that it doesn't allow us to access any insecure states. Right. Those would be the same statements. All right. So I would be one mechanism. The mechanism like this. What does that mean. So I wouldn't say access necessarily. So I think it's a trick that we want to want to talk about in terms of states. So it allows the state to transition into secure. You know. It's a secure state. But it also allows the state to transition to insecure states. Right. They are states outside the policy that this mechanism allows the state to be in. So a term for this is broad. So it's an overly broad mechanism. Right. It allows some things. It doesn't allow other things. So what now. What's the goal. What would be like a perfect mechanism. Yeah. Something that does exactly. Exactly. Perfect. So yeah. There's no way we would be able to draw this. But pretend that this is the best tracing you've ever seen in your life. They don't tell you when you're going to be a professor that you have to like draw in front of students. So if it's exactly identical. So all of the secure states are allowed by the mechanism. None of the insecure states are allowed by the mechanism. This would be a precise. A precise mechanism. Right. So why is this useful. It allows me on the problem. This allows us to establish our mathematical language. When we're defining what we. Yeah. So two ways. So a can allow us a precise way to describe whether the mechanism is implemented is precisely implementing the policy or secure with respect to a policy or as broad with respect to a policy. It also helps us think about policies and mechanisms right. And say like OK you know. It is this mechanism doing precisely what my policy wants. Is it more is it secure and restrictive or is it more broad. In the real world the likelihood of being so locks on a door. Yeah probably broad. Security cameras security system that you have to put in a code. Secure. When somebody just smashes the system or disables the power to the system. So. This kind of the double-edged sword here right. Is the real world is very messy and there are a lot of ways around. Your mechanisms. So. Most of them will be very broad. Right. Because that's just the nature of what we're doing. And so you have to think about OK. Maybe with respect to the threats or assuming that the power still works. Right. Then this mechanism would be secure or would be precise. So it helps us to think about these mechanisms. Right. What does assurance mean. Sorry. So let's go back. Sorry. David what would be a real world. Secure mechanism. What would the policy be there. Yeah. So the policy of the panic room would be only. Like the family could be in there. You know you know no one's allowed to leave or something. That can be a good one. Although I'm sure there's ways into a panic room if you have enough time. And you could start them out. You could like. What was that. If it's on the second floor. Oh yeah. You could like helicopter like. I don't helicopter your cranes or whatever it is. Panic rooms. Right. That's interesting. Any other. The White House. But people. Well. There's even just a couple of months it was next. Somebody was able to run all the way to the front. It was a video game inside the house. That's true. If you didn't know. You crashed a plane into it during the Bill Clinton administration right. Or was it your push. When did the plane crash into it. I do not know. The pilot may have died but I think that would qualify as entry. But he only landed in the yard though. I was in the yard. It wasn't mine. It was like a single you single person. But there were the couple that went to the ball that weren't supposed to go to the ball. Some kind of like crashers. Like they crashed the ball. That was a little bit of a White House if I remember. So yeah this is kind of the problem. I was thinking maybe like if we checked each one of your ASU IDs. Before you turn in your exam. And we'd have to then verify. Also do an online lookup of your photo in my ASU system. And your photo there. But even then that's still a lot of 100% full proof. Because you could have just had somebody else take your picture and sign up right. So it all goes back to the root of trust. Like so yeah it's actually really difficult to think of a mechanism. A secure mechanism. Yeah probably not going to touch that. We should probably not talk about White House as an airport. Yes the problem with encryption as we'll get into it depends on who has the key. So it's all about key management at that point. I'd say okay so a secure policy. So a secure mechanism. If the policy is any authorized user can go in there. A secure mechanism would be you only allowing one, your one friend that you know inside your house. And you like hiring an armed guard multiple armed guards. And only that one person is allowed in ever. That would still be somebody to try to like dress up as them. And make sure you're struck to a certain degree. I mean it's all all kind of ways around that. So it'd be difficult. All right let's move on. But yeah so assurance. So going back to the question earlier about something decreasing risk or. So assurance is really and it's one of the three words I guess two words that makes up the title of this classic game number one official title is. So the idea there is how can we trust. So assurance is all about our understanding of a system and its security. So how can we trust that a system is secure. And how confident another way to think about it is how confident are we that the system is secure. So how do we trust? What should our trust be based off of proven results of what? Well it's an anti virus that catches at least one virus. Interesting point we will address anti virus at some point. Is it too much of kind of a cross in to say I mean in our personal lives and such like that we know that trust is earned and trust is very easily broken. So in that type of way trust kind of builds upon itself and also when you when it is lost. Yes and no I think the way it breaks down is me thinking you know if you are working with someone for a long time and they don't do anything untrustworthy your trust in them increases. Right if you have a system that's running for a long time and you haven't been breached does that mean your assurance that the system is secure should be high. It should probably not because especially if you have no detection mechanisms in place you're probably being owned and you don't know it. That was actually a complaint I heard from I was at that conference last week on Wednesday. I think one of the generals said they got major pushback in the military when they started applying intrusion detection systems and they said well why why don't you want these things. Well they come up with all these alerts that were being scanned and all these attacks when you wanted to get a system but yeah that's the problem. Yeah but now we have to deal with it. Like yes you should have already had to deal with it now you're just aware of the problem. Well I would say if you trust you want to you know you want to make the policies the as in depth as you can create the mechanisms to implement those policies test those systems continuously to keep building trust in your system. Yes so that's what so yes the overtime but it's not just something that naturally occurs over time right so for instance I mean you can be you have pretty reasonably I don't know there's always still problems but at least compared to let's say early 2000s even let's say windows I mean I'm gonna pick up Linux but windows is a good example right early 2000 windows had tons of vulnerabilities in the kernel that would allow remote there is code red melissa virus all kinds of these worms and viruses that were spread through email over time these become much more rare because microsoft developed time and resources into securing the kernel level code and so over time you can have more assurance that yes there will still be vulnerabilities in the windows kernel but they're not as prevalent as they are essentially nowadays so because they have a process and a continuous process in place about continuous improvement and refinement so yeah going back here if you're thinking through and creating your policies to make sure that they are actually aligned with your organization's goals that they are specific and appropriate for your organization that you've thought through and they counter the threats that you're concerned about if you have mechanisms that you have a good assurance that yes these actually enforce and implement the policy that you want and that you test at these mechanisms that you test them over time and that you have some feedback loop in there so that when you see a new threat or a new when your system is compromised you can go back and address your policies to change everything response to that so then over time yes you would you would increase your assurance in the system yes you clarified something a few minutes earlier talking about assumption now you're talking about trust and in my mind trust is just a special case of assumptions are you are you making a difference like you described the difference in your mind between is it just a human element that we trust people when we make assumptions about machines and systems that are inanimate like what's the difference because we can make a stuff like it just seems like the same idea yes i'm trying to think in my own head i'm roughly using them interchangeably i don't know that there's a distinct difference i can call without stopping my head if anybody else has one would say that assumptions assumptions you're usually are usually and should be explicitly stated right so you can say something like this mechanism is precise to this policy assuming a and b and c and d conditions are all true trust is a little bit more nebulous concept but yeah essentially you are trusting something you're assuming that they're going to do something in a certain way so they're definitely related potentially more implied trust is a little more implied whereas assumptions at least in this case are more yeah that's what i would yeah that's kind of how i would think about it but you really need to analyze your the trust inherent in your system to understand and state your assumptions yeah i'd also say assumption is kind of more of a binary thing and trust is more of a gradient right like you could maybe try to quantify well i trust i don't know the locksmith right the trucks locksmith so i'm at 60 or 70 percent or something so um you can have some notion there and i guess it does get into when you have systems of systems right so you could maybe trust that another system is or you can have trust in your certain mechanisms and how much they work up to a certain threshold um so yeah so we've been talking about this right so you're talking about how can we actually trust our own system right so i guess that's another thing you're not assuming that it's secure and then doing something else here saying well how much do i trust that the system is actually implementing the policies i want and is keeping people you know safe and enforcing my organization's goals can you quantify this what i mean by quantify level or something like that what kind of certification level trust certification who's going to give me that certification how much money you have i'll give you a good certification right because that also kind of has to trust right so that there are different certification levels i don't have a name on me off and if somebody looks that up remind me oh but you can get your system process software verified at different levels of assurance and these costs increasingly amounts of money not only to get the certification but to actually develop software that is assured to that level yeah so you could try to do that but that's still kind of you know it's a rough one so somebody says you know how much do you trust that this system is correct you said well i have certification level 10 does that really answer their question of how much do you trust it you know like kind of like a product how do you expect average users to be able to validate the security of your software so why is it difficult or is it it's difficult because any number you can come up with you need something different to perform you know you can you can hang up the sign on your webpage and it says 65 days a thousand intrusion that is a pretty good way of quantifying it but people might not care you know quantifying trust is kind of a bogus thing because the reason you have security is you want people to use your system correct yeah so this is actually a really tricky and difficult problem for all of those reasons that you mentioned so it's easy to come up with metrics you can come up with metrics but it's difficult to justify that those metrics actually gets the heart of what it means for your system or software to be secure right or your website to be secure as to why people want to quantify it so from a business perspective bless you from a business perspective if you're the CEO and your information security officer comes to you and says hey i need another you know million dollars in my budget and they go okay well so you know what are you going to do with that money how are you going to either reduce risk or increase our insurance that there won't be any you know issues and how much can you do that by well i think it's safe no they definitely make it better like i won't make it worse it's hard to kind of talk about those issues about the cow you know to actually quantify that and there's a lot of unknowns here right there's a lot of potential vulnerabilities and things you haven't even thought of one of your devs stood up a development server on your network you're not even aware of that's open on the internet and then that allows somebody to come in to literally bypass all the policies and mechanisms that you had in place yes it's a very difficult problem yeah yes that's an incredibly important and why why um why is how people feel about security and being safe important and impact things they can feel safe why would you have to use security like yeah so you have an anti-virus right why would you be careful about what size you visit right it's like the whole george carlin joked that everybody would be really good drivers if they're just a big spike on the uh scare trail right because there's a very clear danger that would happen if you cause an accident right but and i think i believe they've done studies that are shown that as people as cars get safer and they have seatbelts airbags all that kind of stuff people's average speed increases um because they feel more you know doesn't feel dangerous right even though that may or may not be the case so yeah that's that's a good point and we also you know and these mechanisms that we have many are technical but some are people right and so how do you quantify the people component there that they're going to actually follow your mechanisms that you've put in place so it's a very it's actually a huge if you can solve this problem there will be um trucks full of money that will just come to your house and back up into your driveway i mean this is something that would solve a huge serious problem in the security industry and part of this is because i mean you know security is incredibly new field relatively even compared to computer science and especially compared to other engineering disciplines so um you know practice not that'd be good um so we talked about what it depends on right so it depends on you know how much trust we have in the people how much trust we have on the systems it has how much trust we have in our policies our mechanisms um all of these different aspects right these all feed into the assurance that we have of this system cool so now we're gonna get into kind of system development we'll check a little bit closer and kind of go more software based but i'd like to figure about this so what's the specification nobody's ever seen a spec before just go whatever the heck you feel like it's a requirement that has to be met or is is met by the it depends like are we looking at specification when you're designing something or like when to purchase something it has specifications good so we'll talk about system building so we're gonna build some system right we have some specification which tells us essentially what is the system supposed to do right so you know this may or may not be explicitly defined but there is i mean if you're building anything right it's for a specific it's supposed to do something i guess you could create an art project we're just building stuff to build stuff that's not really what we're talking about here so how do you define specifications this is more of dabbling into software engineering and create use cases that's what you can describe okay uh at very high level these are kind of scenarios user scenarios you can define different types of users and kind of what they want out of the system but also with some other ways slightly more low level but you can define kind of what the outputs are supposed to be what you're expecting to get as results of using it yeah so you could define uh if you have a GUI you can find the interface with the interface look like what the inputs are you can define what the outputs are like um you can also define this you know in English a written document that actually specifies these are the specifications of the system do they still teach you um l diagrams nobody thought just all immediately because uh i guess that's not a specification so so we say okay this is what something's supposed to do then what are we doing next do we build it we model how it'll do it yeah we want to think about how we want to build it right so we want to design it so we want to say kind of modeling how we want to do it this does go into the um l so i'll put that there first um so we can define um l diagrams that kind of finds a more granular granular level how the system is going to work but what's the ultimate goal here make money to make money and how do we make money pleasing your customers so how do you know if your customers if you've built something that your customers want by making they're using it so what was back i mean you can put that essentially in your specification right so your specification should capture something that the user wants and will pay for right so that is the ultimate goal of all these steps right so how do we how do we know that the design actually satisfies the specification you're that person you were just hired how do we validate designs can you unit an integration test of design correct we're talking about the design you could do that so you could model it with some modeling program not like a CAD modeling thing but um and you could try to prove it correct against some properties that would be interesting i think those people would work on that because our specification came from requirements and the requirements were gathered from our stakeholders and what the stakeholders once is always changing so if you're designing for what your user wants there's no way to design like to verify yes we have the perfect abstract design what the customer wants we just need to hire someone to code it you can't verify what they want to change so it's just an abstraction of the quality assurance like is the code correct it's an abstraction of that same problem it's a different level right but if you could so would you agree that you could design something correctly that doesn't actually follow what the user wants and then you could build that out 100 correct that passes 100 percent of your unit case unit test spaces and integration test spaces but ultimately never actually solves the user's problem you can have a crappy design that still works just take 10 years to run i'd say that's a fault that would be bad design i mean yeah that would be a problem so the specification should have some notion of this right of time requirements right these are all different aspects of it so we we want to ensure that the design actually satisfies the specification right we're going to get into the security aspects here because they're all intermingled so can we prove it can we prove that this design correctly specifies satisfies the specification oh we can try to build a quick little easy silly thing that didn't seem kind of a good way yeah uh Susan thanks so much for thinking about so when we get to the implementation so then we have to actually implement something right so implementing using code using something maybe in the future we'll be able to just translate the design down to code but i have my reservations on that so the question is does the implementation satisfy the design and furthermore does the design satisfy the requirements right so it's also tied we're also checking does the implementation satisfy the requirements so we talked about unit testing integration testing any type of qa testing because if your design is completely screwed up at this stage of the game go back and completely redo it or try to hack it until it works which is going to cause you problems years down the road and probably but if your company's not going to exist in multiple years we don't do that and sometimes you have to can you prove this use p-trements i mean this may be a stretch but isn't it kind of boiled down to uh just like uh computer science we're proving uh undecidability and such like that like if we imagined that we did have a machine that you know taken down to just because i'm just recently 55 but you know halting on all input there's no way that we could verify our machine was equal to that machine so ultimately isn't it unknowable to prove it both ways i think to make the claim that it was as hard as yeah so i don't necessarily know so yeah there's no you know i think that's kind of the point is there's no real way to prove any of these things right there's no you know too mathematically prove at this stage yeah there are people who are working on theorem provers and building systems using theorem provers and so the point here is also about security at all these stages right so just like we said so finding a security problem at the implementation phase right in the design or even the specification maybe specification did not say anything about security here after it's already built is a incredibly expensive to fix and b is likely that the fix is not going to be correct this is come up time and time again so security in a system if you want to have a high assurance system that you are confident that it is secure you need to think about security in the specification right you should define notions here you should define the threats that you're considering in the specification you want to think through all of these things discuss your threats your threat model the assumptions that you're making right you should all be explicit same with the design you can look at the design and think okay does this design satisfy those threat models and those threats what policies and what mechanisms are you going to put into place into our system are those actually designed in properly same thing with the implementation now we actually have something we can test say okay is the policy from the specification actually implemented correctly with the mechanisms and it does not just stop here a huge thing with security is not only about is the code itself correct because a system does not just execute in isolation like we saw all right now we've talked about right systems have how's it deployed is it deployed on a shared hosting server with multiple users when it was designed to be a single user system how is it configured it's in 100 impossible and happens a lot where you design an application to be secure but it's does anybody work at a place like this where you have devs the developers build stuff and then you have ops who goes and deploys things yeah so you have completely separate people involved in that so that ops people may not be aware i mean it's not their fault or anything but the deployment in a configuration happens by ops so it could be the case that they're configuring something in a way that invalidates the entire security of your application so one example of this will let's say be a database that should be only accessible in your local debt in your local network to be configured to allow remote connections right that would be a very bad configuration mistake and also the operation so how is this you know there it could be deployed correctly configured correctly but because of the operations there can be security problems in here too and this gets into so even if let's say you prove that the implementation of something is correct all the way from specification down to design that implementation now how can you prove that it can actually be deployed and configured and operated correctly this is also one of these open hard difficult problems is how to prove or even how to you know improve our assurance or increase our assurance that yes this thing is correct because we have to think about all of these complicated scenarios and this may be so it's important when you're thinking about the security of a system because this may be a part of your policy right to say okay well how you know thinking through not only how is it implemented but how will it be deployed who's going to configure it how will it be configured who's going to operate it who has added access to your system right all of these things are important things that we need to think about close to the end we'll go over this real quick so we find out this a lot so context is incredibly important in security okay why yeah so why waste money securing it's a threat that you're unlikely to see or a threat that you're likely to see that is it impact you has no effect to your organization and the key question is it's incredibly easy as technical people to get so focused on mechanisms and we've got to implement all these cool technical access control lists and all these things but if we're not thinking about the business aspects of is it worth the cost then we've really kind of failed because our overall goal is securing and supporting the organization's mission not to develop cool security things so that