Happy Thursday! Today is an exciting day. We, Jennifer and I, well I guess a school, we have a couple of big events today so I thought I might try to vlog. I'm on my way to Starbucks right now at 7.15 and I already placed my mobile order so all I have to do is get out of the car, run up and grab it, and then head to work. We have to be there at 8 o'clock and then we are going to convocation which is like a giant pep rally for the district. All the teachers and all these staff goes to the convocation at the local resort and we hear the superintendent's vision and all that stuff. So I thought I would try to vlog. We'll see if I can muster up the courage to vlog in front of all the other teachers. It'll be interesting and we take a bus right there and everything so Jennifer and I are obviously gonna sit together on the bus and we'll see how that goes. And tonight when we get back from convocation we have meetings from 1 to 4 and then we have Meet the Teacher Night from 5 to 6.30 so I'm crossing my fingers hoping that I will have time to go home between convocation and meetings. I'm hoping they'll give us a lunch break so that I can go home and like kind of get my clothes together for the night because I plan to stay at work between meetings and Meet the Teacher Night. That way I can put up a final bulletin board and just get really prepared for that because I I mean I'm ready like everything's printed out that I need but it would be nice to like have you know the room just looking perfect and I mean it's not messy or anything but just last-minute fixings and stuff. So yeah that's the plan. Sorry I'm vlogging down here I'm like in traffic and I don't want anybody to see my camera. Okay so I just got out of Starbucks and what I've been getting lately is just a grande iced coffee with two pumps of regular syrup and then two pumps of toffee nut syrup with a splash of coconut milk. It's so good and I get a grande coffee because it only has 160 milligrams of caffeine in it and as a pregnant woman I can have up to 200 milligrams a day so I figure if I drink it all in the morning then I can burn it off throughout the day and it's just fine and my doctor approved it and it's not a big deal at all and then I also get a trend to water that way I can reserve the water that I bring in my water bottle for like later on in the day this covers me for the morning and then I can drink that in the afternoon because when I go to work I'm drinking water and then there I have a big jug under my desk so that I can just fill it up and then I also get a spicy chorizo sandwich which is so delicious Jennifer and I did notice though we were looking through some of our comments on our YouTube videos and we noticed a couple of cranky people and I just wanted to let you guys know that the reason I have my comments upon approval is just because of all the negative people that are out there there haven't been a whole lot but there are some negative people and I just want to let those negative people know that you really don't affect me when you comment on my videos with negativity I just delete the comment so if you don't like my videos if you don't like me then don't watch them and you know you don't have to comment if you don't like video or just keep it to yourself because the only thing I'm gonna do is delete it so Jennifer and I just kind of were like well should we stop vlogging like should we you know take some time off and I said you know what no because people are gonna be mean they're gonna disagree with what you say and what you do and it doesn't matter you know if you stop then you're just feeding into them and so just keep in mind that this channel is a place of positivity and I do not I'm not gonna entertain your negativity so just a little side note there but I'm gonna go ahead and keep driving you to school oh I am wearing lip sense today I think if you follow me on Instagram you know that I started using lip sense and I'm wearing the color first love and the reason I love lip sense is because it lasts all day and as a teacher I'm talking all day long and you know drinking my coffee drinking my water eating whatever and the lip sense stays on so I plan to do more of like a chat about that in my upcoming back-to-school hacks video that will be posted on August 10th so if this video is up before that one then look forward to that one on August 10th I'm also gonna share a couple of makeup secrets with you guys for teaching and just you know a couple of other hacks for getting ready to go back to school because I know I'm getting ready I start school on Monday in today's Thursday so a lot of you guys are getting ready to start on the east coast and like in other places in the middle of August or in September so hopefully that will be helpful video and I think Jennifer's doing one as well so yeah so I'm gonna go ahead and get to school and then we'll see what I can muster up in today's vlog I don't know it's kind of still that awkward like I don't want to vlog in front of the other teachers even though a lot of them know know that I do YouTube I don't know it's just weird to me so we'll see oh this is creature and being trash in your bag Hi, Manny. Hi. Hi, Charlie. That was last night. Say hi, Rachel. Guys, this is Katie. Right here. Hi, Bronte. Ouch. We're back here. Katie, this is coming. That's okay. I'll just hide it behind Manny's head. Jennifer, I got some stories to tell us. Oops. I'm not in the vlog. I'm not in the vlog. I didn't vlog anything. Yeah, you're good. Hi, I'm Jennifer. I'm not in the vlog. I'm not in the vlog. I'm not shy. He hugs a plumber. I'm glad there's a toilet for you. We all hugged the plumber. I'm glad there's a toilet for you. We all hugged the plumber. I'm not in the vlog. We're on our way to the convocation. We're sitting in the back. In the back. I want to see the rest of the group. We got these sweet sunglasses. I have all of the T-shirts. All of the T-shirts. It's a separate shelf. It's a separate Tracy's stuff. It's Ailee's time. Yvonne's time. She's with Athena's daughter. What the heck? I thought I hit stop. We're going to the convocation. I'm feeling very greasy already. I'm too humid out here. I was just watching the video. We're eating good things. Rachel's ready for me to teach tonight. Everybody's getting ready for me to teach tonight. Guys, it's Rachel's first meet the teacher night. Are you pooping your pants? Look how cute her room looks though. She's getting some of my kids from last year because she's teaching fifth. Look how cute this room is. My vlog. And here's my room. So, up on the board. I just have one of these slides from Teach Create Motivate. And it says welcome students and parents. And then it just tells them all the things they need to do. With all the things they need to pick up, sign up, and then these are like extra pickups. And then all their supplies is going to go back here. And they can label their supplies if they bring bags of it. And they can put it under the table. And then I have Disney music playing. What else? Aiden, what else is going on in here? Hmph. You want an air rake? I'm filming. So, this is where we're going to sit. And then that too. And then that's another seating. That too. And then the supplies area. The supplies goes down here. And then the rest goes over here. And then the computers. And then that's another seating. Seating. Miss Valdez is a disc. Say it. Oh, look at the emoji. He's such a cute emoji. What are you doing over there? I don't know. Also, Aiden, if someone comes in I'll just drive into the front and I'll let them know that this is like an example of the supplies they need to get. Okay. The supply list is on the back of the welcome sheet. The supply list. Okay. Kill. Oh, I should tell them I got my new glasses. Yes, he did. I have my own case, my own cleaner.  My own stuff. I like that suit. Do you want to blow these up? Blow the balloons. Let's blow the balloons up. Okay, we'll tell them. So, we're going to blow these balloons up and then we're going to go and get our night started. Yes, blue and purple. Okay, bye. Hi, guys. So, Meet the Teacher Night was a great success. I had so many kids and parents come and I'm really, really excited for this school year. I think it's going to be amazing and I'm really excited to meet the kids that I didn't get to meet. I think I probably had over half of my class show up and the fun part was that I knew most of them because they were in Mrs. Reese's class last year. So, I already knew them. I already knew their names and I was able to be a kid that came in and just made sure that I showed them that I really care and that I'm really excited. So, I'm going to end this vlog here and I do have a back to school video as I mentioned earlier this morning. So, I hope you guys look forward to that. Don't forget to subscribe to my channel and click the little bell that's next to the subscription button because that will alert you guys when I put up a new video so that you can see all the fun that I have to share this school year. So, ooh! Excuse me, I just burped. So, I'm on my way home and I'm going to go to sleep. So, I will see you guys in the next video. Bye!


And let's get started. So welcome to the OkD documentation subgroup meeting for January 25th of the year 2022. Please take a look at the agenda real quick and let me know if there's anything you want to change or modify. I'll put the link in the chat as well so that folks can see it. And don't forget to put your name in the attendance and it looks like we have a couple of folks that haven't been to meetings before. If you want to introduce yourselves feel free to do so no pressure but if you want to introduce yourself either in the chat or live in audio and video go right ahead. Yeah, sure. Hi, this is Aisha and I work with the CFE team and with this flat team as a software engineer and really works with the VMware vSphere and CI related stuff. Christian introduced me for the OkD group and because I'm also going to participate with him as a co-speaker in a DEF CONS 2022 for the OkD presentation. Because I was always being really interested for OkD and I really like that's the community thing and I really like it. And I'm also really interested in OkD. That's why I'm joining this meeting and I wanted to say hi to everyone. Christian is not in the meeting, but yeah, I'm hopeful that I will be joining the meetings in coming weeks every week as much as I can and contribute as much as I can. Excellent. Well, welcome to the meeting. Anyone else want to introduce themselves? Hi, I'm Sharon. I'm also in the CFE team like Aisha. I'm new to the team. It's been a couple of months only and actually OkD is on the teams agenda. So I was just curious to know how we can help out. Excellent. Well, thank you for joining us and anyone else want to introduce? I think we have one other person. No? Okay. Well, let's move on then and let's take a look at the agenda and we'll start out with issues in the repo. Brian, are there any issues or pull requests in the documents repo? There was one from Sandro. Yeah, he raised one just off the meeting last week around the community section. So it's issue number 255 in the OkDIO meeting. I'll post the link into the chat, the Blue Sheen's chat. So I think we're probably going to need Diane to look at this one because it really looks as to what is the purpose of the external sort of the community site. And should we consolidate it? And I think the community site was more around the wider commons community that everything was meant to point to. But I'm not sure how many other projects are all that uses that and so I'm not sure we can answer that today. Yeah, so that was originally. So when I first started attending the meetings, there was this community with the charter, which were reworking the charter. You know, the new chairs and stuff like that were modified to that recently. And then there was also like, I think that's where the projects tab is, isn't it? Where was, there used to be a tab that had like the meeting stuff. Yeah, that's it. So under projects, there's like a, oh no, that's not it either. So there used to be a panel basically with all of the lists of tasks and whatnot. And I don't know, it's in one of the repositories. It might be, might have been in this one. In terms of the community stuff, do folks see a reason to keep it around? I mean, we're basically moving. Well, I guess the centers around the question, let me phrase it this way. Is there value in separating the web content from the administrative content? The community one is basically administrative stuff like the charter members, owners roadmap. Is there any reason why that should continue to be separated from the web content or the repo that has the web content? I guess, I mean, there's only five documents in it. And it, are we the only project in the community, in which case I don't think it makes sense, separating it. However, if this was meant to look at a wider set of projects, then I think it just makes sense. But if it's purely the OCD community, I think we should pull us into the OCD.io site or put it in the OpenShift repo. I don't think it makes sense having a whole repo for five markdown files. Right. Bruce, what do you think? Yeah, I know that makes sense to me as well. And I mean, if you look at the URL, it's like OCD.io class community. So it would seem that it would only be OCD.io projects. So why not fold it in? I think that there is a general problem that several other people have brought up, which is that our communications is extremely fragmented with a number of places where people could go. Some of them are challenging to get into. You sort of have to be invited and others are relatively easy. But I think that in general, if we can consolidate so that there's like one place as much as possible, that would be fine. Now, for community outreach, which is one of Diane's big concerns, that's a different story. And I know nothing about that. So I don't offer an opinion. Yeah, I think that this was created because the sense was that OCD was the community distribution of Kubernetes and Open. And that was the, you know, the tagline of it. And so I think that's why this was created, but I've never seen any other projects. And obviously there's no documentation in here from anything else. The last commit was the changing the charter or changing. Yeah, it was like changing the chairs and the format of the affiliations, which was something that I did and Christian approved. All right, well, straw poll vote seems to indicate that we'll do any of our other guests have any thoughts on this. Wanted to just be the regulars anyone else have any thoughts about, you know, repos and should administrative stuff like that's in this repo should be separate. Can it be folded into a single repo where we also have our website stuff and other files. Okay, doesn't seem like anyone has anything to add. So I think we should fold it in to the new. Let's do it when we make the change to the OCD project. GitHub. Does that make sense to do it all like it once. I think it makes sense to do it. And again, just for the new members joining. We are looking to create our own GitHub organization and put all our content within that organization, rather than within the open shift. GitHub organization, or I forget what the custom the CS customer support, which is where the website is. So at some point in the near future, we're going to pull everything into a new new GitHub organization for OCD. Thanks for that contact. Related to that change. I was just thinking about how, like, the best sort of GitHub name was already taken. And we tried to get it back and couldn't, which is not untypical, I think, with my experience as well. So now we have sort of like OCD projects or something like that. Yeah, project, that's project, which is not something that would occur to people to look for. So maybe we should task Diane to look into search engine optimization to move that name up in the list. So if somebody searches for a, you know, like OCD or something like that, that that one appears. And that will give people a way of finding it in sort of a natural way. Now we do have OCD and Git lab, right? I think that we did end up getting that. But. I thought that we did. Yeah. Oh, no, that's that one we couldn't get into. That's the Kenzo Acuda owns that one. What was the. Which ones? Is it that both of them were owned by somebody? Let's kind of remember here. Yeah, it's like both of them are like, they were created by people and then like never used. Okay, so yeah, we can't get Git on or can't get OCD on either of them, which is too bad. So, all right, let's talk to Diane. Well, I'll add that as an item here. So I'll add that. Talk to Diane about SEO. By the way, she will not be in the next few meetings actually she is taking a much needed break. So let's move on to the next item. Are there any pull requests that we should be aware of Brian anything that came in in terms of pull requests? Nope, nothing since the last meeting. Okay, great. New business, the slack down channel dev slack channel. You know, going back to folks maybe that didn't pick this up in the main meeting. There's questions about the value of having the dev slack channel. It's it's almost exclusively be used by people posting user questions, sometimes cross posting with the user channel as well. Does this group see any reason to keep the dev channel around? Well, I actually like the way it's currently formulated no. But I sort of had this idea of the two channels somehow being, you know, one more for admin issues and the other for actual user issues. Like people running applications on OKD would be the users and people administering OKD would be, you know, admin. And so I was originally like long time ago looking at the dev channel as being more for people trying to get OKD itself to work versus running loads on OKD. And maybe you have those two distinct communities. I don't know. But as far as people developing OKD, I would say they're not so many that they need a slack channel. You know, they can just sort of yell across the hall or something like that or well not quite that because they're some of them are different countries, but figuratively speaking. The one thing that I noticed is there's actually very few questions about running workloads. Very, very few. So I don't know that a separate one for folks actually running apps would be necessary. And I actually question the use of slack. And it really goes back to the, I mean, we have people cross posting because one, they're not getting answers quickly enough because it doesn't seem to be there's a huge community logging into everywhere to actually answer the questions.  So I think there might be some hesitation is are they actually for OKD or do I have to be an OpenShift paying user? I think there is some confusion around that. Certainly when I first joined the community, I saw that it's like, well, do I have to be a paying user to use this channel? And Red Hat don't use this as an official OpenShift channel. So it is very much a community channel. My tech is trying to push everyone onto the github discussions. Let's have one place to go for everything. I think I'd be inclined to as well because then you don't get repeat questions or you can point people to solutions and whatnot. As opposed to it's very hard to keep linking back to previous conversations and slack and solutions. So yeah, I'd be inclined to shut them both down. But in conversation last week, it was said that they want to maintain the presence on the Kubernetes. Yeah, I understand that. But even so, having the OpenShift name there, it doesn't sort of suggest that it's also for OKD. Yeah, unless you start reading the posts. So we could rename the channel or at least propose, rename the channel to OKD and see if that got pushed back. Right. Or OpenShift slash OKD or OpenShift dash OKD or something like that. Would it make sense? Or OpenShift, I don't know. Let's find out.  We'll see what the options are for that. OK, so this group doesn't have a problem with shutting down the dev channel. Because in the main meeting, that's what we talked about. So maybe that's the path forward then. Just say yes. OK, so the next thing is something came up last week that was kind of a surprise. It happened pretty quickly. Sandra organized a Stakeholders, OKD Stakeholders meeting on like Monday afternoon and it happened on Thursday. And it was Christian Glombeck, Vadim, Diane, myself, actually I had to watch it later because I was double booked. And a handful of other folks, Charo was there. The gist of it is that Sandra wanted to know for the virtualization efforts, what is the path forward? Sandra's here. Sandra, you want to talk about the Stakeholders meeting that you organized? Yeah, OK. Just caught me by surprise. I just joined it. I was actually in the RUCA-IO community meeting right now because of the operator's support there. So yes, I was trying to put together kind of the situation of the community and understanding what the stakeholders and what's the plan for the upcoming year or so. And I understand that it's a huge goal to try to understand what will happen in a year from now in the OpenShift area because it changes every six weeks. So it's really hard to... But yeah, with regards to the involvement for the OKD virtualization part, I understood from the discussion that we had that there is a good opportunity there to have good support from the OKD community on that. And so I believe that it will be a nice contribution there. One of the things that just now in the RUCA-IO community meeting they raised is that they fear about having confusion between the OKD version and the OpenShift version of the operator. And out of the stakeholders meeting, it sorted out that there is a plan for having a dedicated OKD operator app. And this will solve this issue. So I'm pretty sure that this will help getting also the RUCA-IO operator into OKD. Right. And one of the things that Diane suggested at that meeting, and I'm going to move forward with that, is that we assemble a subgroup for operator stuff because this has been sort of ongoing. We want to address it, Bruce. I know you're very passionate about it. But it seems like a good idea. Maybe it's an async subgroup. It doesn't have to meet, but just defining tasks and pushing people to get that community operator catalog. The OKD community catalog created separate catalog for OKD and then get it populated with all of the operators we know and love. Is there any opposition to that idea? Yeah, go ahead, Brian. I was going to say, I mean, one of my, I guess, frustrations with the OKD project is when things happen behind closed doors within Red Hat. And as a community member, you just feel you're helpless in getting anything done. So is this going to be an operator catalog that's built as part of the Red Hat and build process, internal build process? Or is it something that we're looking to own as a community? Did you actually talk about how it's going to be manifested? Is it something that conversation? I can speak to this a little bit more, but and other folks who were at the meeting. Live, but it is that there is the person who currently is the point of contact for catalogs, right? I have no specific answer for that because I don't really understand how the catalog itself works, but from what I understood is a bunch of configuration files in a GitHub repo. So I believe that it can be completely on community side. The issue currently is it's built using prow. All the images are built using prow. And so, for example, if I want to customize it, I go through this sort of chase through a lot of repositories to try and work out how I can replicate the build. So we have like in a traditional open source repo, there's usually an instruction says how to build this. Where I think the Red Hat ones talk about the internal prow, build process, CI process, and there's all sorts of linkages in with that. And you look at a single repository and it just links to other repositories and it just seems to be an endless chain of trying to follow stuff through and missing information. And then if you want to do anything, if you want to suggest an update, we're locked out to those repositories because they are Red Hat repose and the community members have no sort of permission on there. So this is going to be specifically for OKD. Is it going to be done as the product is done, or is there an opportunity to actually open it up a little bit. So we have some control and some say in the operators. I think that that's a question for this subgroup to find out and do the research and meet with Red Hat. We have some names of people. There's the person that we talked about at the last meeting and then there's some people that came out of this meeting on Thursday that we can talk to. Let's get a list of people together who are interested in this topic. And maybe it's the same group. I don't know. Diane was suggesting a subgroup. There might be people who are interested in operator stuff but not interested in documentation. Let's get that group together work asynchronously and press some buttons and see what happens. I think we can do some research looping in Vadim, looping in Christian and looping in the person whose name I forgot already that we talked about at the main meeting last week and seeing exactly what is possible. I think, you know, I agree that a truly, a true OKD catalog would have to have some ability, there have to be some ability for us to make some modification to it. And have some governance over it, the OKD community to have some governance over it. I would say even if we can't modify it, if we can clone the repo and customize it for our own personal needs. I think that would be something where at the minute it's not obvious or trivial how I would do that say for the community catalog that's currently in OKD. I mean, that should all be public open source stuff. But trying to work out even how to rebuild that and get that configured into OKD is not a trivial task for anybody at the minute. Yeah. No, I agree. I guess my main concern would be that going from the current version to an OK version, we then cut the number of operators down by another factor of 10. And so we have an OKD catalog that has like one operator in it. And it is, you know, maybe the LCD operator. But you can, you can, it's an array, right? Isn't the catalog list, isn't it a list? It's a container. Yeah, it's sort of tricky though, because if like I was, I discovered, oh I don't know, a short while ago, that if you have an operator that's in the catalog that's, you know, that's managed, then you cannot have your own version of the same operator. So like there's a wild fly operator in the, oh sorry. Well, that one's actually not an operator, so maybe it doesn't apply to operators. There's a wild fly builder image and that gets tracked whenever they update the version. And it's generally a couple of versions behind, OK, fair enough. So before it was there at all, I could install my own, but once it's there, then it overrides what I install. And so there are some interactions with things, you know, like the sort of official versions of stuff then constrain your custom versions that you can put in normally. But now I've got like RookSeph installed and I'm using that for, you know, basically to allow people to create their own storage without my having to prove everything. And, you know, the RookSeph operator would be nice, you know, like I wouldn't mind going to that. I would, as long as it didn't blow away my existing setup and everything that's stored in there, that would be sort of unfortunate. But, you know, so I guess in principle, good idea, see what the details are. You know, like if the Red Hat people are willing to make that work, you know, then I'm happy to jump on and support that as best I can. Can I just ask another question? Is this meant to replace the Red Hat operators catalog that's in OCP? Or are we talking about the community operators that's currently in OKD? It's supposed to replace the Red Hat one, not the community one. Okay, so it's to avoid collision between operators that are in the Red Hat catalog with those that are in the community catalog. So if you want to push the same operator for both OKD and the OpenShift and you don't want to confuse the customers, you will have a way for publishing the same operator also for community. Okay, perfect. That's what I think that's the best approach. So we are looking at the Red Hat operators that are in the sort of the Red Hat catalog on OCP and releasing them. Yeah, great. So things like the tech on the pipeline, the serverless. So basically, because I've sort of resisted for the past quite a while using my developer pull secret. But from what I understand you're saying, Sandro, is that with this new system as you get the same operators with no pull secret as I would get using my Red Hat pull secret. I can't guarantee that you will have the same set of operators because it will depend on the developers of the operator itself. So the idea is to open the possibility for this to happen. And I would like to encourage every operator maintainer to push to the OKD catalog as well. Right. And then I guess a related question would be, well, okay, so does the community have any ability to do it if the Red Hat developers ignore it for a particular operator? Being an OKD community catalog, I believe that it's possible that community can push there. But I have no clue that it doesn't. Yeah, these are all the details we need to work out. So let's get the group of people who are interested in this together and put these questions into a document and then approach the respective people with those questions. I think that's the way forward for this. All right, so anything else before we move on from this topic? All right, so let's look at the task list. Create a list of links to add to the PR against product documentation. You add an extra book to provide links to the community documentation. We haven't done that yet. That's to provide to Michael. We should get started on that if someone wants to take the initiative on that one, put your name next to it on that first task there. Send email to Red Group, look at the code of conduct. Diane wants us to get it in by the next main meeting. So I'll send a reminder email like it out one more time, but we've been asked about, you know, where is the code of conduct? You know, because it says actually even says on the website like in progress or something like that or to do. So let's commit to all looking at that and the main group will have a vote and and sign off on it at the main meeting the next main meeting next week. Create template from general presentation. Sandra, did you get everything you need in terms of template presentation template? Yeah, I put together a kind of template shared with a few people for review.  And so we'll change this to look over what Sandra created and we will do that and we'll send the link out to the group via email. So do we know where we want to store that? Are we going to put it in a central place or is it going to be looked at by somebody and then people contact them when they want it? I think we can put it in a, I think we can put it in a central place. I don't see why not. I'll just add it to the docs repo. Just check it into the docs repo. Yeah, it makes sense. Find out who's behind okd linkedin. Who was going to do that? That was Diane, I believe. Yeah, and I don't know that anything has come of that. I didn't get a chance to talk about vanity links yet. I wanted to create the playlist at the same time to see if we can have a vanity link for that playlist and for the okd group and see if not, maybe we create, I don't know, we'll see. Call up for YouTube content. We haven't done that yet. Does anyone want to write up a call out for YouTube content? I'm going to take a stab at a paragraph or two of an email to send out to the community asking for videos of installing okd, using okd. I'm always surprised that some of the videos I come across suggested to me that someone posted one couple weeks ago that was installing okd, I think, on Beatsphere or something. It was just someone random, like not affiliated with the working group randomly. It's like there are people out there making videos, that's cool, but we should see if we can get them at least promoted through our social media and stuff like that. Anyone want to take a stab at writing a paragraph or two to do that? Anyone? Alright, we'll leave that as a standing item then. I've got too much on my plate to take on writing. Review code for next meeting, we've got that. I did talk to Vadim about going over repo materials. And that meeting will also have a conversation about closing down the dev Slack channel. Brian, I'll get with you because Vadim had some suggested times that work well. So let's the three of us get together. Okay, sounds good. And then we got to talk to Diane about SEO. I'll do that when she gets back. Anything else? Yeah, I just think we need to capture a task list that we need to work out what's going on with the survey and also the Twitter credentials. Right. We talked about it on the main meeting, but yeah. Sorry, I have updates on that. So, Diane now has the credentials and we don't have an update on the survey yet. Turns out Drity was out for a couple of weeks on PTO and just got back, I think, like in the past couple of days. So let's check in with that. Asynchronously, I'll reach out to Drity directly and find out what the status is on the survey. And then let's commit to getting it out or signing off on it. If Drity can't do the extra work, let's just do it as it is, because I think it was pretty well close to being done. Because I think at this point we just need to get something out to help define sort of steps forward. Sounds good. Anything else? I've got something sort of, I guess, new and wildish in a way, but it does relate to documentation. Okay, so you might have seen many years ago. There are a couple of books that Red Hat was, you know, flogging for free. One of them was OpenShift for Developers covers OpenShift 3 and the other was DevOps for OpenShift 3 or something like that. And neither of them was ever updated for OpenShift 4. And possibly because the authors are no longer around, like Grant Shipley was one of the authors and he's long gone. But I wonder if it's worth updating those, like they were introductory books, and it might be worth updating to OKD4. But, you know, sort of, I guess, where is the source, you know, who has the intellectual property rights, et cetera, et cetera. I mean, there's a lot of issues, but, you know, I don't think, yeah, go ahead, Bret. Sorry, Bruce. I actually think that's incredibly useful because that's my main use case that I'm trying to achieve. But I think there is a dependency on getting the operators sorted because at the minute we don't have an ability to easily install any of the DevOps tools that are in OCP in OKD at the minute until we get those Red Hat operators available to OKD. But I actually think that's a very, very valuable thing because I think one of the challenges is when we get OKD installed, it's like, well, what next, where do I go from here? And at the minute, until we get things like the pipelines, the tecton, the GitOps, as an integral part of an OKD install, I think we're missing a huge part of the strategic getting started as a developer, learning how to do pipelines with tectons rather than the old build subsystem. Right. And I agree with that. And that would make the DevOps one difficult at the moment. But the developer one, OpenShift for Developers, a guide for impatient beginners, that one would be very easy to update. Basically, like I'm running my students to analogous things, so I wouldn't have a big difficulty updating that. I mean, it was only like an 81 page document with a repo behind it so that you could run the code. But that seems feasible. And it just sort of surprises me that there is this, I guess, big push from Red Hat back in OpenShift 3 and some of the things never carry forward. And it was, I think, somehow they got involved with O'Reilly. O'Reilly published it. I don't know if they made any money since Red Hat was giving away for free, but at least had the O'Reilly logo on it. All right. Well, let's look into that. So who wants to take that as a task? Yeah, I'm happy to get involved with that. The question is where to... Yeah, you can ask Diane. We'll find out. Bruce, I'm going to add you. Diane, I could track down Grant. Let's ask Diane and I'll see if I can send an email to Grant if I can find him again. Sure. He's out there. He's out there. Mr. Shipley's out there. I see his name fly by every once in a while. Right. Okay. Is there anything else that we have here? All right. Well, let's... Wait, wait, wait. One last comment. Okay. It's copyright 2016 Red Hat. Okay. The Red Hat owns the intellectual property. Okay. Well, we'll see. Maybe we can, you know, get them to update it or do something. Yeah. By the way, that book, what is it? The hybrid cloud apps with OpenShift and Kubernetes is pretty good. That came out this summer. I was actually really impressed. This last summer was actually pretty impressed with it. Yeah. Well, it's got three or four authors on it. Three authors on it. All right. Anything else? Sounds like we're good. I'm going to stop recording and end the meeting and I'll see you all at the next main meeting that are going to join us. Thank you to the new folks that joined us. And the main meeting next week would be the best one to find out about involvement in helping out the group in general. And thanks, Sandro, for popping in and updating us on what happened Thursday. And I'll put more info on that and what came out of that meeting into the meeting notes. And I think we're good to go. See you, folks. Thanks, Jamie. Bye. Bye-bye.


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.  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.  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 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 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.  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.  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?  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?  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?  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.