 Okay, we have no microphone or no batteries for microphones, so I'm going to try to shout. Sorry about being late, I got your class mixed up with a class I guess taught yesterday that started at 1045, so I was right on time for that. And maybe as you can tell, I did run here, so I did what I had to do to get here as soon as possible. Two double A's, I think, is what we're looking at. Oh, somebody's prepared. Let's go! Actually, sorry, what was that? Oh, you have batteries? Let's go! I also think I messed up the recording again, let me check. Thank you. Usually there's extra batteries up here, but cool. Okay, great. So we are official recording. Sorry if you saw the lecture I posted on Tuesday. I forgot to record the screen, so it's more of a podcast of our class than an actual recording. Sorry about that, but now I've learned from that. So, important things that you probably care about. Assignment 1 is released today, so it's up on the course website. There are several different parts, but do not be scared. The purpose of this assignment is to really cover some baselines of where we are and where we need to be. So very first thing that's super easy is sign up for the course Piazza. Just sign up, and you get an easy five points on the assignment. As I mentioned, on Tuesday this is going to be where we discuss and talk about the class, so that all needs to happen there. The next part of this assignment is going to be developing your Linux command line skills. So part of what we're going to be doing is we're going to have that assignment in the future, where you'll be accessing a remote Linux system and hacking binaries and challenges on there. So to get you up to speed and ready to do that, throughout the semester we're going to have a series of assignments where you do different levels of a war game that I really enjoy called Bandit. So Bandit is part of this really good over the wire series of war games. So they have, to here I think there's like 34 levels in Bandit. Over the wire has a number of different war games at different levels. So if you want to keep going forward you can. Each of these levels, basically it will give you directions of how to SSH into a machine as a given user. And then you have to solve some challenge to get access to the next level as the next user. And what's really great about this is it has a lot of directions for you. It's meant for beginners learning and this kind of thing. So it tells you what commands you may need to try to solve this level. So look at those commands, read the man pages, understand what they do. You can do this by accessing it through SSH if you're running Linux or Mac. And Putty is a really good SSH client, all that fun stuff. So for this first assignment you just have to do the first five levels. They're not meant to be incredibly difficult. But this is really to help you improve your skills on the Grand Line. There's other stuff here, how we track you. So we track you through a really cool place. So this is also another good resource. WeChall.net is a place that actually has links to a bunch of different war games. So if you really get into the security stuff, you can track your progress on here. It has leaderboards of who's solved what things, if it ever loads. But I assure you it does work and you can see it from there. So basically you follow the directions. You create a WeChall account. You set it up so that you can access that through Bandit. And then every time you break a level you run, I believe WeChall. And it will update WeChall that you broke that level. And then when you submit, you'll submit a readme, just a text file of how you broke that level and specifically put your WeChall name in there. And then the submission system will go check that you've solved those on WeChall and then give you the points. Questions on that? Well, I'll definitely say this now. We have other assignments that will take us further. So you'll be behind on those assignments. If that makes sense. More questions? Yeah. Can we complete more levels? Yes, for sure. Yeah, complete as many as you want and you'll get credit for in the future assignments. You won't have to worry about it. Except for the readme. So keep track of how you're solving these things. So it's actually a good technique for you as you're solving these. So you have notes to refer back to. Like what was that command I ran in that one level to find a file that was executable but not writable or whatever it is. You can easily look those up. For the readme, do you want us to keep track of how we're attempting to solve it or just the solution? Either. I think the solution is what we care about. But that for you is nice to have of what avenues you've tried. Oftentimes it takes multiple paths. But you don't have to document every single thing. Like I typed in SL instead of LS. And then I had to type in LS, right? Yeah. Does anybody think that's particularly interesting? Feel free to. How long are we going to have banded this semester? I don't know yet. We'll see how we go. Let's take it maybe five moles at a time. I think I can get pretty far. It's a good system. And they build pretty nicely on each other. Next assignment is going to get you familiar with make files. Have you ever written or done a make file before? Good. This should be very easy. Good. So you're going to write two different make files. One that compiles a C program. And one that creates a Python executable. So the kind of instructions are all here. I give you access to the file that you're supposed to use. All you'll be submitting is the make files. So the C make file should call GCC to compile the program and create an executable called C underscore program. And it must recompile it when the C underscore program.C changes. So pretty simple make file. I'm sure you can adapt if you've done it before. Adapt what you've done before. The purpose of here is not to be tricky or difficult. This is literally a very first assignment so that we can start getting our feet wet. And so that these issues that I've seen come up in future assignments we're going to address now in the beginning rather than wait. The next thing is creating a make file for Python. So why do we care about that? Maybe I should answer that. So all of the future assignments seem kind of silly because Python is an interpreted language. So we don't have to compile it. There's no GCC we have to run. But for all the other assignments in this class you can write it in whatever language you want as long as you provide a make file that when we run make outputs a particular binary, not a binary, sorry, an executable file. So you're going to practice doing that here for this Python file. So essentially you'll have a file Python program.py. Incredibly simple. I think it's four lines of code. And when you call make with this make file with this file in that directory it'll create an executable file called Python underscore program. And it must also recreate it when the .py changes. There's a lot of different ways to approach this. You can, some people write a batch script as part of the Python underscore program. One thing is, which I'm not going to get into, I'm going to let you get into that and learn about this. So the Python script has a shebang at the top which tells the interpreter which tells the operating system when this file is executable how to interpret this file. So this is how you can have a Python file actually be an executable. It just needs to be, the file name needs to be executable. So any questions on make files? Yeah. So should you use Python 2 or 3? Doesn't matter. I'm fairly confident this example will work in bold. Yeah, because you're not writing any Python code you're just writing a make file that creates this executable named this specific thing. So yeah. And if you find better resources feel free to share them with the class. Last thing, pretty, the idea here is to get familiar with command line arguments. I know from experience that a lot of the things that people have done until now you have programs that maybe read from standard input and write to standard output. One of the other ways that we give input to a program is through command line arguments. So in this you're going to practice doing that. So you'll have your, and this is the part of the assignment that you can now write in whatever language you want. I don't care what language you write. So you can even use the make files in the previous one. Basically it's, the spec is a number of command line arguments that are passed to it and then print them out in reverse order. The last command argument first, the second to last second. So probably best through examples. So the program will be called command. So when we run command foo bar it'll output two and then say bar foo. If we run it with nothing how many command line arguments are there? Zero. Zero. So we output zero and then I have no idea, I guess it's not there I'll have to add it but then a blank line because there's nothing to output. There's no other arguments. If we do something like command A B test input C D E we'll output six. There's six command line arguments here. Why is it not seven? Because why? Because the quotes. Because the quotes tell back to interpret that string including quotes as a single argument not as two different arguments. So this means the third argument is the string test space input. So this means your output should be six E D C test space input B A. Questions on that? It says any language. Yes. What implications are there for us for getting it to run when you get access to it? Yes. Okay, great. So this is where the make file comes in. So your goal, so it'll have to run on Boon 2 1804. That's our test platform. That's what we're going to be using. I don't care what you develop on but I don't accept this. It works on my machine, on my Windows machine. I'm using crazy Windows things. It doesn't work on the submission system. So for something like this, it should not be a problem. Just stick to standard things. But that's the gist here. So then you'll also provide a make file. So the make file is what makes all of this work. So do the other part before this part if you're not familiar with make files. So you'll write a make file and you'll submit it along. So this is where your code, what we do is take your code in your make file, put it in a folder, run make on that folder, and then check is there an executable called command that comes out. So this way you don't care what you write it in. C, C++, Java, and anything should be fine. Yeah. Does it look like it's on the machine with what happened? It'll have both. It'll have both. Yeah. I think it's close enough that it would work. Yes. I don't, of course, see any problems. Yeah. It looks like it's on the general. So if you want to use general.asc.edu, you can totally do that. I'm highly confident it's similar enough that it won't matter. They have a different compiler version on the general. For something like this, I don't think the compiler version is going to matter. Okay. Also new, so I'm trying something out. We're going to try to use grade scope to do all the submissions. So the assignments will go live after this class. There's a link on the assignment descriptions to the grade scope. You all have accounts through your ANSI account. I somehow linked this with Canvas. It's the only reason why I'm using Canvas to do this linkage. So yeah, you can submit on here. It's actually, I guess, well, I'm slightly biased because I, but you can upload a submission. You can drag and drop multiple files on here. So to submit all of those, you can click on it and control select multiple files. Upload them all. It uploads them. It gets auto graded. And you'll know your score right away. Yeah. Do we have multiple questions? The main extension is one. Yeah. Does it automatically unzip zip files? I don't know. That's a great scope question. We will find out together. All right. I think so. Even saying any files, including .zip, I would think it would automatically unzip it. I haven't tested that. Yeah. This is brand new. So we're still working out. I mean, I'm still discovering, but it seems to be much better than what Coursera does. So that's my stand. When I go to Gridscope, it doesn't have the assignment. Yeah. It's not open yet until after this class for exactly this reason. Cool. So again, this is supposed to be a learning starting assignment. So, you know, talk on the mailing list, help each other out. It should be good. It should be super stressful. Do next Friday. So a week and a day. I think that should be doable. Questions? Cool. All right. Now, let's keep going with the material. Okay. So we talked about on Tuesday, we talked about threats. So somebody remind us, what are some of the threats in different security situations that we were talking about today? Speeds. Yes. Yes. Right. So if people are trying to steal information from a property, let's say, what else? So why would they do it? Right. Yeah. So maybe user actions, right? So if users in your organization are downloading software, running it, it could basically do whatever it wants. It may contain malicious logic. Yeah. Should we blame the end user? Should we? Are they the enemy? The answer is that, no, we shouldn't really think of them as enemies. We should think of them as users who make mistakes. Right? So the un... And oftentimes they're just trying to do their job right. They're trying to get their job done. They're not trained in security. They're not even computer scientists who don't care or understand about all this stuff. They see a pop-up box that looks exactly like everything pop-up box they've ever seen. That says they need to update their antivirus. They know antivirus is important. They know you should update that. And so they think, okay. And they just do whatever needs to be done. Or, you know, you can have... Anybody have an iPhone? So Apple has, by default for some reason, an Apple contact in your phone already that they pre-installed. So when Apple support calls you, you'll see this Apple logo. But what a lot of people don't know is that you can trivially spoof the caller ID on your phone number. So you can get a call on your phone that looks exactly like it's coming from Apple. You answer it. They say, hey, it's Apple X support. We've heard you've been having problems with your Mac laptop. Let's help us. We're here to help you figure out what's going on. So the one thing that some people in that scenario, what you do is you give them essentially access, remote access to your laptop. And now they're in your system going through all your data and all your information. So, yeah. And there's another thing when talking about... So there's maybe unintentionally malicious users or unintended user actions. But what about malicious user actions that you can worry about? Insider threat? Yeah. And what kind of scenarios? When does that come up? The priority, maybe, to get access to data are new malicious. You can just be disrunful and then you work the job that you didn't like to talk about, man, I could take this company down by doing X, Y, and Z. But imagine now you have administrator access to a bunch of systems. So you can cause a significant amount of damage. There's actually a case in Australia. I want to say 2005, but I don't have the exact date where a contractor who worked for the sewage company in Australia, they fired him but did not revoke his access. So it was revenge. He unleashed sewage on totally Australian beaches causing like theological disasters. Hotels had to be shut down. It was crazy. So they obviously found out we did it and I believe we went to jail for it. But, so, yeah, this kind of insider threats actually do really occur, right? So you'd be thinking about those types of threats, not just external. It's very easy to think just external. What else? What was that? Visioning emails. Yeah. So, the visioning email, you get an email from, let's say Google that says, hey, we've seen some of this vision activity on your account. You know, click here to make sure that everything is safe. You click there and it goes, oh, we need to know your identity. You need to log in. It's the Google login form. So you give them your Google username and password and now all of a sudden the bad guy has your Google username and password. Yeah. What else? What are the threats? Other systems that have your data, like experience and trans-union type things. Yeah. So that's a good example. So, threats in terms of other organizations that have your data. So that could be almost a little bit in terms of privacy, but also, yeah, your data is out there and stored by a number of companies, some of which you don't even have a business relationship with. Like, experience has tons of credit history and credit information and they were the ones that got hacked, right? Yeah. Experience. Yeah, everybody. So the other interesting example of that is the, anybody have, I think we're going to talk about this. So if you've ever, I've never gotten security clearance, but I've been interviewed by FBI agents or people who have, and they ask a ton of crazy questions about the drug use and all kinds of things. And so everybody who has security clearance has a file with all of that information about them. And not only that, who their associates are and what they basically talk to, their family members, every place they live, all their information is stored in a database at the Office of Personnel Management. And in 2014, they found out that this database was breached and the consensus was that it was the Chinese government that hacked in and now has all this information. And kind of crazy stuff that can happen to these kinds of threats. Cool. Okay, so we can kind of talk about, we can kind of try to categorize threats into different categories. So we can think about disclosure threats. So when information we don't want to be released is released, right? So that could be a type of threat deception. So pretending to be somebody else. So maybe a good example, so this section actually in the kitchen, is a good example here. So a fraudulent website is pretending to be Google in order to trick you to give them their Google username and password. Disruption? So why is disruption a threat? Why do we care about disruption? Yeah. Your organizational services, right, have to be a massive problem in terms of availability and ultimately security, right? So another example that I really like is their services that kind of seem silly on the basis of how many people get spam in their mailbox? You get a lot. Maybe like one of... Most spam filters are pretty good at filtering out spam, right? They're various into the spam folder. So there are services out there that will send like a thousand e-mails to a mailbox that have all gibberish. So they bypass spam filters because they don't look like spam. They don't link to anything. They don't have any background sounding keywords, nothing. So why do these services exist? People are going to target a bank, right? Banks have a lot of related systems. They have a lot of good security systems. But security systems ultimately have to alert the people working ahead of a different problem. And how do they do that? Through e-mail. So what the criminals do is they take out the e-mail addresses and security... When they try to launch their attack, they flood these inboxes with all the gibberish so that the alert messages get lost in all of these moments. So it takes them... It gives them kind of hours of head start before they can dig through all of those and actually figure out what happened. So yeah, so there's another kind of availability where you're trying to limit or suppress an alert from getting out. Cool. Okay, so I think it's also interesting and we've talked about it a lot in terms of common types of threats. We've talked about snooping or wiretapping. So what's kind of the nature here? For something, people are on their phones they're banged, and for whatever reason they're saying their social security number out loud. It's crazy to me. Yeah, so you can be snooping inadvertently, right, by physically snooping on sensitive information. You could be in more of a digital way. Maybe you've got access to this phone call that you're actually listening to tap and wiretapping into that phone call so you can listen to what's going on. Similar things with electronic communications. Basically every email you send is essentially a...the way I can think of it is the difference between an envelope and a postcard. Any male person who's taking that mail can read the postcard. It goes from spot to spot to spot. It's getting carried, but if anyone has a postcard, you can read what's an envelope. You have to destroy the envelope and very carefully put it back, right? It's not a whole group method. Similar with email. Email is basically a postcard. Every email you send it gets sent from mail carrier to mail carrier and very few of them actually encourage that in private. In private it sends any of those mail carriers, any of the switches that your data packets to get from that mail carrier to another mail carrier. Anyone could have read that email. So other ways of snooping and wiretapping. Okay, how does that differ from maybe modification and alteration? Which are you more likely to detect some modifications if it's possibly virus? If somebody is passively eustrophic it can be more difficult. There's...I don't know how much good it's led, but I believe it's pretty true. NSA has...they send submarines down to where the undersea biographic cables are between countries and they wiretap so they can read the traffic that's coming on those cables. So that's a lot more difficult to detect if somebody's passively reading their information that they're actively changing and modifying it. Cool, so one of the classic versions of this, and what we're talking about is this helps us brain how we think about security in different contexts. Another kind of context is the man in the middle. So a person or entity in the middle of your communications so think about in our post-op, for example, the male character. Right? The male character you're trusting that they take the male from one place and deliver to another place you're hoping they don't read it but we know they could if they wanted to and would be very good at helping it. But they can also fabricate new pieces of mail like nothing prevents them from just creating a brand new piece of mail playing you in front of somebody else. They can alter or change mail that you're getting along the way. I'm not picking on them. I don't think that they're malicious. But it's important to think about this concept. Other things are pretending to be someone else so masquerading or spoofing, right? Being crowd-spirited sending me emails asking me to get an eye-opening ticket card for another person. You got to get one of those good cards. One of those good cards? Yeah, so, and actually if you look at it, it's a very clever spoofing attack. It's kind of cotton Kyle. They make emails from them so they understand what their normal email looks like. So it's exactly like an email for a pin. It has a booster and everything. And the tricky thing is a lot of mail clients actually hide the email address that the email is coming from. So all you see is necessarily the name. You don't see that it's actually a Yahoo account or whatever it is. So, yeah. So we can think of kind of masquerading or spoofing as trying to act as if we are somebody else we're getting. I said to trick someone else to think that we're somebody different. You've all received emails from Michael Crowe, right? Do you think he writes all of those emails? I think that and we're going to think he's the one who gets sent. Why is that? A lot of mail clients have the function to delegate and to say, okay, this other person in the organization can act as me on my behalf. But is that masquerading? So is that a security problem? Should we go tell Michael Crowe to stop that? He needs to reply to all of his emails himself. Yeah, so the key aspect is is it this idea of delegation, right? And intention, right? So Crowe has intentionally decided that these people can act on his behalf and forward with his name on all streets and stores because he trusts them, right? Essentially that's what it has to be. So it's not a masquerading or a spoofing because he said these people can act on my behalf. Right? So again, that's an important thing to think about. The difference, the same behavior may be a huge security problem in one context and may be perfectly okay. It depends on the intentions and what the goals are of the organization. Cool. Okay. So another two aspects here, repudiation and non-repudiation. So this is another type of threat. So essentially non-repudiation is the case where you call up your stockbroker because you have a lot of stockbrokers that you call the phone and you tell them I want to sell all of my shares of Apple stock. And then three hours later Apple shares increased 500% while your broker and you say, hey, what the heck? I saw that you sold all my shares. Why did you do that? And they said, well, here you called me and told me. But you claim you never actually called. That was somebody else pretending to be you. I never sent that. So that's, repudiation is being able to say, well, I never sent that. And so non-repudiation is a security property we try to strive for so that we can maybe make either cryptographic or mathematical guarantees that know you did send this. So denial of receipt is basically kind of a different way of saying, well, I never got that request. Sorry. Cool. And other things touching on what we talked about in terms of disruption, maybe delaying things. Right? And I can attack the security of the system by just delaying something like 30 minutes, right? That can maybe seriously affect the spirit of the system. Like, I don't know, starting class on time. Or denial of service. So denial of service is a much more, one of the standard threats in terms we think about of, okay, so think about this classroom. Let's say I wanted to perform a denial of service attack and get an issue to get into this classroom for class. How can I do that? Lock the doors. Lock the doors? I don't know how to use these keys though. It's called A civil attack almost where you're hiring to sit in these seats, but no, your seats have to be at night care. You can call it a bomb pressure. Yeah, you could call it a bomb pressure, and four pieces of string and organization that have more authority to go to the room. Don't show up. Yeah, what, is that around 15 minutes? Have you spent that window? I think there's a great existing Yeah, so all these ways are ways that I can try to bar the doors physically, right? I could try to, maybe if I don't have locks, I could put, I don't know, really big or heavy boulders on all the doors. I think you saw that and you said, well, I'm not going to class. Yeah, so all these things are different types of analysis service attacks. So these are ways that we need to think about how we can attack systems. Cool. How do we defend against threats? So we talked about a lot of threats. We talked about what are the three principles of security or components of security that we're also going to be thinking about. How do we defend against those threats? So we talked about those security properties at a high level. We talked about different types of threats and you can map each of those threats into one of those three areas. So how do we defend against them? Educating users, yeah, hardest education for sure. Restrict access. So how do we actually do those things? Even both of those things. So educating users. So every time everyone sits down at their desk, they have to take a spam and a fishing grenade. Or two. You're shaking your head, why not? Is this productivity? Yeah, it's getting in the way of the business, right? So people need to do their jobs. They're spending, what's that, a quarter of their time at their day doing your security training. And they probably won't get fish because they're not doing any work. So we need to answer these kinds of questions. If we think we want training to solve a certain threat, we need to answer, well, how often do we do it? When do we do it? How do we evaluate that it's successful? Maybe our training actually, for whatever reason, makes us more susceptible to fishing. But how would we ever know that? Other frameworks that let you test fishing on your company? Oh, yeah. And there's companies internally that will do that. So we actually did this at ASU. We wrote a paper about it where we did telephone scams. So we ran our own telephone scams on ASU faculty and staff, varying different aspects of the scam to see what would be more effective. And it turns out the most effective one was one that basically targeted ASU. So rather than opposed to just an IRS scam, an ASU-specific one that was definitely ranked before payroll, that said that there was a problem with your W-2. And if you didn't fix it, you would jeopardize your pay data for the credit. We had a lot of responses. So, yeah, measuring those types of things. So we need, in some sense, we need some kind of policy. So it's kind of what we're driving towards and what we've talked about before. We need some kind of policy that the organization comes up with of how are we going to try to mitigate these threats, right? Other things that we talked about like a home example. They say, so what are some of the policies that we can think of to secure our home from the threat of murder or something? Don't let people follow you into your house. Yeah, it's actually a lot easier to do with your house than your company. Don't take a picture of your key. Always lock the door. Always lock the door when? When you leave. When you leave? Maybe also when you come in, after you come in, too? No? You guys all leave the door open as you're in the house? Just don't use the door. Huh? Just don't use the door. Don't use the door? Why are you going to get in the house? It's like saying abandon the house. Cameras. Cameras? So maybe, uh, so like, okay. So we need to, now, well, that was good. I was bridging into this. So we need to separate or think about differences between policies and mechanisms. So this is kind of a classic security thing, right? So a camera is a security mechanism. A lock is a mechanism, right? It's a thing that does some kind of security thing that we care about, right? A lock. What does a lock do in terms of a mechanism? Yeah, it lets you. So it's a lock, um, only allows access to people who have to key. Right? So you can have a lock in your house, but if your security policy is, your key is duct taped to the side of the door, it doesn't matter how effective your mechanism is, if you have the best lock on the planet, it doesn't matter at all because people go, woop, woop, woop, stand in, right? Right? So you need policies over how to get into a mechanism, right? So this is all we were talking about of, every time you leave the house, lock the door, right? It doesn't matter how effective your lock mechanism is, if the door is open all the time, we need policies to think about that and to enforce that. Cameras are another good thing, right? So, camera is a mechanism, right? So we need policies are, are you gonna have that camera on all the time? They're gonna be streaming on YouTube live all the time? So, where is that data being stored? Where is it going? How, who's reviewing it? Who has access to that data? How long do you keep that data? Is it based on a motion sensor, right? That could be a policy as I only start recording a camera when it senses motion and when I'm away, right? So you can have all of these different policies that go into how do you manage this security mechanism of this camera? Okay, so let's go a little bit more. I want to talk a little bit about, we'll kind of do this a little bit narratively as a class in the new year, a little bit, but. So we want to secure our house, we'll kind of rent what we're worried about, we'll kind of policy to a good place, and we'll kind of mechanism what we need to enforce the policy. Or what kind of policies are mechanism to be. So if we probably want to think about maybe fences, right, because that can protect us a little bit, we can keep the walls, we can keep the walls in the house, that kind of stuff. Where do we want that lock? What do we want you to lock? Doors, windows, what was that? Entry points. Entry points, what are all the entry points in a house? Garage door, yeah, I mean, you have a lock, you have a garage, doors. Yeah, you can have a pin pad, some of the right ones have that, yeah. Pet doors, yeah, pet doors are actually have, I don't know, I get the word, but that's something you put in a dog collar that tells the pet door when it's close to it, so it unlocks when your pet is close to it, and supposedly locks, I don't know, it's also just, I guess, a flap of plastic as I'm thinking about it, so cut through it probably, but better than nothing, I guess. What other types of ways are you gonna go house? Windows, so in fact, yeah, windows, following you in when you're coming in, pretending to be somebody else, so showing up, so maybe, you have to work out threats around impersonation, so impersonating maybe, I don't know, UPS, like claiming you have a package, or some of those types of things, or that you're, I don't know, the electrician, from the electricity company, you need to go check the meter or something. Yeah, just like breaking your way in. Breaking your way in, yeah, so we can think about all of these windows, right, so the windows are, I guess, a mechanism, you could say that, right, because policy would be, make sure your windows are always locked, but of course we know we probably need to consider the threat of a hammer against our windows, right, so how easy it is to smash the window, so what we may do to defend against that threat? Our patrols. Do we want to barge our windows? What else? Censors. Censors, so the mechanism will be censored, so we got some censors on our windows that detect if they're shattered or not, right, but now we need policies over how to detect that, like all that kind of stuff, yeah. You could have like a guard dog. A dog in the house, yeah, that could maybe, depending on your dog, or how many treats your burglar has, yeah. Ban all windows. Ban all windows, so get rid of windows and get rid of the problems. Yeah, it may not be a house we want to live in, so that's kind of what we need to think of in terms of the organization, right, but it's definitely a way to combat that threat, all right, that possible threat, yeah. Armed guards. Armed guards, yeah, so now we need to start thinking about what are these, so we now need to start thinking about risk, right, like is it worth it to hire armed guards to defend our house? For a lot of us that answer the middle, although I mean have, I guess, armed guards, that's all we need to think about, right, so this is why we need to think about context, right, context is important. We also need to talk about what kind of house is this or whose house is this, right, because like we said, maybe for Bill Gates that totally makes sense to have armed guards at certain times, at his house, the rest of us, it doesn't quite make sense. We're talking about just a rural or an urban area, so those have different ways of thinking about different types of threats and different types of policies and mechanisms to combat that, yeah, great, cool. And so the other thing, the things that we need to think about and with security policies, we want to think about them in terms of prevention, so how is this a great policy actually preventing a given threat, right, so in the case of the policy of always, let's say, lock our windows when we leave, right, that's literally combatting the threat with somebody coming out of an opening window and entering the house, right, they want to get in there to do more physical damage to get in, which potentially increases their risk of getting caught. Can we just rely on prevention so prevent all possible threats, get rid of those windows, get rid of the house, oh yeah, great. No, what else, why can't we just rely on prevention? If someone wants to combat us, we go and get it. Yeah, so no system is totally secure, right, that's, I think that, basically my argument is usually that, well, systems are written by people, we're created by people, people make mistakes, so have you ever had a coating in saving your life? No, never, okay, we'll see how these are signed, I'll check these for you, yeah, so, you know, systems are written by people, they're run by people, even if you're trying to verify, so you can tell me, okay, but I'm gonna write my system in such a way that we can formally prove that it's correct. I would say, okay, great, let's secure you properties so that you can compare and test correctness to it, and who wrote those security files, and who knows properties and does this kind of modeling actually reflect the real world, so, anyways, that's very general, we're definitely not there, I don't think we'll ever be there, so we can't possibly prevent everything, so what do we need, so if we can't prevent it, what do we need, we need, but how do we, so, okay, make the consequences high enough, but how do we know there needs to be consequences? Yeah, we need someone to detect what a problem occurs, right, if we don't have any way to do that, then, well, okay, we can't enforce any consequences if there are any legal ones or whatever, but furthermore, we can't learn from what we missed, right, so super important, and it kind of, you can think of it in kind of a cycle where you start, you try to prevent as much as you can, you then use whatever mechanisms you need to monitor and detect when everything goes wrong, and then, we recover from that, which may be, I don't know, it's a security incident, you wipe the computer clean and get rid of whatever it was, recover from it, and then refine and say, okay, how can we refine our policy and our mechanism so that it doesn't happen again, right, how can we try to increase our prevention so we can prevent this, then we also need to think of how do we define policies? So we have some notion of the house and walk the door, we found that, right, with either verbally or written with English, right, so we can use natural language, is this, I don't know, the best way? What could be some problems with using language to describe what we want to have happen for our security policy? So sustainability, let's say misinterpret it. Misinterpreted, yeah, so we may intend something different than how it's actually interpreted, yeah, that's good, what else? There's more than one language? Yeah, well, there's more than one language, yeah, that's actually a really good problem. Yeah, so, and how do we prove that this security policy is correct if it's written in English? We're gonna try to reason and argue about it, that it's actually properly dependent on this threat, but reasoning in English words is kind of nebulous, we can easily trick ourselves into doing that. But the complete opposite end of the spectrum, we can use math, so we can create a formalism that describes the scenario, that describes the threats we're thinking about, and describes our policy, and then we can actually mathematically prove that this policy successfully counters these threats. What are the problems with that? Or if we're taking any math class, we get a proof thing, trigonometry, I don't know, think about all those things you got to prove there for trivial things about triangles, now, expand that to a complex organization security policy, and it would be very, very difficult. Just the complexity. Yeah, the complexity inherent in describing a complex system in a mathematically formal way, and then getting any kind of reasonable proofs out of that, and then trusting, how do you trust that these, that you actually get the right answer? So then kind of in the middle, you have this nice notion of policy languages. So these are things that in, let's say, something like XML that describes the security policy of your organization or something that you really care about, like access to, access what? So it's kind of a mix of both. It's not completely formal, and it's not completely English. And so then when we think about, okay, so but how do we kind of ensure that this security policy is correct? So can we ever convince ourselves that it's 100% correct, secure, right? But are we just guessing? Do we just kind of write them letters and say this is my security policy so that I can never make one that's perfectly secure or I'll just kind of do that? No, you can test it by hiring a company to try to break it. Yeah, so maybe we can test a company to, or hire a company to essentially test our policies and our mechanisms and see if they can find holes either in the policy itself or in the system as deployed. We can also do it ourselves, right? We can think adversarily about our own policy and say, okay, if I was a bad guy, how would I break into this? Why is it, why can it be also good to hire a external third party company? Who's on the bias? Yeah, because your own bias that happens to the view, I'm sure this is happening to you where you're staring at your code, you can't see what the bug is, and then you show it to somebody else in like five seconds they're going out and something you've been missing for hours, right? Because they're not sort of tying in to happen. You have your own biases, it should work, you think it works, right? So you need somebody else to come in with an outside fresh perspective. Yeah, we also need to be thinking about assumptions, right, why are assumptions important in understanding correctness of a security policy? We might think we covered everything, but we missed something. Yeah, and these are, we may say, well it's secure if A, B, and C is true, right? So for instance, what kind of assumptions did we make in our house example? Everyone follows the policy. Everyone follows the policy, right? This is a really difficult thing, like locking doors, right? How do you ensure that everyone that they leave the house locks the door? Do you have roommates that don't lock the door when they leave? You used to drive me crazy. What other assumptions did we make? Yeah. Kind of from a pedantic point of view, we never actually said we had a roof. Yeah, so we didn't actually send me a roof, or what that roof is made out of, it's made out of straw, and it's really easy to get in this roof, right? So yeah, we didn't define the actual brand or of our environment, yeah. Yeah, so we're assuming that the mechanisms we're using actually work. We say we have like a bike lock that has kind of a circular key. Yeah, I think it used to be, I focused on the case, that it used to be able to just take a big pen and jam the back into there, and another example I really like about this of sound, so I was involved with my lab at ATC Santa Barbara when I entered in, I think 2006, to evaluate voting systems and to perform another party security review of a one-party voting system. And so the story goes that they brought this security, this voting machine in and the people who brought it were so proud of this machine and they were like, you see this lock? This is the best lock. It has diamonds, something, something with multiple things. It's the best lock on earth. There's no way you can pick this lock. So Professor Dick Kemmer, who was part of this, was actually the first hire I used to be in a computer science department. He goes and as soon as those people leave, he starts looking at the lock and he goes, okay, this looks like a really fancy lock. And because inside this lock is the PC that they see running the whole show. So then he goes to the back of the system and just sees screws. It takes the screwdriver, screws it off, the whole thing of that, and you have access to the thing. So you have this beautiful mechanism that's not actually sound. It doesn't protect everything that you think it would protect. And this happens all the time. This even happened when I was doing a pet test for a company and we were doing just kind of classic scans of their network to see if they had anything interesting in the open and we found out that one of their machines had servers, had this network management protocol. So basically the problem with the server is that it goes down and you need to reboot it. Rather than physically going there, there's actually a second CPU that's connected on a different network port and you can access and reboot it and do all kinds of stuff. This was open and it was vulnerable to a, I think it's a standard like admin, admin login. And so we found this and we showed them they were so pissed. They were like, how did you discover this? We run these same scans every night against all of our systems. We showed them this month ago and we looked and dig into it and they realized like they were using the defaulting thing and only looking for ports, I don't know, zero to 1024. And when I read my scan, I did zero to 65, I don't know what the maximum is and that's how I found it. So they were relying on these mechanisms that work as sound and work actually detecting what they thought it was detecting. So yeah, it's important to kind of, in terms of correctness, to revisit those assumptions of what we think. So some of the assumptions is that we talked about the policy is correct. We also assumed the mechanism correctly influenced the policy, right? Because exactly we were just talking about the soundness. And also we get into this notion of trust, right? So the questions of well, who do we trust? Do we, like we were talking about the house example and we lock in the door when we leave. Do we trust that everyone that has access to this key and lives in this house is gonna lock the door when they leave? If we don't, then what do we do? Are we just saying, ah, we're gonna get robbed at some point? An option, yeah, you can just say, well, we have a higher risk and then it'll be it's gonna get insurance in case I ever do get robbed. Which is definitely one way to go about it. You can also get like a fancy smart lock that tells you the lock status and allows you to lock it remotely if anyone leaves it unlocked. Of course, then you don't have to think about are you adding additional threats, right? Is this smart lock here? Are you hacking your smart lock? So you find that you're locked on the internet and locked into it and unlocked the house, right? So you kind of balance all of these types of things. Cool. Okay, so in terms of mechanisms, we can have things that we pick up in terms of technical mechanisms that implement things and implement security policies. So this is what we're talking about the lock itself. And we can also think of procedural mechanisms of, and so, but really we want to talk about the effectiveness of security mechanisms, right? What makes them really effective? Well, I think clearly we want them to be secure, right? What do we mean by secure in the context here of a security mechanism? Can you see, can you see what we're talking about? Security of the system. We're talking about security mechanism and along that you see here. So does that mean some security mechanism? And it's not possible for somebody else to subvert it and maybe do something about it. So for instance, locks. If you have the key to the lock, you should be able to open it and nobody else should be able to open that lock. If that turns out to be not be true, then that is a problem. We also want security mechanisms that are precise and kind of only apply to what they need to apply to. For instance, our system that's constantly going off even though nobody's like a motion detection system, maybe it's a good example of having a path or something at home, right? So a motion detection system is continually going off because of your path or because just your motion detection system sucks, right? Maybe it's windy and maybe it's blowing and it keeps going off and keeps alerting you, right? So the mechanism is not very precise at doing what it's supposed to do. In addition to that, we also want to think in terms of break. So is this mechanism broad enough that it's covering important things? This gets into what we're trying to defend against. If we're like, I don't know, maybe if our approach to preventing burglary of our house is actually, why don't I just have one really good lock on one door in my house and just have all my valuable things in there. They have care, so many breaks in my house. They have to get into that specific room and that specific door, right? But that's really too narrow way of securing and thinking about that system, right? We want to kind of broaden that security mechanism so that it's applicable to the entire house. And really where we're trying to go and get to is this notion of assurance. So basically assurance is how we trust that this system is secure. So we go back and have the title of the class. What is this class about? What's happening now? This is, yeah, so it's information insurance or what's the information insurance? Information is secure, so. And this really gets to that notion of we can't just think about security in terms of binary, if you're secure or insecure. We need to think about increasing our level of assurance that something is secure. So how can we do this? What are some ways? We've talked about this, so we've talked about we can hire a third-party team to evaluate our system, right? What are some problems with that? I think we want to talk about what they've targeted and when it has worked with you on that. So actually, Joy got my example with her credit card processing machine. We told them what we found. They said, oh, this is our, and I was ready to go to that system and do all the whole stuff. And then they were like, yeah, that's them. So the whole new machine, we have that process of spreading cards, so we're not a five-time machine. We believe that this is a problem, but don't take it out on the machine. Otherwise, we would slide it on. So it was good that we did that. So yeah, we want to trust that they'll follow their policies. They won't cause more damage. They won't release the information of what they have or use it when it's been later. What else do we trust them? I don't know what they're doing, right? What if they're not very good and they tell us, or what if they're, even what if they are very good, they're the best. And then they tell us we didn't find anything. What does that tell you? Yeah, they're still human. What does that tell you? Is your system, could there be vulnerabilities in your system still? No matter how good they are, even if they tell you there's, they've got five vulnerabilities in your system, that mean they found them all? No, there could be another 10 or 20, whatever, out there. Right? So by not fixing the five that they told you about, that's a huge problem. Actually, I think that's a big problem in terms of penetration testers. The first thing they do when they go back to a company for a new gig is to check the exact things that they found in the last time and like 50% of them will not be solved. So they're like, well, this report is easy, great to do this, and then do maybe the rest of the time on that. Right, so we can think about hiring people to test our system. Can we quantify trust in a system? They say I trust this system 50%, but I trust this other one 60%. You can maybe trust in the availability, but you still don't know that, just because it's been up for two, 10 years, doesn't mean it's not gonna go down tomorrow. Right, depending on how the system is made. So, anyways, the point is this is a difficult problem and you should try to quantify this down to a number. You can try to increase your assurance that a system is secure, but it's very difficult to quantify this down to a number where you can say I am X percent secure. All right, and so kind of assurance depends on what you've done to increase your level of trust in a system. Cool, and we will stop here and I'll see you all in two things. Batteries, batteries.