 Cool. Well, on that note, let's get started. So, hey, everyone, that's here live with us and here, hello, everyone, on Thursday. So, it's popping in the schedule. We'll look forward a little bit at the start. So, today's the live lecture on Wednesday that this being recorded. We'll be playing this Thursday morning at 10.30 a.m. And so, people asked, so because there's no class on Monday because of the holiday, we're now going to flip going forward. So, now live classes will be on Tuesdays and Thursdays and the recordings will be played Wednesday and Friday. And then later on, what did I say, Wednesday and Friday? Yeah, that's not right, Wednesday and Monday. So, that means Tuesday morning we'll have a live class and then Wednesday we'll play the recording of Tuesday's class and then Thursday we'll have the live class and then we'll play the recording on Monday. It'll also be available right afterwards. And it will flip back at a certain point in the future. Yes, you can show up to anyone. So, you can show up to any class. Cool. Okay, and first thing, the first assignment is out. So, it's being released right now. So, the important thing is we'll go over this assignment real quick. The idea is to get you kind of up to speed in and develop the skills that you'll need going forward in the course. So, you got a week and a half on this assignment. It's meant to be definitely on the easier side. The first thing you can do very easily is sign up for the course Piazza. So, once you're on there, it'll look something like this. Your interface will probably look a little bit different. And then from there, when you're on there, now we'll be using grade scope for the rest of the assignments. So, you'll use the entry code that's here in this post, and you'll need to go to grade scope, which it doesn't do for me. Awesome, because I'm already logged in. And, anyways, sign up for an account, put in the entry code that links you to the class. Make sure where you put, the important thing is where it says for your ID, put in your ASU ID, the numbers, and that way we can link that there. If you haven't used, has anybody used grade scope before? Yeah, so, yeah, grade scope is awesome for many, many reasons. It's... So, yeah, grade scope is awesome because you can submit assignments and it gets auto graded, and you get the feedback right away of exactly what your score is. So, it makes things really awesome. It allows you unlimited submissions. And, yeah, so I'm not gonna go through it all here, but it's actually very easy. You upload your submission. So, for this bandit, you'll upload, as we'll see in a second, just a read me file, and you'll upload that file from your system on here, click upload, and it will go ahead and grade it for you. We'll probably try to do an example maybe in a future class. So, yeah, so, okay. So, this is the first part of the assignment. Basically, sign up for Piazza and also sign up for grade scope while you're at it. The assignment is due on the 26th. It's like a week and a half. That's a Sunday. Is that correct? It is a Sunday? It's a Tuesday, 26th of Tuesday. Is it? Yep. I meant it to be the Sunday. So, what is that? The 24th is a Sunday. Yeah, sorry, okay. 26 is okay. Thanks. Let's, you guys wanna do a live edit of the thing. I'm sure this is a great content assignments. Yeah, okay, that part is right. And then, oh, it also says 20. That should be done. Cool. And, okay, so then there's the assignment split into different sections. So, the first part or the second part here after dash A is dangerous on Git. If you get used to using that, I think it adds all changed files and you can easily add and mess up. So, I always two part it. Okay, so then Bandit. So, what we're gonna be doing in future assignments and this is to get you kind of excited for where we're going in the future, you'll be hacking on a Linux server. So, there'll be various binary challenges and other types of challenges on the server there. And so, you need to be familiar with how to access a remote system and access it from the command line. So, that's the goal of this Bandit assignment. So, you'll be practicing command line skills and also familiarizing yourself with WarGames. So, first and the way we track it, there's this site called Weechow. So, this is a, so I kind of mentioned it, I think in the first class. So, we talked about how capture the flags are these kind of like in-person hacking challenges. WarGames are a bit different. They exist on their own and you can play them any time individually. So, for instance, this is one of the sites we really like is over the wire. They have this excellent series of WarGames. Actually, one of the ways I kind of got into security is we were working through the Vortex challenges which are excellent, excellent challenges. And so, Bandit is a WarGame that starts at the basic beginner level. So, you start at level zero, it teaches you and shows you and gives you resources to use to access the other levels. So, and so Bandit is not the only such WarGame, there is this site called Weechow that has actually, I think like, yeah. So, it has 56 sites that it tracks that are all different kinds of WarGames. So, what the nice thing in here is, so A, yeah, there we go. Okay, so over the wire. So, so you link, so create an account on Weechow, you can link that to Bandit and this way it will track your progress as you go. So, the first thing you'll do is register for Weechow account, you can follow the directions here, you then link to overthewire.org and then your goal is to reach to level six. So, it's five points per level. So, you've got to get to level six, solve five levels and then you'll need to follow these instructions to make sure you've registered your Bandit progress. And if you have trouble, ask in the absolutely no penalty for doing more, you can feel free to do more. I'll spoil it for now, we're gonna do more for future assignments. So, you can either wait for then or just go further along. The language, I don't think for the Bandit levels, you'll need any language. So, it's all just Unix style command line interactions. So, yeah, okay. And then, so then what you need to submit. So, you're doing this, you're solving things. So, just kind of keep track of how you solve the levels in a file called Readme. So, an important thing is it needs to be a plain text file. So, just a plain text file means no PDFs, no rich text files, no anything, just a plain old file. You can open it, you know, edit it in your favorite editor, but just plain text file, you know, how you solved each level, right? So, we wanna see, make sure you always, so a good practice to always get into with your Readmes is to always have your name, ASUID, so we know who you are. And then, okay, for level one, I did this, and for level two, I did this. No, you can use whatever email you want for WeChall. That's totally good. So, then the, and then when you submit, so you'll put your, a line in your text file called WeChall space name colon, and then insert your WeChall name here. And then we will, this is how we automatically grade it. So, this is why we do all these linking. So, we can actually check that you've solved these things. And when you do that, it should all work and you'll get, you know, right away that you've solved that. And then we'll go and you should be able to see it. So, the, okay, and the important thing here, so Bandit is a system that's been around for a long time. If you Google around, you will find the walkthroughs of how to solve these challenges. You'll even find walkthroughs that just give you the password and do whatever, whatever else you want. You know, I, the purpose here is to have you develop your skills because these are gonna make you be successful in the future assignments. So, you know, I think it would be who of you and it will definitely improve your abilities in the future if you take these and approach these and don't look at walkthrough. So, yeah, that's my advice. Like, cool. All right, and the third part is getting familiar with make files. So, most of the coding assignments in this class will let you choose whatever programming language you want to do. So, you can write your program in Java, you can write it in Python, you can write it in C, you can kind of basically do whatever you want. The only way we can make that possible is through make files. Has anyone had experience with using make files in their previous classes? Yeah, what class? 340, I saw 210, 310. Okay, cool. That's awesome. The basic idea, and I linked to it here, but a make file is actually a really cool way to specify how to build a piece of software. So, you say, okay, I need to build certain files and to do that, to build this binary, I need the certain C files and these are the programs that I need to run in order to build the file. And it's super flexible. You can do a lot of really cool stuff with it. You can use Prolog Swift. I think I've seen, not for this assignment, but I've definitely seen crazy stuff in my other classes of what kind of languages people used. So, there's a ton of good make file resources. I highly recommend, if you're not familiar, read through these resources. They were compiled by past TAs and that the students have found them super useful. And then you'll make two different make files. So, this is what we're gonna be practicing. So, you'll be able to write a make file that can compile a C program and another one that runs on a, or that can compile, quote, quote, and we'll see that in a second, a Python program. You don't have to know anything about C or Python to do this and I'll show you why. So, the pro, well, you should know something about C already. The programs are, what is this? Two lines of real code and like five lines of actual code. So, you need to create a make file. So, you're given this program.C and you need to create a C underscore program executable. So, assume that your C program make file is called make file.C. I realize it's a little weird that file extension is named.C even though it's not a .C file. Please forgive that bit of ugliness but this allows you to submit both of them at the same time and the system knows which ones to use. So, just roll with it. Hopefully, this should suggest to you that file extensions are not important at all and they're completely made up in arbitrary. So, if you put this make file.C in the same directory as C underscore program.C this exact file here, when you run make-f make file-c what this does is normally when you run make it executes the instructions that are in a file called make file. Here we don't have that file we have a file of make file.C and so you should compile C underscore program.C into C underscore program using GCC. And the other important thing with make files is it should recompile the binary when your source program changes. That make sense? Yeah, so you can definitely use general. You can definitely use general for this as we'll get in a second to the next part you'll want to be able to the assignments need to run and are tested on a Linux environment. So you want access there. So, okay, so then for the Python make file. So this is a little bit different as people said. And again, this is a what is this three, four line Python file. So it's just prints out hello world from Python. It's a very simple program. So again, you don't need to know anything about Python for this. But the idea is you want to turn this Python underscore program to PY into an executable file called Python underscore program. Now why this is tricky is what people mentioned in the chat if you're not familiar with Python, it's an interpreted language. So typically to run a Python script, you would say something like, can you see, can everyone read the screen? Is it big enough? Okay, great. Okay, so now I have, okay, so I have my Python program here. So normally when I run this, I would run Python, Python program to PY it's going to run and execute. But what I want to be able to do is to execute it. So just like how I typed in Python here, what I'm telling my shell is I want to execute a program called Python. And so now we'll get into it later, but how it finds that is it uses your path and figures out it's actually executing this program, which is getting too complicated. We will pull back and not worry about any of this and we will just worry about, but the problem is if I went to try to execute program.py, that would not be possible. But if I went copy link, if I get this C program and I run GCC out, let's say C underscore program. Okay, yeah, that was weird. I don't know why that froze. Okay, now what file does GCC make by default for our program if we don't specify the output? Yeah, a dot out. So why can't I do a dot out like this? Yeah, it needs to figure out where to find it, right? So I need to do dot slash a dot out to say, hey, in this current directory in temp, I want to execute this file a dot out. So I can execute that and it'll say, hello world from C, excellent. So I can do that here, but I can't do that here. So, ah, I didn't change that. But there are ways that Unix allows us to do that and that is with what's called the shebang functionality. So if we check that out in Linux, it basically says that if the first line of a file starts with a hash and then an exclamation point, it takes whatever's after that as the thing to execute and it passes it the argument of this file. So if we look at the start of Python, our Python program, we can see that it actually has this part. It has a shebang where it has a hash and then a bang and it says, okay, what I want you to do is slash user slash bin slash env and call Python. So env Python looks up and figures out where Python is and then it passes this whole thing to Python so that the end result when you can finally execute it is like that. Now, the reason why I can't do this Python program, let me do it again so you can see it. So it says permission denied and if I look at the file permissions, and again, this is why the other parts of this assignment are so important, you'll learn how to look at file permissions and those kinds of things and explore the file system in the bandit levels. So we need this to file to be executable. As we'll see, nobody can execute this file. So if I make it executable, list the permissions, I can see anyone can execute this file. I execute it. And now it does it exactly the same as if I actually technically does, what's this file like? It's exactly the same as if I went user bin, EMV, Python, ENV, and X means executable. So chmod means change the permissions of this and add executable. So we'll actually go deep into when we talk about access control of exactly what. So you'll be able to by the end of this class understand exactly what each of these bits means in this output. But for right now, what you need to know is that it needs to be executable and this will help you do your assignment. So popping back up the stack and going to where we need to be. This is why, where are we? Yeah, okay. So this is essentially what your make file will be doing for the Python program. Yeah, chmod is exactly, that's the meaning of it, I believe. I think it's, yeah, change the file mode, basically. Yep, great. Okay, so this is what your Python make file needs to do is to be able to turn your Python underscore program dot py into an executable called Python underscore program. But again, because it's Python, it's not compiling it. All you need to do is copy over the Python underscore program dot py to the correct name and then make sure that it's executable and then you should be good to go. Cool, so when you submit this, you'll submit the Python make file is make file dot Python and the C make file is make file dot C. And then it'll test it and submit. Yes, so yeah, so somebody was asking about if it's read in my terminal. So what my terminal, I think it's ZSH or something is doing, I actually don't know exactly what it's doing, but something is has changed the output. So when I LS this, it says, okay, an executable file should be read and that's why this one here is not executable. Yes, so somebody asked in the chat if you need, if you're allowed multiple submissions on grade scope, yes, you're allowed unlimited submissions. Cool, and then going forward, so now we're going to look at how we can write programs that receive input from users through command line arguments. So as a brief little tutorial, so here I'm executing the program ENV, specifically the program that lives in slash user, slash bin slash ENV and I'm executing Python, I'm sorry, I'm sorry, I'm executing this program, this binary that exists on the computer and I'm passing it the command line arguments of the first one is Python and the second one is Python underscore program dot py. So this is how we can execute a program and pass different parameters to it. So what your goal is to do is to just write a program that modifies the command line arguments. So you're gonna write something that will be called command. So the eventual thing is the command and when you execute the program with foo bar, it outputs first the number of command line arguments so it'll be two and the next line it will print out the arguments in reverse order. So it'll be bar and then foo. So if you just run command normally, it should just output zero and then an empty line. If you run it with command AB, test space input CDE, it will do it in output six, it'll do it in reverse EDC test under space input B and A. Any questions on this functionality aspect here? Cool. Then, okay, so then the goal is it, so we have to have a standard system because we can't be dealing with though I have this version of Linux and it doesn't work. So the standard that we're using for all of the submissions is Ubuntu 1804 64 bit. So with the default packages installed, if you need more packages, just ask and I'll install it for everyone. I have a bunch of stuff installed. I think Java, Ruby, I think crazy stuff that is in there. So I'm happy to always add more. If somebody reminds me, I will add to this list and I'll put what the other ones are. Yeah, you should be fine if it works on general. So the goal is, if there's any disagreement at this level with a very simple program, I don't think there's gonna be any discrepancies between general or Ubuntu or Ubuntu 20. But again, if it comes down to it, it's gotta work on an Ubuntu 1804. And then you also need to do, create a make file specifically. So make file called make file that when you run make compiles, whatever it is in your source programs to create the program called command. Yeah, if you pass grade scope, you're fine. The only reason I have this in here is just so that we're all 100% clear on what the target is. So if you wanna use a VM, if you wanna use a virtual box, you can download for free and install an Ubuntu 1804 64 bit VM. If you absolutely can't get access to something, please let us know. We can spin up a server for you and so yeah, I don't let that stop you. Cool. And then submit on grade scope. Yeah, again, just like always, this is gonna be a standard thing. So always write a read me file, plain text, name, ASU ID and description of how your program works. This just helps in case there's any issues with your submission. Any questions on the assignment? I have a question. Yep. Do you submit anything for part one or are we just doing it as fine? So we will, yeah, just do it. And so we'll know if you registered based on your name or ASU ID. So if we have any questions, don't worry, we'll contact you directly. Thank you. Okay, somebody asked how long it takes to finish the assignment. That's kind of up to you. So it depends on how familiar you are with these things. So I don't have a good timeframe but this is why we gave you a week and a half on something that's a pretty, compared to the other assignments, this is on the low end of difficulty. Yes, three make files exactly. So two for the make file part and one for the command part. So question is for the description in the read me, a plain, you know, pretty, just an overall description, right? We wanna see that you actually wrote this and know what it is, right? So you can write. So somebody's, yeah. So for each part you need to read me. So you should always do a read me and you'll submit it with your assignment. Okay, cool. Let's, and if you have further questions, you know, always chat on Piazza, also monitor the Piazza for people's questions. We'll be happy to answer this and we should be able to rock and roll. Cool, then let's go back to the PowerPoint. Okay, so we ended talking about threats, right? So why is talking about threats important? Why do we care? We're talking about security generally. We're kinda getting, we will get, as we see more and more focused on, you know, kind of cybersecurity, but I wanna get you into this security mindset now. So what are threats that, like why do we even care about these threats? They can ruin the infrastructure of our computing network and market company. Yeah, so they could ruin, they can violate, right? So if we take it back to the triad, right? What was the triad again? If you drop it in the chat, I'll see it. Yeah, CIA, so confidentiality, integrity, availability, right? And we wanna make sure, so somebody else made a good comment that we want things to work as intended, right? So we want things to work as intended. We don't want unauthorized people to get access to our data. We don't want unauthorized people to change our data and we don't want people to be able to take down our service. So this is something that we definitely need to be aware of and think about and this is why we need to understand what are common threats specifically because we now then want to talk about, well, how can we actually defend against these threats? And so we'll look at basically two different ways. So we're gonna think and throughout this course, we kind of have to have this dual mindset. We need to think about ourselves as, okay, what are we, we just have this adversarial mindset to think, how do I attack this thing? And then we need to think of the defender's mindset to think about, okay, how can we defend this thing? Question I like to think about. So have, well, we'll get there in a second. Okay, so what we think about is in terms of two different aspects, and this kind of helps us to frame our thoughts about threats and how to counter threats. So they're very broadly, and this is a, it's kind of one of these things where you have a kind of these academic terms of a security policy and a security mechanism and properly thinking about and defining exactly what things fall into what categories can be fraught and slightly difficult over time with different things. But the way I think of it is like this. So a security mechanism is something that tries to enforce some sort of policy. So if your policy of let's say your car is, I would like only me to have access to my car and to be able to drive my car, right? So a policy is essentially kind of intentions or, and it also involves, so another policy could be, I'm gonna be the only, so a mechanism that would enforce that policy with your car would be your car keys, right? So if you think about just standard car keys, right? So how does that the key mechanism actually help enforce that policy? Yeah, so whoever has possession of that key should be able to be the only people that can access the car or start the car, right? Yeah, so only that, but is that mechanism alone is a key of your car itself enough to ensure that nobody else can get access to your car? How could, even if you have a key, how can you actually make sure that nobody else gets access to your car? Yeah, so that somebody made a great point in the chat, you need to have locks? What else do you need? So people are talking about in chat, alarms, windows. So what do you need to do with the windows? Let's focus on one things. If you want people not to be able to access your car, what do you need to do? Yeah, roll the windows up, right? So you wanna make sure the windows up. Why? Because if you don't roll the windows up and you're the only one with this key, are you the only one that has access to that car? No, exactly. So because other people can then get access to your car just easily through the windows, right? So you need a, now, in order to try to ensure that nobody can get access to your car, you'd need to have a policy that says, whenever I've stopped driving, I need to roll up all the windows in my car, right? And you'd use the window mechanism to roll your windows up in your car, right? So that would be another policy that you need. And if you follow that policy, then you should be secure against leaving your windows open which allows people to go in. What other types of policies might you need in order to secure your car? So park it in a safe spot, that's good. So park it somewhere where people aren't likely to do it. Yeah, that's a great one. So Eric in chat just mentioned lock the car, right? We didn't even talk about that because it's almost something that's so innate to us. But just having a key and having a lock mechanism on the car doesn't mean that it's safe from people getting into your car, right? You actually need to have a policy that every time I leave the car, I need to make sure the windows are up and I need to make sure to lock the car, right? If I don't do that, then somebody can access the car even if, and we haven't even talked about, you know, people using car jacking or other types of tools or breaking your windows, assuming your windows are unbreakable and your locks are the perfect locks and nobody can break it, if you lock your car every time you leave, right? Or if you don't lock your car every time you leave, it's still that the other people can get into your car. What are, so let's say, okay, let's go with this. Your locks are perfect, can't be broken. Your windows can't be broken. And now you have a policy with, so those are your mechanisms, they're perfect, although we'll see that no mechanisms are. Your, you always close the windows when you are parked and before you leave, you close the windows and you always lock the car. Are you safe? What are the policies? Someone can threaten you. So someone can threaten you for access to your car? Yeah, let's take that off the table for now. Can't they like disconnect the battery and disarm the alarm and the security? Let's say that it's perfect, even that. I'm thinking more basic. So somebody could steal your key, that's great. So somebody could steal your key, you need to make sure you always have the key. The car, the stealing the car is great. They can actually just put your car on a truck and just haul it away. What else? They can get in through the trunk, that's a great one. So you also need to make sure your trunk is closed. If your trunk is open, they could possibly get in. Social engineering, anybody you leave the keys to, that's a great one. So they've done that. Well, something simple. There's something simple that we didn't talk about that. Maybe you don't even think about. So what do you have to do? So put yourself, you're inside your car, you're about to leave, you roll up the windows, turn the car off, take the keys out, get out of the car, close doors, that was great. I didn't see who put that. Sorry, man, this chat sometimes blows up and it's really difficult to tell. You actually have to close the door. What if you just locked the door without closing it? And now you have a locked car with the car doors open, right? So this is, right? So you can see how you're beginning to see how these policies and these mechanisms can work together, right? So sleep in the car and never leave. That's actually pretty good. Although I guess that doesn't prevent other people from coming in, but I guess it depends. Cool, okay, so yeah, this was a good example. So this is, we'll talk, we'll get into this more and more as we go, but this is kind of gets across the general idea. So does anybody work at like a corporate company? How does access to buildings in some places work? Yeah, so an ID badge, so you have an ID badge and so that's a mechanism, right? There's an ID badge, there's mechanisms at every aspect, but is there any policies associated with that? Yeah, what kind of policies? Is that something you want to say and over voice? Yeah, because I work for one of Fulton's IT departments. So all of ASU has a system called ISIC, which is basically those little swipey panels everywhere. And there are, it's a really old server, but there is a list somewhere on the Fulton server that has all these groups and stuff of who can unlock what doors and like there's a, theoretically, I think a student could be removed from like the student group and then you'd just be like screwed, couldn't unlock anything, but yeah. Yeah, and like I'm on a special list that gives me access to like the labs, the ID department services. Great, yeah, so those are all policies, right? Of who can access what, right? And who should be able to do what? Another policy that you definitely have to think about and that comes up a lot in different organizations. When I worked at Microsoft, they tried to hammer home the fact that don't let people walk in behind you after you badge in. So like you should check to make sure that the person behind you also badges in because otherwise then that violates the policy. Yeah, the question is that's, you know, you have to think about and we'll talk about it later. Is that actually human nature for you to challenge the person behind you with their thing? I actually knew this is probably a good time for this story. I heard a story from a person who works at a local company here who used to do physical pen testing. And he said the way I, so physical pen testing is they basically hire you to break into their building. So they say, get to this floor and then we'll pay you basically. So what he did is he'd always go in the morning, be dressed nicely with a suit and whatever and he'd always have like McDonald's or something. So he'd have a cup of coffee and like a bag of food in there. And so, you know, he would wait strategically and go right when somebody was going and be like, oh, I'm so sorry, like I have my stuff and my badge. I just can't and they would, you know, he'd have something that looked like a badge on his hip but it wasn't a real one. And so they would just, you know, open the door sometimes. He said sometimes the security guards themselves would be the ones to open the door and let him in. So yeah, that was great. So yeah, this is kind of again, an example of policies are both are important. If you have a policy without a mechanism, you're not going to be able to actually enforce anything. And if you just have mechanisms, like if you just installed card readers on all the doors, well, then what's the policy for who should have access? And if we get more into it, you think, well, who, sorry, I forgot. Oh, Jack who said that, who worked there, right? Yeah. Yeah, so like, should Jack just be able to change and add anyone to any group in Isaac's, right? There's policies that dictate who should be able to change those, that access, right? Yeah, and I can't. So the mechanism in that system would be the little Isaac card readers, right? Exactly. Yep. That's great. Awesome. Cool. So now I want to talk about, we're going to kind of do this similar exercise but in a different way. So we're going to talk about a house. So we want to defend a house. And so let's first, whenever we're thinking about this, we need to go over threats first. So what kind of threats are you guys going to care about? Or do you think we should care about? Is it a smart house? Like does it have like a lot of internet connected devices? Okay, is it a smart house? Does it have internet connected devices? Why is that important? Because they may or may not be able to be have to enter remotely. Yeah, so this maybe changes some policies or mechanisms that we need to put into place for those devices if they're absolutely necessary. Great. Yeah, somebody made a joke maybe of Alexa Unlock My Doors but actually there have been news stories where people did stay, were able to activate an Alexa from outside the house or another device and be able to get them to unlock a door. Yeah, okay, so that's great. So what other threats? So we need to think about if there's IoT devices, we need to think about is there a way for an attacker to activate those IoT devices? Check how well the actual physical locks are on the doors. Can you say that again? Sorry, I can pump up my volume I think. How well or how well the physical locks on doors and windows are? Yeah, so we may wanna, so we need to, so some of the threats, so to take that to a threat, right? We need to think about what are ways that people can break into our house, right? So we may need to think about burglars busting into our house. Yeah, so we'd wanna think about those aspects. Any other threats? What are some other threats that? So fire, great, Brandon, that's a good one, right? So do we need to be considered about fire or concerned about fire, right? Which of the CIA triad would a fire affect? Yeah, A, availability, right? If our place burns down, we now have nowhere to live and we would have failed at defending this house. Awesome, what other threats? Weather, so in the similar vein, weather, flooding. Should we be worried about aliens coming and sucking our house up and taking it to another planet? What's the trade-off there? So some people are saying more or less real and not real answers. It's super weird to see this stream of your guys' thoughts, but it's kinda cool too. At some point it becomes pointless to say like I'm not gonna try and stop my house from being destroyed by a nuke. There's no point and it's not within my means to do that. Yeah, exactly, so that's great. So the way, and really what we need to think about and something we haven't even thought about, so let's, we'll get there in a second, but we also need to be thinking about when we're thinking about these threats, what are the different probabilities of those threats, right? So we need to analyze the threats and say, ah, is this a highly probable event that we should be thinking about or not? And so that's definitely something we need to consider. And so we also need to think about policies if we wanna try to defend this house. Mechanisms, so people have said this, I think the classic one is locks, right? So, and let's think about the way these are connected. So what kind of locks should we get? Yeah, dead bolts, window locks, eye scans. So when might it be appropriate to think about eye scans to defend a house? So like that'd be a retinal scan, so I guess a second layer of authentication, which we'll look at later. Yeah, so why wouldn't, so a retinal scanner would be a mechanism. So why is that not common in every home? Why don't all of us have retinal scans? Yeah, expensive, right? Cost, so that's, and also, but are there homes that you can think about where maybe you do want a retinal scan? Like what? Yeah, Bill Gates' house, that's a great example, right? So the really important thing we didn't even talk about yet, right? Think of where we've gone in this conversation and we haven't even talked about what type of house we're defending, right? Who lives in this house? What type of things are in there? That's a good one. Is it Batman's house? Is it Wayne Manor where we have to hide stuff? Or is it just a normal person's house? Do I need to worry about a threat of my lovely students trying to come to my house to extort me to change their grades or something? So yeah, these are all things that, and we can see that, okay, we need to understand the system, right? We need to understand the house in order to understand the threats, which then we can use to estimate the probability of a threat. And then that impacts the policies and mechanisms we put into place, right? And the other aspect there we didn't touch on that people are talking, we're talking about in the chat earlier is the other aspect there is the budget. How much budget do we have, right? If I told you that we need to defend Bill Gates' house and I gave you $1,000, what would you actually do there by him and Uber so he can leave his house? Yeah, that's pretty good. He probably has armed security. Yeah, he probably does, right? He probably has like round the clock armed security around his house. He probably has video cameras everywhere, I mean, you know, and then think about, you know, the difference between that versus like a bank, something like a bank. So these are all really important things. The other thing we didn't talk about in terms of this is we didn't even talk about the nature of the house itself. Why would it matter if we're defending a two or three-story building versus a one-story building? Yeah, multiple entrances, multiple access points, right? We may need to be worried about somebody and we also need to know, is this house in the middle of nowhere? Is it surrounded by other houses? If it's surrounded by other houses, is it possible to go from a roof of a neighbor onto our house and then go in through a window or I guess the chimney does make sense, right? That's a great, so somebody just mentioned in the chat, can you trust the people in the house, right? So the people in the house, can you actually trust the other people that have access to the house? So if I invite somebody untrustworthy and they have access to the whole house, will that give them access to something we don't want? Yeah, any other examples? The environment the house is in? Yeah, the power grid, that's pretty good. So especially when it's something like a bank, right? I think we've, I did just rewatch Die Hard over Christmas with my family and their whole plan hitched on the power getting cut and that caused the bank vaults to like open at the right thing. So if you have a house alarm, an alarm system, but if you think about the way the house is made, right? So if you have a beautiful, perfect alarm system, it's connected to the power, but the power lines are outside of the house. So all I need to do is go there, cut the power lines and now your beautiful mechanism is rendered useless because of this problem, right? So yeah, you need to think about backup generators, right? If we're in charge of defending this house. Phone lines, that's a great example, right? Let's say there is a problem and this actually has corollaries with the security stuff we've already talked about, right? So all the things we've talked about so far are really examples of prevention where we're trying to prevent something from happening, but what if something happens, how do we get help? How do we detect something and how do we react to it and mitigate it as we'll see, right? Yeah, this is great, cool. Okay, so we've been doing this, we'll do another minute 20 on this. I wanna do 10 minutes. What's the access? Yeah, what's the access to the house? So that could give you a heads up basically on who's coming. If you're in a rural house in the middle of nowhere, people can, you would see them approaching if, of course, assuming you're monitoring, right? That's the other thing. So I wouldn't say it's worrying about how good we are breaking into this house because that's our job. So actually, this is a good point. Have you ever been locked out of your own house or apartment or whatever before? Yeah, and didn't you look at your house completely differently now and thinking of like, okay, how can I break into this house? How close is that tree to the second story bathroom window that I know is unlocked and open? Yeah, I've definitely done this before. So this is, and this is part of what we're developing in this course. This is the adversarial mindset. This is looking at a system, thinking about it adversarily and think about how can I break that system? So yeah, it's important part of defending and also being proactive about when you're even writing code, you think, okay, but how could somebody misuse this as we'll eventually see? So yeah, that was great, awesome. Well, thank you everybody. I really appreciated that. Cool, okay. So like we said, and I'll use examples that we talked about in the house example, but some of our goals here with our security policies, it was we want to prevent things. So what were some examples of policies that we're trying to prevent things in our house example? So locks are mechanisms, right? Those are actually physical things. Lock door when you leave, thank you, Tyler. Yes, family has access, awesome. Right, outdoor security signs, yeah, exactly. So those would be preventative types of policies. What were some detection types policies? Yeah, an alarm system. So yeah, if you think about it, alarm systems really don't prevent anything, right? They don't actually stop anybody from entering. And this is an important thing to keep in your mind. You want to prevent things, you want to detect things, and when they detect something, you want something to actually happen. And then the third aspect is we always will, it forms this circle. So we always want to prevent and then detect and then recover. So yeah, this would be, this is great. So yeah, these policies, so in let's say a computer system prevention, a prevention policy would be always install the latest software updates for your systems, right? And so detection would be run an antivirus system that tells you if there's a known piece of malware on your system. Recovery would be, okay, when you detect that there's a piece of malware on your system, completely wipe that machine and start it from scratch so that you know that it's in a known good state. Does that make sense for recovery? What would be a piece of recovery for this particular example? For which example, sorry? The house example. So recovery would be your house has either gotten robbed, has been robbed. So that case you're kind of, so maybe you can use your alarm system at a video camera or like the things that they have on ring cameras where people steal the packages from their doorway. They have the picture of them and so they're able to find and recover it through there. That would be a type of recovery. So like evidence, but what about insurance? Yeah, so that's great. So insurance would be another way to recover from it. Yeah, that's, I should have used that one, right? So yeah, that would be, and that's a policy that's literally called the policy, right? That you purchase so that in the event that something happens, you have a way to recover from that. Yeah, that's great. And there's actually a, I don't know if we'll go into it a ton, but there is a kind of newish area of cybersecurity insurance policies which are pretty interesting. Cool, that was great. And so how can we define policies? So how have we defined them up until now? Yeah, loosely or rules. I'm talking like pretty natural language, right? Literally with English words, we say things like we want it to be the case that every time we leave the car, we lock the door, we roll up the windows, we make sure the car is locked in all the doors and the trunk is closed, right? So we're saying that with English. What's a problem of natural languages? Vague. What's for interpretations, that's translate? Exactly, open to interpretations can be misinterpreted, vague, all of those things, right? So I may say one thing and you may interpret it differently or somebody else may interpret it differently, right? So yeah, the opposite of that would be mathematics, right? So formally define exactly what we mean by a security policy. So we can formally say exactly who should be able to do what and access what sort of things. What are some of the drawbacks of using a formal mathematics type language? It's constricting, there's only so many theories. Yeah, so it may be, I would phrase that in a different way in terms of expressability, right? So your formal language may not be able to express everything you wanna be able to express, right? It may not be able to say, oh, the CEO's brother needs access every other Wednesday to the facility, right? And if that's one of your business rules and you can't express that in your language, then you can't actually implement the policies that you need. Other people in the chat had great examples of it's really difficult to understand and this is something I totally sympathize with. I'm very much not a formal mathematical person. And so understanding and being able to interpret what does this policy mean in terms of mathematics, it may be simple to enforce because the enforcement systems understand that formal language, but for a human to reason about what that means, that is actually an important part. Yeah, cool. Great, so you can see that there's these kind of like big gaps in between these two, right? These are at polar opposite ends of a spectrum. And so policies can kind of do a little bit of both when you kind of read the like ASU acceptable use policy and those kinds of things which you've definitely already agreed to at this point. You need to be thinking about that. So, okay. And then there's the third aspect, which is something that is really important is kind of something in the middle of what's a policy language. So, there are languages that provide like a meta language to describe some sort of policies. So there's like XML, okay, my dog's going crazy. Okay, cool. There's, you can define policies in XML. So it's a specific, essentially a domain specific language to describe a security policy. So it's not infinitely expressive, but it's a lot easier to understand and a lot of tools actually can use this kind of thing. So, cool. Okay, so then we have different ways of describing policies. So then I guess to start off, do we even care that a security policy is correct? Yeah, why? Yeah, so if it's not correct, it doesn't properly address the threats that we think it does, right? So the entire point, so we would never implement a security policy that is not countering a known threat. So therefore, if a security policy is incorrect, meaning it doesn't address one of our threats, then that's a major problem that we need to think about. So, we always need to think about in terms of, and what I like to think about is in terms of assumptions, right? So, whatever way we're specifying our policy, what kind of assumptions is it making about things, right? So, what assumptions did we make in our house examples for some of those policies? So yeah, Christian, great. So that we close the door. So, we want to assume, so we want to, we assumed in our policy that people would actually follow these steps, right? So, and as we can see or maybe, actually the car example is probably a good example of this. So, newer cars don't even have actual physical keys anymore, right? They have a little fob that when it's inside the car, it's unlocked, or when it's near the car, it's unlocked, but when it's far away, the house automatically locks. So, it actually is a mechanism that tries to counter this problem of assuming that people who will actually follow your security policy. Yeah, so that's great. So, there's tons of examples. We also are assuming that the policy itself is correct, right? We also assumed that the mechanism correctly implements the policy. So, one example, I'll tell. So, I think this was back in 2004, the security group that I did my PhD at, I wasn't there at the time, but they were hired by the Secretary of State of California in order to analyze some digital voting machines. So, it was the machines where you put in your things, your votes or whatever. And so, when they went in their first day, so they're there to perform a red team experiment, so try to break it as much as they could. They went in there and the people running this facility basically said, these locks are the best locks money can buy. You literally, they're diamond, whatever, things, they have, there's so much permutations, it's impossible to crack this key. And so, the professor there, Dick Kemmer, was the person who was telling me this story. He said, okay, cool, nice. And just got all the information. And so, the very first thing that he did, what do you think he did? Do you think he tried to attack the device, the lock? Yeah, saw if it was even locked, that's a great one. Second thing, looked around the machine and saw that there were just some screws on the back. And so, he was able to unscrew the back and it freaking opened from the back and they got access to what was just a normal PC right there. So, yeah, so this is a problem of when you think that this mechanism is actually implementing your policy, but because of flaws in how things are designed or used or different mechanisms, there's a famous case of the, you know, the U locks for bicycles. So, it's like a U-shaped lock like this, right? So, some of the older ones, I believe, had kind of a circular style of keys. You could just take a big pen. So, you could take a big pen, like just a normal ballpoint pen and shove the back of it in there and it would just pop open. So, you, so yeah, you can just, so this is, you know, important things to think about and also things about trust, right? Why, so for instance, the example where we said we don't want anybody in the house that shouldn't be in the house, right? That was our, what we wanted to enforce. And so, how can we trust, you know, can we trust the other people in our house to not bring people in? So, all this being said, is this, is this, does this mean that security policies are worthless? Yes, they're worthless. I've been wasting your time the last half hour. No, I'm just kidding, they're not worthless, right? So, we need it. And the really important thing I want you to think about here, it's important that we understand both for a policy what assumptions is it making and what trust is involved there, right? Because then we can assess the risk just like we did with the threat, right? It's a new threat. The threat is what if our locks are really crappy, right? So, if our locks are really crappy, then maybe we need to have, so this is what we think about and we'll get to the concept of defense in depth. So, how can we maybe think about different layers of defense or other policies, other mechanisms to try to prevent these types of things? Yeah, so stopping people from getting too lazy to get around mechanisms is great, awesome. Cool, so this is why it's still very important and it's also, you can't just ignore these things. You can't just think, well, I came up with this policy, this means everything is great. You always want to think about what kind of assumptions are baked into that policy and what kind of trust is required for this policy to be effective. Cool, okay, so in terms of mechanisms, we have kind of two ways of thinking about these. We've kind of touched on this a little bit. This is just kind of more categorization. So, we can think about technical mechanisms which are basically saying like the lock, like the physical lock is keys are slightly difficult to lock pick and understand. And we can think of more a procedural mechanism, but I want to focus more on the security mechanism effectiveness, right? So, what makes a security mechanism effective? So, what are some of your ideas? What are important things here? They limit the amount of opportunities that an attacker has. Yeah, okay, so they limit the amount of opportunities that an attacker has. I'd say that it effectively does, so I guess that's inherent in effectiveness, right? It's trying to do exactly what that mechanism does. If you had a lock that if you just touched it, it popped open, that would probably be really bad, right? We want reliable security mechanisms, right? We want actually our security mechanisms themselves to be secure, right? There's actually been cases of where people have found security vulnerabilities in antivirus software, which is running at the highest level of privilege on your computer, at the kernel level. So, if malware was able to get on your computer, it would actually be able to exploit this vulnerability to elevate its privileges up and own your entire computer. So, we want our security mechanisms themselves to be secure because any flaw in a security mechanism means that now that mechanism isn't properly enforcing the policy that we wanted it to. We also want our security mechanisms to be precise. We want them to actually do what it's supposed to do. So, if somebody asked in the chat, since it's important, I'll talk about it here, can I just uninstall antivirus? So, the answer is no. So, antivirus, the way to think about it is this, and the truth is this is the way it works. So, the criminals have access to, they actually run websites like Software as a Service. So, you can go to a, pay money if you're a criminal, go to a website, you can upload, let's say, a virus or something or piece of malware that you're working on, and that service will run it on every single antivirus on the market, and it will do it such that it can't report the results back. So, what they do is they keep changing it and iterating it until none of those services can detect it, and then that's when they'll launch it because they know that nobody will detect it. Now, the entire ecosystem is very good. So, some people will be infected, but then that sample is found, basically new fingerprints are added and it gets pushed to everyone's thing. So, it's like you are much more vulnerable to attack if you don't have antivirus, but it's not an 100% effective mechanism. Does that make sense? Cool. And we also wanna think, so in terms of security mechanism effectiveness, we also wanna think of is the mechanism appropriate? Is it too broad? Is it overly broad? Or is it precise and does specifically what we need? So, an example of this would be for our car, I mean, I guess, well, oh yeah, let's say a, I mean, maybe this isn't a great example, but let's say our, no, that's not very good either. Yeah, so the notion is precise security mechanisms do exactly what they're supposed to do nothing more and we want that. We don't want them to be doing extra things because we may not have thought about them or configured that correctly. Cool. So, okay, so now we get to the notion of assurance, right? So this actually ties into the name of the course, right? The name of the course is information assurance. So since I brought up this topic, I'll address what's the comments in the chat. So basically, if you look at the share of people who are targeted with security vulnerabilities and malware, Linux just has such a small market share that nobody bothers really developing things for it, except for maybe servers and other types of things. So there's really no money in it. That's why actually back in the day, Mac had like a 10% market share compared to Windows had a 90% and so yeah, if you're developing an exploit, you wanna get the most people possible, which is almost everything, you would target Windows. So people had this perception that Windows is more secure when really, actually Microsoft did a lot of stuff to improve the security of their operating system over time. So yeah, there are strong economic forces at play here. I wish Gabriel Gates was paying me more, he's paying me zero. Cool, so assurance is basically, how can you trust that the system is secure? So I'll ask you a first question. Can you trust that a system is secure? No, never. I would say it's basically, so what would be a secure system of Bitcoin? Tell that to the person who has $220 million in bitcoins locked up in a key that only has two extra guesses. Yeah, something not digital, something not digital secure. So we saw in war games, right? How did the guy in war games get the passwords to the computer systems? He wasn't really hacking in, he wasn't guessing passwords. How did he know the password? Yeah, they wrote it down, right? They wrote it down on a post-it note by the desk, right? So even physical devices, I think the way that maybe you could think of a secure computer would be one that is turned off, not connected to the internet, is in a locked vault that is guarded by armored guards, but still is that perfectly secure? No, the thing you should always think about is if somebody gave me $2 billion, could I break into that thing? Or could I try, right? I could bribe the guards. I could tunnel in to the secure facility, right? So this is a really important thing and definitely an important thing I want you to take away from this course. You can never be 100% certain that something is secure. Now, does this mean you should just throw your hands up in the air and give up and say, well, if nothing can be 100% secure then I should just go home and not worry about it? Yeah, no, because we, and so assurance is the notion of how much do you trust this system? So thinking about the example we just talked about, if I know two identical Windows machines, one is running antivirus, the other one is not, I have more assurance that the one running antivirus is secure, right? So we, so this is the notion of assurance, right? We always wanna think about how much should we trust this system? That's really the key challenge that it is in there. And so information assurance is this notion of how can we trust information and how much can we trust that information? Even things like, we'll see crypto there, I mean, cryptography, there are ways to break it. Gosh, I've been saying too much Bitcoin chatter in the chat, right? We'll be talking about cryptography, things that are mathematically proven to be secure under certain conditions, right? And as we'll see, those have to be implemented on computers, which are programmed by people and there can be bugs in any layers of those systems, right? So how do you quantify assurance? So I just gave that example of the two Windows machines exactly the same, but one is running antivirus, the other is not. Through mathematical probability? Through mathematical probability. So what are you gonna give the two devices? So let's go with the, maybe probability that it's compromised. So quantified. So can you give me a assurance level, a quantified level between the two? How much security did I get for installing antivirus on this one machine? Yeah, we definitely know it's relative, right? We know it's more. I think we, I definitely would agree with that. It's definitely more. I would say I have more assurance in the system with the antivirus than without, right? I guess you'd have to look at it statistically. You have to do an actual report for it. Yeah, it's a difficult problem. And the reason why I propose this is because it's, you'd have to think on, so actually quantifying this is an incredibly difficult topic that is still not even solved at all. So, and to even begin to try and quantify it, you'd need to assign some weights, which must be either statistics-based, but those could be biased based on previous things because I can't really predict the future as to what types of attacks there are now going to be. Like I said, if it now turns out tomorrow that we know that this antivirus actually has a vulnerability that allows a remote person to easily take over that machine, I'd then switch my threshold, right? Because now I have more information or my rankings there. So actually quantifying this stuff is a really interesting topic for research because it's just so, so difficult, cool. So what we'll get to in next class is we'll talk about, and so this is what you can think about from now until then, what type of things impact assurance? So we talked about maybe security mechanisms. So we're gonna talk about all the different aspects that go into our system that can impact our assurance that the system is secure. So this will be on Tuesday. So no class on Monday. We will be doing live Tuesday, 10, 30 a.m. Show up there if you can. If not, we will catch you again. Thanks everyone.