Welcome everyone to the session from Neetu Tripathi. She is here with us to talk about championing security for your agile development. So without further delay, what do you think? Thanks Manju. I'll start sharing my screen. Hi, welcome everyone. Today we'll be talking about championing security for your agile development. A little bit about me. I'm heading security for ThoughtWorks India. And my area of interest is the continuous security, assessments, fit modeling and everything in between. I have spoken myself at a few conferences earlier. And yeah, let's dive into the topic. So today with respect to championing security for agile development, I wanted to touch upon a few things. With respect to that, what does the attack surface look like for agile development teams today? What do we mean when we say security in layers? How do we leverage the agile rituals? In fact, the tools and rituals in agile to make sure that security itself is also agile in our context. How do we build security in and get agile development teams to that level of security maturity? And finally, with respect to security programs that you have in your organizations, how do we design that keeping agile in mind so that we can make it effective? And we'll also be discussing the program outcomes for one of the programs that I designed and I do at scale for our agile development teams in ThoughtWorks. So in the past few years, in fact, in the past many years, we have been seeing a lot of attacks, data breaches, ransomware attacks and whatnot that keep happening from time to time. But in the past couple of years, particularly you will see there are specific categories of attacks that have gained a lot of prominence. And one of those is mostly and which we are talking a lot about today is the supply chain attacks. And out of a lot of other attack categories, I believe that from an agile development standpoint or in fact from a development standpoint in general, it's important to understand why these things are happening and what are the causes for some of these when they're happening in the real world. So for example, and it's just not a specific thing that is leading to supply chain attacks, because it's a very complex sort of an issue which gets exploited and successfully so in many cases in many organizations. Sometimes the reason would be for example, insecure pipeline components which are in use, which could then be exploited. So for example, in case of code curve, it was the credentials in the Docker image, which then led to attackers modifying the bash approach script and going ahead from there. And it did impact hundreds of their customers. And this was one component in the entire development setup as you can imagine. Similarly, in case of Kaseya, it was an insecure product and there was an authentication bypass which was the first sort of the exploit point for the attackers, which then eventually led to other issues and eventually led to the code execution.  And in case of Uber, it was AWS credentials that got checked into GitHub and very soon exposed to the attackers and were abused by them to gain access to close to 57 million customer and driver records. And then there was a lot of direct financial loss also millions of dollars lost there, a lot of impact to Uber as an organization. And this was unmanaged secrets. So while we are talking about a few of these, there could be many, many reasons for these but mostly you will see how closely they are related to a lot of things which are under the control of a development team that way. So the attack surface itself reflects what's happening in our development environment many times. But when you look at it, there is so much changing in an agile development environment that it becomes very difficult to pinpoint on one thing as such. Now there are other challenges when it comes to agile. When you look at it, the whole landscape itself has changed, which has completely become microservices landscape. A lot of development happens that way. It's a lot more distributed now. The attack surface if you look at it from an attack perspective, it's quite distributed, it's scattered. And that increases the possibility of getting something that might be vulnerable or loosely configured, so to say. There are also other things with agile development, there are faster releases happening, a lot is changing, the environment is quite dynamic for all of us. There is new technology coming in, a lot of new tech stacks that keep getting introduced from time to time. Even the adoption of agile is not complete for some of us. Some of us are still in the journey of becoming agile. So that is also, we were not purely there, completely there. Then for many of us, many of our businesses, the need for compliance is also there. It is a regulatory requirement for securing data, for securing assets in various geographies. And then when you think of all of this amalgamated to scale it across different teams in your enterprise itself can be a challenge as well. So, when you look at your development setup today, I just wanted to show a sneak peek of what it looks like and what do we talk about when we will look at it in different layers. When you look at the development setup, typically you will see that you have a developer pushing in code to your VCS. It gets built with your CI and then you turn out the artifact or the container artifact, push it to production and deploy. There are also a lot of other things within the supply chain that you are interacting with or consuming from, for example, there are public reports from where you are taking your libraries or dependencies. There are images being pulled in from different registries. So a lot of things are being ingested to perform the software that you finally have or that application that you have hosted. But apart from these components or code, these are all essentially codes in different formats. So all of this automation that we use for development, we also have a lot of people surrounding this automation setup. So with respect to coming back to the supply chain attacks that we were talking about, while you will see that I have highlighted a few components here just for you to understand that all of these can be different points of compromise as a development component. All of these could be compromised depending on the vulnerability which are there, vulnerabilities which are there in these systems. But there are also the entire set of people surrounding it who could be compromised or could be tricked into doing a lot of or accepting or installing things which they should not. So whenever you talk about security of agile development or it tends to the discussion tends to be about DevSecOps and we tend to focus a lot on having security tooling on the pipeline. Many times that tooling may not be enough. Now the security tooling on the pipeline helps you identify and detect vulnerabilities in the code that you're writing. And essentially in different ways with the CEA with SAS and all of these other tooling which are there in the pipeline. But that may not be sufficient for a lot of these other attack scenarios that you keep hearing about today or which are so successful today. For example, logic issues in your product which can be exploited, session issues, supply chain attacks that we keep hearing about social engineering, phishing, endpoint issues, hardware, software issues are there. There are zero days which cannot be accounted for. So all of these, for all of these we need to look beyond the security tooling which might be there in our pipeline. So how do we look at it? As a development team, in fact even as a security team, the idea is that you look at it in terms of layers. And I've tried to loosely break it down into different layers here. So you would have the people there, network or cloud, excuse me, the environments which are there, the infra components which are there, your supply chain, software and your custom code itself. Generally, the layer on top impacts or is and when it is compromised can impact the rest, one or more of the layers below. That is also one of the reasons why the people there becomes one of the most important and most crucial when you're trying to have security in place for agile development. So with keeping people in mind what it is that we should do, this is particularly for security teams that I wanted to call out. When you start setting up security for your agile development teams, it's important to understand first of all their development goals. What are they trying to develop? What is the business about? What is the time to market you're looking at? What are the OKRs or business objectives that are defined? What are the performance markers that the team is trying to get to? Apart from the business side, also understand what are their technical challenges and constraints? Those would be a lot of things, particularly some crucial ones from a security standpoint will be to look at. For example, how do they manage dependencies? Do they have secure pipelines? What is the kind of tooling that's available currently? What automation is missing for the teams? Where is the PR process? Are there any gating constraints for them already in place? Things like that. And I think one of the most crucial things to understand particularly for security teams is that agile development as a process is very informal. So whatever solution that you come up with or you introduce for the teams should be highly optimized and it should also be very lean. Think of it from the perspective of what they can do on a daily basis. When they take things up, they take up controls or establishing controls in their development environment. The other thing to look at is now this is something that all of us can look at whether your security or your dev teams is to leverage the agile rituals. One of the most prominent and best ways of making security agile in an agile development environment is to leverage whatever it is that you follow in terms of agile rituals. So, for example, if you are looking at sprint or iteration planning meeting, this is a ritual that generally happens at the beginning of your iteration. Think of what it is that you can tie up with this particular event which invariably will get done in the course of the iteration. So for example, this is an example from the SECCHAM program that we were driving. We had taken the teams through the entire process of performing the agile threat modeling, coming up with the right kind of threats from it and so on and so forth. But then we had the question of when do we do it? So it's good that we know how to do it, but when do we do it in the entire iteration? So this was a time when we figured out that in the iteration planning meeting will be the place where we will actually schedule the threat modeling. We'll pick up a bunch of features and schedule the threat modeling for the team to do. Similarly, you have other things like stand-ups. You could use it for prioritizing security tasks or thinking about or talking about the acceptance criteria with respect to security. In sprint reviews, if you're doing manual reviews, for example, manual code reviews, you could also combine them with security code reviews where you could look at logic issues and other things which your tools will not catch. Or vulnerability scanning results and things like that. In retros, you could think about looking at dentist findings if you have any. And also any recurring threats because, for example, entire iteration would have done threat modeling. Now, is there any recurring threats that are happening? This might be a time to look at it. When you're doing your showcase and you are, for example, demonstrating the stories that you have already developed, it might be a good time to look at edge cases from a security standpoint. Or security integration issues with other components at that time. And in fact, we have seen this work wonderfully, especially when you bring that mindset also for the business teams. For example, when you're doing showcases, you would have your business teams also or your clients also alongside. It should not be just the security expert or the sec-camp asking these questions. The group should be collectively thinking of, you know, what if scenarios where something could go wrong from a security standpoint. If you are into black log grooming, also look at prioritizing some of the high critical security bugs which are there which may not have been picked up until then. Or any foundational security tasks which you may not have picked up by that time. Apart from agile rituals, it's also good to leverage some of the agile tools. And I think one of the best tools in terms of agile development is the project dashboard. So it looks roughly like this. This roughly put it together. Like you will have a backlog and then you will have in progress items.  Now I typically you will have all of this form from a functional standpoint. You need to think of whether as a development team are you looking at security as a part of the project dashboard or not. So for example, if you are so it would look something like this where you have the stories that you have already developed would have taken care of your acceptance criteria from a security standpoint. You'll have your security validations all not just coded for but also tested, you know, by the time it moves to run. Similarly, it would also be a place where you have prioritized any critical or high risk security bugs that you have identified any threats that have been identified. And all the stories features would take care of you know security validations if that needs to be a part of it. Now typically in a real scenario you will not have each and every story having this the set of validations required in that context. But there's still be many where this is required and it should be complete only when all of that has been taken care of. So now we'll talk about building security into what are the things that the development team that we can do when we are trying to build security into the product. You know, rather than have a pen test team come towards the end and you know, do some testing and go away and then you know, next time they come in in the next quarter or maybe the next year. This is also what I have realized is one of the fastest ways of doing security in agile is when you start thinking of it much earlier from the very beginning itself because there is no designated separate timeline or period for security to happen. So from that perspective, if you look at your development setup, like we discussed, we always talk about vulnerability detection and one of the items is one of the fundamental, you know, parts for you to look at. So you would have maybe your SAS or tooling that's tooling a CA continuous scanning and so on in place to be able to detect vulnerability in the product itself. But there are some other practices which generally we consider as functional that will help immensely with security. So for example, starting with a secure source is very important, like having secure baseline images from where you can pick from when you're doing development. Or for example, you have a repo for your private repo for your dependencies, which you can pick from. In some cases, although you need to be careful because when you pick from there, it could be that so for example, many times we have seen that we are doing dependency checking and then there are dependencies which are not upgraded yet. So if you have such private reports that you're using, it's important to keep it updated over a period of time. Then you will also ensure that you have, you know, software set inventory or, you know, a bill of materials that gives a very clear visibility of what you have in terms of libraries and dependencies for your product. And I'll give an example of the recent or not so recent block per day issue that happened for many of us. And specifically in this case, you would have realized that mostly organizations which are teams, product teams where they had this kind of a setup, it was much easier for them to figure out what is affected, what is not vulnerable and what needs to be addressed. Having things like secrets manager is also very important in developing that practice of not even checking in secrets, for example, and this tends to be very preventative than detective, which is a more mature state of being. Artifact signing to help with the integrity infrastructure as code if you have it makes it much easier to have a secure configuration, for example, and also make it repeatable in the long run. And also engineering metrics like, for example, your mean time to recover or, you know, time to push particular partial production. These things can be very important, particularly to limit the blast radius once, for example, there is a critical issue that's been found. So the lesser the time you need to push a partial production, the lesser exposure you will have from that vulnerability. So these are none of these are exhaustive. So just a disclaimer there. Security when you look at it as a part of development process, there are again a lot of other things which will help other than just having security tooling is, for example, tying it up to a change management system, where you can, you know, identify, for example, just few examples here like security incidents or your card, which are related to security incidents which have been addressed and integrated to your project dashboards with respect to code. One of the most fundamental things which I would like to call out which a development team should pick up and can easily do is defining acceptance criteria and stories from a security standpoint or addressing all the security requirements for that story or set of stories or features. In terms of hardening, generally we tend to think of just, you know, in terms of network isolation, you know, across our environments and things, but the idea is to look at, do you have clean set of images to start off with when we are provisioning infra or if we are the ones managing and handling infra then are we looking at the right set of benchmarks or CS benchmarks to secure what we are provisioning. Vulnerability management itself is a big area like I mentioned, and this is actually way easier to do with the help of security tooling that's available today. There's a lot of variety for various tech tech that's there, which can be picked up. But as a development team, what adds that extra edges to be able to define clear set of test cops KPIs for yourself, or SLAs for for example addressing or fixing any high critical issues that are identified from the security tooling. And of course, adhering to that over a period of time. And monitoring generally because that tends to happen towards the end of our development life cycle. Often a lot of things are ignored. Some important things, which I commonly see are missing are you know, making sure that you are capturing the right kind of security events or auditing events, which in the case of an incident will prove to be helpful for us. But also looking at targeted alerting. So are the alerts going to the right team at the right time with the right set of parameters identified. Now at the project level, this can mean different things. So generally, you will know in a product you will have business objectives that are defined and which are tied to the results that they're looking for. Many times it would be the business objectives or you know performance objectives, which are clearly called out in the beginning itself, which pertain to you know, the product releases. The idea is here to go one step further, and if possible define so depending on what is the need for how much security is required for your product also and the kind of data you're dealing with and kind of product you have. It might be good idea to also define your objectives with respect to security at the product level. If not, at least have the KPIs defined for security in terms of what you want to meet in your in your own time lines. One good way of map to also structure and look at security that way because there are certain things which are better started at a certain time. For example, we're talking about security automation to be in place or securing your pipelines with adding the right kind of tooling. It's best to do this in the initial few iterations itself. And then later on you can have continuous scanning going on in the entire or the rest of the lifecycle. In terms of awareness that is something that should come much early on. But depending on for example when new technology gets added, it's important to also keep repeating it from time to time for the teams. Threat modeling can come in when your development almost sort of starts and can stay till the end when you keep looking at threats iteratively from time to time. And then also account for more milestone specific security events. For example, you may have pen testing performed prior to release. You may have audits which will happen for your product and all of that need to be accounted for. Not just for the event itself, but also for the preparation because practically these things require some level of preparation as well some level of self review. And then afterwards when there are issues or findings from there also time is required for fixing them, you know, addressing them. So talking about championing security and we looked at you know how do you look at the development process how do you look at the product level how do you look at it more from a micro set of metrics that we were talking about with respect to people. It means making security a part of the mindset so that everybody is doing it in their own respective roles as a day to day activity rather than as a one time activity. That will mean that of course awareness is a part of it. But making sure that you're looking at role specific training rather than generic security training to make it effective. So for example, in the section program that we were driving one of the main goals we had with awareness was to make it as hands on as possible and to enable teams to do it on their own. The second thing is to have the right resources shared with all the development teams. The development teams can also reach out and ask for some of these. Generally security teams would come up with these resources. All of these as handy as possible is the idea so that the dev teams can take it and then run with these. It should also be actionable and timely because time is of essence in a real development. So having frequent touch points with security is a good idea and vice versa with the development teams is also a good idea. Keep it evolving so all the so whether it is awareness and the idea of for example, latest patches coming in for any vulnerabilities issues with new technologies that you're going to adopt and all of that it needs to evolve over a period of time and keep getting updated because a lot is changing on the security side as well. And lastly, it's important to create a community of everyone in this space. So for example, for the SECTRAM program that we were driving, we created the community of SECTRAM where all SECTRAMs could come together, talk to each other about security challenges that they may have when they're actually doing, for example, enabling some automation or performing threat modeling and all of that and be able to discuss that with each other and that helps solve a lot of problems and helps it scale and be sustainable over a long period of time. Because there's only so much that a small security team can do at the end of the day in a large enterprise. So this is a very good and efficient way of actually scaling your security initiatives across the agile development teams. So to put it simply and a little more visually, when you start off with your, you know, the development life cycle, essentially have education as early as possible, you have the right kind of awareness for different roles in the team. It could also depend on the tech stack that you are going to pick up, right? So it could also be language specific. So when you're talking about code security training, it could be based on specific in the code that you are or the language that you're going to pick up. In the design phase focus on identifying threats early on in the life cycle. When you are creating your backlog for the stories, it's important to also add everything from a security standpoint there. And this should include, for example, the threats that you might have identified. Generally, what we do or what we did for the program was once we identified threats, we would convert it to the right kind of story or, for example, security tasks or bug or, you know, a different category because not every issue needs to be a story or a feature. And then add that to the project dashboard. This needs to be prioritized and then addressed by, for example, by allocating a deaf pair who could then fix or address the issue. During development, leverage as much as possible, all the security automation security to tooling that you may have that could be your size to your SCA DAS container scanning, you know, and even in for security review and all of that in a in a most automated fashion. But the idea is that towards the end of all of this, you are as a team come together and, you know, retrospect on or reflect on what are the issues. Analyze, see what are the recurring, for example, threads recurring findings from these scanning tools and all of that, which can be avoided in the next iteration. This could be so this feedback that comes in from this tooling or from the set modeling and other things that you perform can can be added as a part of security unit tests in some cases, not in all cases. In some cases, you could add it as an acceptance criteria in these kind of stories to that right kind of validations, take care of the issues in the from the get go. So, finally, with respect to the security program that you may have in your organization. How do you keep agile in mind when creating that so many times of your different kind of program in different organizations. So it in your context, it might be different. But essentially, it's important to look at different kind of teams. For example, if different teams are using different text tags or have different compliance requirements, that's possible for different products. Then pick up a variety of that see how your program suits or is effective for each of those to have the right kind of things and when you are designing a pilot, particularly in your program. When you're thinking of the awareness aspect, make sure that you are you're thinking of awareness which is more effective to create that critical thinking with respect to your program goals. And it is very practical for the development teams to pick up and run with it. When you are at the execution phase for your program. You look at of course implementing of controls, but how can you do that collaboratively with the developers or deaf teams. So there in security need to work collaboratively when we are specifically talking about security programs being run for deaf teams. And it's also very important to keep it lean so that you can be picked up by the team themselves. When you're doing the governance and you're looking at the metrics, keep the metrics simplified with respect to your program. Metrics should be such that can be measured by the development teams themselves and also by the security teams. But the idea is also to keep it transparent in a way across teams so that drive the sense of competition is healthy in a way that you can see and measure it on your own as a development team. And then of course improve it over a period of time. It's important to keep getting feedbacks because the agile development context itself keeps changing a lot from time to time. So for security teams, particularly, it's very important to keep getting feedbacks from time to time. Lastly, when you are thinking of scaling your security program across the development off. It's important to simplify it as much as possible to make it very handy to have the right processes in place, which can be right processes in the right tooling in place, which can be picked up and the teams can own it on their own, but also make it a part of the culture, make it a part of the practice so that it can scale evenly effectively across all the teams in your development off. When you're looking at the maturity of your own team, for example, your own agile development team, or as a security team if you're looking at the maturity, it's one part of it is to look at the specific metrics that you've been talking about. So it typically it would be number of vulnerabilities which are being detected through the tooling that you're adding, or you know, number of critical high risk issues that are being fixed and how frequently by these teams, a rate of implementation and all of that. But one of the good things to focus on with respect to the program or with respect to your security program will be that if this metric that you are trying to measure is driving a behavioral change or not. So I'll give an example. So when one of the main things that that was at the heart of our the section program was set identification. But we tried to, when we were setting the metric, we did not keep the metric as a number of threats found. Rather, the metric for us was the frequency of threat modeling. So how frequently are the teams actually getting into the activity of doing set modeling. And that is what is what we wanted to do. So the practice of looking at threats or analyzing threats was, you know, the one that will drive the behavior change eventually. There could also be some non measurable parameters, for example, how proactive are the teams with with doing security. So, for example, in our case it was while they are doing they're looking at threat modeling in the design phase. Some of them would proactively go out and ask the businesses or the client around what are the specific security requirements around a set of features or in general for the product. So overall, all of this together will give you a unified picture of the actual security posture of where you stand in terms of security maturity. So, to quickly discuss some of the program outcomes of this exam program that we were driving. This was for close to 200 sections at that time. There are certain things that we focused on in every phase in the kickoff or onboarding we focused on nominating the sections, which was to be, you know, the exams who are actually passionate about security so that it became more sustainable for us with awareness we focused on keeping it hands on and keeping the threat modeling is way more agile. So we reduce the timelines to you know, close to one hour, one hour, one and half hours for project level threat modeling, and for features specific threat modeling to 45 minutes. In execution we mostly focusing on having more concrete actionable tasks for the depth teams to look at or in this case for the sections to look at. In case of governance we made sure that we are collaborating more with developers we are meeting them more often. And what we are measuring points to a behavior change, like I mentioned. And when we were scaling the idea was to build a community where they can interact with each other, share those their own security challenges, help each other solve it and also own their journey as a security champion. So, this led to us through actively uncovering hundreds of threats. Very soon, addressing and addressing most of these high critical issues that were identified as a part of that identification. The secchamps became the security point of contact so they were no more just doing that identification because once, once they matured to a certain degree they started looking at a lot of other things like security automation. What needs to be put on the pipeline and a lot of other things. And eventually, the push model changed to the full model for us where the earlier we were reaching out to teams for enrolling in this exam program, but soon once this got established. We started all the new teams that that were forming were actually started reaching out to us to become or enroll into the program itself, which made the job much easier. So as a small security team, it's much easier if you know people are reaching up to you for all of this than you reaching out to all different team, depending on how many teams you're dealing with. So, yeah, that's the benefit that we saw of driving it in this manner. So lastly, with respect to agile in mind, how do we champion security focus on individuals and interactions over, you know, following set standards, traditionally we have been doing security in a very slow fashion. In an agile setup it's important to focus on the interactions that you have focus on a working security model than having elaborate processes or elaborate documentation for things. It's important to go via the route of collaboration almost always helps and it's almost always effective in an agile development setup. And lastly, it's important to respond to change because the agile development environment is quite dynamic, particularly from a security standpoint. So you should be able to adapt and work with the dev teams to come to the right working security solution for your agile development teams. So yeah, it's pretty much taken from the agile manifesto and I think all of that really works well with agile security as well. So that's all from me today. Thanks a lot. No questions on the Q&A right now. I mean, it was a wonderful session. I mean, like, I think I think security in and out has been covered right from the execution to mindset.


Hey, nice to see you again. I'm MC3's Zachary Bell and today is November 8th, 2011. We're three days away from the carrier classic and I'm here with your daily status update. The flight deck is prepared to hold about 7,500 people and with the event fastly approaching, setup is nearly complete with a backup. I'm going to take you up to the hangar bay to show you how far we've come. Let's go. Hey guys! Normally when we're on their way, this whole entire area front to back and it's hard not to walk 10 feet without bumping your head. Sailors have also been doing their part by prepping, painting and cleaning to keep the carrier classic on schedule. Stay tuned tomorrow to see the players' reactions to their new surroundings.


here anything as far as uh wordage wording as far as uh when the working groups will be fully established no there was just can we full full speed ahead Tracy just get her down you are empowered to yeah your deadline is have a report by may but that's that's a good question okay any other any other conversation on that about future agenda items any comments from the public on that or online okay yeah yeah and that's one of the the updates that we have in our 98 report out for a branch yeah okay so that finishes up agenda item number eight I think we're on the agenda item that we all love uh public comment any comments from the board for members that weren't for anything that wasn't on the agenda okay any comments from the public anything online you see anything in the chat or anything okay anybody in the room all right seeing hearing none item number 10 adjourn do we have a motion to adjourn a favor motions to adjourn okay there's six motions to adjourn so that might be saying something it's we're a half hour all right so we'll say Dr. Goldman as the motion Erin as the second because I think you clicked yours too all right I was going to actually ask you do you think that we should be allotting more time for these meetings we can two hours the long meeting I really was trying to keep it to that but we can certainly block out two and a half hours so we can do that that's easily there's nothing preventing us from doing that yeah I don't have a comment on that it was more can we get the agenda emailed to us yes we can we will have it ready at least 10 days prior and the last been because I'm not that great about we follow my email on time but um that would be super helpful yeah just in terms of process what we'll do is is about a month before the meeting we will send you the agenda see if you have any additional items to add give you about a week to comment back on whether you have additional items to add and then we will add those in and that did happen this time Stephanie we did that but and then we will then follow up when we post on the website let's just make a note from a policy perspective just send it to the members because sometimes the web they're not checking the website and that way you'll you'll actually have the agenda too yeah yeah and I think that's one step we don't do now but we will add in yeah that's great that's great one additional question um as we're going through the work group report outs if there are like supplemental slides or documentation information or something for the board to review are those always distributed with the agenda like I just want no they are not um what we typically do because this is a very fluid environment the agenda set can't be modified um but if you have anything to present just get us to us a couple of days prior and then once we present it we'll ADA compliance it and put it on the website to make it publicly accessible because if it's presented here it has to be public material so that's how we'll do it does that make sense in other words one or two days before get us what you want to present or worst case day of we'll make it happen and then once it's presented we will take on the responsibility of making an ADA compliant and posting it on our website because that's required from our side okay all right okay so we are in the middle of a motion and a second to adjourn any other comments before we adjourn anyone opposed to us adjourning all right so we stand adjourned my time is 12 29 thank you everybody


Welcome back to Kids Fun Science. My name is Ken. Today's experiment is Easter egg science. So three hands-on fun experiments you can do at your house. What you need for this experiment is iodine salt, there's regular household salt, a hard boiled egg, and a raw egg. So experiment one is to figure out if it's a raw or hard boiled egg. Experiment two is you're going to spin the raw egg, stop it, and then it spins again. And experiment three is a stand-up egg. Okay, well here I've got a great hands-on experiment for kids at home, especially right around Easter, right? So I got two eggs. I got one as a raw and one as a hard boiled, but I don't remember which one. Because when I hard boiled them, I kind of intermixed them back in, so now I've got to figure it out. So what I could do is I could shake them, and I can't really tell a difference. I could hold them, and I don't really can tell, but there is a way we're able to tell, right? So if we put one down on the side, and we take another one, and we grab the ends, and we spin it, you can see it's just spinning around right here, right? So this must be the raw egg, right? So it wobbles, and it spins because the egg inside is liquid, right? So when the raw egg is spinning, the liquid inside sloshes around, and the effect of the egg spins back and forth, right? So the egg will just spin and eventually come to a stop. So this is because of Newton's first law of motion. So the law states if an object in motion remains in motion, unless an external force stops it, right? So put it more simply. Newton's first law says if something is moving, and it keeps moving, unless something else stops it. So we have our example of first law of motion here with the raw egg. So this is something else you could try with this. Now we figured out this is probably the raw egg, but let's figure out something else. We're going to spin it, then I'm going to stop it, and we're going to see that the liquid is still moving even though I stopped it. And when I release my finger, it should start spinning again. See that? That's pretty cool right there, right? So I'm spinning it, and the liquid is going around in a circle because we know it's the raw egg. And even though I stopped the egg, right, and when I release it, it starts to spin again one more time. That is cool science right there. So since we know this is the raw one, right, we're going to get to the hard boiled one. So now there's no liquid inside, so nothing's going to move around. So when I spin it, you spin it right, you spin it wrong, it goes off the table. Woo! It goes right there. Anyway, because it is solid, it's able to spin all the way straight up, and therefore I know it's the hard boiled egg. Give it another try. Very cool. Right there, great science, because of all the, it's all solid, right? Alright, for the second experiment, we're going to have a hard boiled or soft boiled, doesn't matter. You're going to use some table salt because it's got a rectangle in squared shape, so it's going to help us. If we're going to try to stand an egg up on its own, even on the big end, it doesn't want to stand up, right? Because it's just, it's round, or it's oval, and it won't stand up. But with the cube shape salt, or the rectangle shape, it'll help build a base so we can stand it up, right? So we sprinkle a little bit of salt here.  It's not very easy, I'll tell you that. Because when you go to release, your hand hits it every time, so you have to be very gentle. But I'm going to show you the salts around it. You can see it's holding it up, standing straight up, which is pretty cool. Gently blow the salt away, and there you go, you got your egg right there, stand up egg. I hope you enjoyed this video, remember to click thumbs up, and to subscribe, and thanks for watching. Oh, and that video too! Um, red subscribe button down below and...


document be treated as an exhibit by the trial court. Then we must go to order 13, order 13 sir. See, once a document is produced in evidence, say for example, a plaintiff gets into box and files a promissory note or a title deed. Then it is admissible, it is also relevant. Proof is different, mere marking is not proof. Then it says the suit promissory note is exhibit A1 or the suit sale deed relating to suit schedule property is exhibit A1. Then an endorsement will be made on the document. That endorsement will be as per order 13 rule 4. Subject to the provisions of the next following sub rule, there shall be endorsed on every document which has been admitted in evidence in the suit in the following particulars namely the number and title of the suit, the name of the person producing the document, the date on which it was produced and a statement of its having been so admitted and the endorsement shall be signed and initialed by the judge. Once that particular rubber stamp is put and the columns in that unfilled columns are filled by the bench clerk and the judge initials the documents, the marking is complete in the eye of law. The marking is complete in the eye of law. There a document so admitted is an entry in a book, account or record and a copy thereof has been submitted for the original under the next following rule. The particulars of a foreshad shall be endorsed on the copy and the endorsement thereon shall be signed and initialed by the judge. Supposing the original is a voluminous document like a revenue record is brought. It relates to 100 survey numbers but only one survey number is in question in the suit. The entire revenue record need not be kept in the court. The relevant page after comparison of the original with the photocopy can be taken and the photocopy can be marked. The judge will make an endorsement that the photocopy is compared with the original, original will be returned to the witness, the photocopy will be marked. Unless there are interpolations in the original record, the original record will not be retained in the court, it will be returned because it is daily needed by the revenue authorities for day to day maintenance. Similarly, a banker's book, account book, it will contain entries of several customers. One page is relevant for this suit that will be taken and will be marked. The photocopy will be marked and the original will be returned saying that the copy market is compared with the original. Similarly, a witness's identity is in doubt. Then he produces the adharkar. Adharkar is regularly required for him at several places. Similarly, he produces a driving license to prove his identity. Then a copy will be taken, copy will be retained in the court and will be marked as an exhibit. The original will be returned to the witness. That is how in some cases copy will be marked with an endorsement. In all other cases, original will be marked with an endorsement. When the endorsement is made in the court hall and the endorsement is signed by the judge, the market


So I got a question for you guys, ketchup, vinegar based products, you keep it warm, store it in your cover or cause you opened it, you refrigerate it. I think it says it does, refrigerate after opening. What's your thoughts on that?


Let's get started. So thanks, everyone, for coming in today, Friday. Good to see everyone this morning. See, everyone's not quite as full as normal. I don't know if it's because of the assignment or what. We don't have to super spread out, right, everyone? Everybody says that, but nobody does that, actually. Even in faculty meetings, the faculty spread out like crazy. It's really fun. OK. So questions on assignment one? Maybe say something about the small package. Yeah, I will. Let me see if there's any other questions. Any other questions? We can use the redx package like we're using. Yes, you can use the redx by absolutely. The only packages you can't use are anything that does HTTP parsing. That's good. You can use regular expressions to parse it. You can use the URL library to parse the URLs. What if we use a part of the HTTP library that doesn't do the actual HTTP call? You should ask me if it's OK. Yeah, so I can make sure. Yeah. Does it have to handle multiple connections? What should a server do? Handle multiple connections. Yeah, it should handle multiple connections, right? Because the idea is you're creating a server that's a backdoor, right? So if you have a server and when you connect to it, you have to do some long running job in the background. When the administrator scans it, right, you don't want that thing to crash or fail or to not respond to that connection. You want it to respond and say, hey, no, no, 404, like look elsewhere. These aren't the drawings you're looking for. OK, some things that I posted. So I posted on here the list of apps of Ubuntu packages that are installed on the submission system. So this is all of them. If you know any discrepancies, please tell me. I can fix it. It's easier to fix it now rather than an hour before the due date.  So if you need to see if your package that you want is on here, you can easily look on here. There's the link. I also sent a, yeah, so here is the link of all of the trusty packages. So trustees to links distribution that we're using, right, 14.04. So you go in here. You can find your package. You can look. You can craft. So the submission system is up all the way up. It's 90% up. Wow. That's a great perspective. So you can create an account, right, which you should do. All of your ASU IDs if you're registered for the course or haven't registered for the course should be in here. If you have any problems or it's not in there, please let me know or if you're here illegally and not actually involved in the course but you want to get an account here. I'm totally happy to do that. Just send me an email. I'll add your ASU ID on there. You should come up with a hacker alias. A cool hacker alias for later homework assignments. We'll be posting maybe some scores or rankings or how people are doing throughout the week, you know, so we can see who's hacking what systems. And so this is a checkbox you can use to say if you want to obdyscape that on the public, anytime your hacker alias is public, you'll be obdyscated. So you can, you know, be creative to the cool hacker alias and then a password. So I'm going to say this now. So I created this system. It does the bare minimum it needs to do so that we can test your projects, right? So did I do things like implement a password reset mechanism and email you your password thing? No, I did not. I'm fairly certain since it came out of the mailing list, I'm pretty sure that I am hashing and hashing very well all of your passwords. I think would be correct. So that should not be a problem. But that means that I can't, and I think it is faultless. I can't be correct. Yeah, automatically does that. So, you know, so I don't know your passwords. If you email me and say like, I don't know my password, then I have to manually go into the server, create a new password and change it. I'll probably ask the TA to change that at some point. So it's a little easier, but you know. So should you use your Gmail password on here? Why not? You're saying password on multiple sites anyway. Yeah, what if I'm lying to you, right? And I'm logging all of your passwords to bring in your Gmail account, right? It's not HTTPS. It's also not HTTPS. Yeah, because that's a famous setup. I'll try to do it at some point. But this is just your submission thing, right? It doesn't work. It's just to keep you all out from each other so we can tell you all apart, right? Cool. All right, so once you create an account, you'll be able to log in. And I just realized I'm in the wrong browser because I don't know the password here. Also, so I did say, OK, well, OK, then, a second. Let's see if this logging works. Yes. OK, this is my awesome hacker alias. So you can submit assignment one. So the only thing that's working right now is the smoke test because I had to, basically, I created these to do the smoke test for my system to make sure that you can submit things. They would automatically get assessed, all that kind of stuff. So I can, let's see, this is for my 591 class. So this should definitely not compile. I can submit a make file. And then you can submit as many source files as you want. I can do a smoke test. It will tell me that, yes, it was successfully submitted. The smoke test had 100 submissions. I don't know. It doesn't really matter. I can change that at any time. And so then I can check the status. And it's going to say that it's submitted and it's still pending. When it actually gets some output, it will tell me the output. It will tell me it failed to compile the project. And here's the first 750 characters from the output. Characters of output from, that's all right. So this will tell you what's wrong and it'll help you try and debug your program. And if we refresh, I don't know exactly how long this takes because I haven't timed this yet. But at a certain point, this will stop and it will give us output for this submission or everything crashed. But hopefully it does it in a way that we will never know about this because you don't know about it. Ha, there we go. So you get feedback pretty quickly. You also notice there's no fancy like, oh, it's in progress and there's no time remaining, right? So, you know, you have to give it some time. So yeah, it tells me that it couldn't, it tried to, so it tried to make, but it failed. So it tried to do this copy thing and it tried to look for a discovery file. The discovery file is not there. I can probably add that information here. We can see here in this test case when I tried to execute discovery, right? That didn't exist because I submitted a big file for a completely different project to do a completely different thing. So very soon, definitely by the end of this weekend, I'm going to have a way for you to take this smoke test submission and then submit it actually for project two so it can actually be evaluated with the real test cases. So I'll have it soon, but this will install, it's exactly the same process. So it's going to install all the packages you install. It's going to compile it just the way we set on the website. It's going to do everything. So that way, when it passes these two cases, then you know you're at least good to go that your program actually compiles. All right, any questions on this? Pretty basic. It's not super complicated. If you have any problems, email me. There'll be problems. I'll hand that off now. There's all my problems, but we'll be able to solve them together. Okay, important note about this IP address here. Oh, all right. I can't do that. Okay. So this is the IP address of my lab. <IP_ADDRESS>. So do not scan or run anything against this lab, right? So this IP address is the external-facing IP address for our entire lab and all the research that we do. So the IP address is not fair game. IP address at this specific port is fine. It's forwarding to a server in our cloud where all this submission stuff is running. So if you find something on that or you find something in the website, please let me know, right? Be an ethical security researcher. As long as you're making a good-faith effort to not break into your fellow students and get their submissions and submit them as your own or otherwise interfere with their submissions, right? Then I think it's good. So this is a place you can play around with and try to bang on. So I don't know. I tried to code it very securely, but we'll see. Stuff happens. The one thing that's definitely not really fair game all I don't think... So the submission system, so we're taking code from you and actually executing it, right? Right. Which is actually what you want to do oftentimes when you're exploiting something, right? You want to get a foreign system to execute code of your choosing. We are doing that here. So use this responsibly. So I think I set it up pretty well so that you shouldn't be able to mess around with it, but those systems are running everybody's submissions, right? So if you mess one of those up and you've messed up that system for everyone else. So don't... If you do something really cool like you're able to exploit the Linux kernel or something and get root on that machine, that's really cool. You should let me know. But if you're running code on there to figure out the hidden test cases and then send them to you on TCP or an email or something, that's not cool. You're breaking the assignment, not the actual security of the system. Yes, we all know you're running code there. You can do whatever you want, right? But the point is actually implementing the assignments. Is that clear? Kind of fair? Fair rules? If you have any questions, just let me know. We're happy to talk about it. Do we get worked? Okay. So we've looked at that so far. We've looked at how the network works, how networking works. Does this look dark to you guys too? Yeah, this is the same problem that happened before. Let's see if just plugging... So you do see that, that it's dark on the sides. The system would, a lot of that would cause that to happen. All right, we'll try this one more time. Yeah, there. Maybe, maybe I have something to say. Resolution. I think the resolution switching between it definitely doesn't like... Okay, good. Little distraction. All right. So we've talked about how networking works, how packets move on our local network, right? What does it mean? What does a local network mean? Is that just like a vague term? Like, does it mean something? The local network means... In the same subnet? Yeah, we're on the same subnet, right? So when you configure the IP settings of your machine, right, the subnet says, hey, any IP address that's a prefix or within the subnet is on my local area network. So I know I can directly talk to any other machine on my subnet. Okay. So we talked about that, right? We haven't even gone into how packets reverse the interface and how they get out, right? We've only been looking at local area networks. And we've talked about why do we want to... We've talked about sniffing the network, right? We want to sniff the network. We want to be able to get information that we shouldn't be able to get. And so this is what we're going to look at now. So network sniffing is the start of a lot of local area network attacks. The basic idea is that... So by default, what's actually getting the packets on your machine? Your packets, your IP packets come into your machine. I have one of the layers it goes through. The network card. The network card, yeah. So the network card first, it maybe does some processing then throws it up to the kernel or the hypervisor depending exactly how I've done. Probably up to the kernel. And then the kernel sends it to you, the application if you're listening on that, right? So by default, what is the... You're making an efficient network card, right? What are you going to do if you get a packet that's not destined for your physical MAC address? Drop it. Drop it, yeah, right? You know you're not going to do anything with it, right? So you just drop it on the floor. You ignore it, right? Which makes sense because it's efficient. And the physical card knows its MAC address, right? But they, you know, either debugging or any kinds of other things, right? You actually don't want that. You want to see all the packets that are on the network. And so there's a way to set your network interface into what's called promiscuous mode where it actually will pass up all the packets that are not destined for that specific MAC address. And then it's up to the other layer to decide what to do with it. So the operating system has to decide if it deals with that packet or not and for your application. So is this it? We just say, bang. We set this little bit, this mode on our network card and now we're going to go. We can snip everything. You have to back it to an encrypted, I guess. Encryption is not encrypted. We don't really care about that. We still have to read it to know if it's encrypted, right? We still need to be able to read it at some point. So can we snip everything we want now? What are we talking about on networks? What do we know about how a local area network is working? Packet is sent to every other computer on the network. All of it has to first establish a connection to every other machine. Right. So we have ARP. So remember on ARP, right? So when we want to know some of these physical address, we broadcast a message to everyone in our local network. So are we going to get those packets when we send ourselves to Permissio's mode? Yes. Yeah. By default, it's broadcasting to everything in the subnet. So those messages are coming physically to our car. Right? So we can listen to that. Can we just listen to any other arbitrary packets? That are being routed via me. What's that? That are being routed via me, I could listen to all of those. That are being routed via you. Yeah. So what were the two architectures for a local area network, like the physical devices? Switch and hub. Right? So here, so does that affect what you can snip? Yes. Why? What's that? In hub, they broadcast to everybody. Yeah, exactly. If you're on a hub, you're done. Right?  So all those packets that you're getting in, as long as you're in Permissio's mode, you can read them. You can see exactly what's going on in the network. But if you're on a switched port, or you're on a switched network, it becomes more tricky. Because by default, packets destined for another MAC address don't go to your port. The switch keeps track of what MAC addresses are coming from which ports, and so that way it only sends out on that port. So we're going to look at that. So we talked about a little bit about kind of high level why sniffing. Some of the other reasons why you want to do sniffing because aside from it's just really cool, you can steal financial information. A lot of protocols that are still in use nowadays transfer authentication information in the clear. So if you ever connected to an FTP site where you had to do username password, that username password is sent on 100% in the clear. Same with POP, same with HTTP with basic authentication, actually with all the types of authentication. It's still sent over in the clear. IMAC, what's POP and IMAC? Yeah, reading email, right? SMTP is the simple mail transfer protocol for sending me an email. I don't know what they stand for. Any of you know what's up their heads? POP and IMAC. Post office protocol. Post office protocol and let's see what. Internet message. That actually makes sense. Post office protocol and internet message access protocol. Not very inventive things. So, because these protocols just send in the clear, this isn't a class about encryption, you can learn about how to break encryption and all that stuff, but here we're not even talking about encryption, they're not even being encrypted, they're just sending it out. So we can actually collect username passwords, files that are being transferred, mailed, and oftentimes we'll save that data to a file and try to analyze it later to look for these things. And this is stuff that happens all the time. When you think, well, we have SFTP, right? You can do that securely. We have HTTPS, you can do POP or IMAC over SSL, so all that's encrypted. But we've actually seen this when I was doing a pen test at a company in Santa Barbara. They gave us a tap on all their network traffic and we were listening to it and we saw that somebody was using an FTP server and was sending username and password in the clear so that when we connected to it, we were able to see that they were, it was there, I think it was one of their marketing people, like a little marketing site that was up there and so once we got in, we could poke around in there and we could have uploaded files and changed all that stuff. So, you know, this stuff happens all the time. You'd be very surprised by this kind of stuff that happens. Okay, so we want to, so I was going to say we could do it, we could sniff on the network ourselves, which you can do, but there's a lot of layers in between you and the packets. So there's a lot of tools that actually help make sniffing a lot easier and they're good for hacking, penetration testing, trying to understand and really also for trying to understand what's going on in the network. So really, if you ever encounter tricky troubleshooting network problems of why isn't this packet, this request getting to this server where it should be getting, these are the kind of tools you look for. Really good command line tool, the most famous, best one in my opinion is TCP dump, which collects traffic, so you can set filters on it as we'll see to change which types of traffic. TCP flow will take in a TCP dump file, analyze the TCP connections, the flows, right? So TCP connection, we're going to get to it, but it's IP, source IP, source port, destination IP, destination port, and that constitutes a flow and so it's able to take from the TCP dump and rip out all the flows into separate files so that you can see all the communication that's happening today. TCP replay is a super fun tool to play with because it will replay TCP dump traffic to another host. So you can try to record something, maybe try to play against your own system or back at them or something like that. Graphical tools, Wireshark is kind of the standard graphical version of TCP dump. It will look at the network, see what's going on, and try to reassemble from the raw IP packets into TCP flows and it has all support for all kinds of other protocols to then say, oh, this looks like an HTTP, that means this whole conversation is HTTP and so I can parse it and I know exactly that this is the sequence, you know, the mode and the request and the URL that's being requested and this is the response with the response code, all of that stuff. So TCP dump is really kind of the core. It's a simple tool but used all the time. And it's based on the important thing, kind of one of the important things here, is that it's actually based on a library so it uses this library lidpcap to actually do the network capture. And the idea is you can code your application against lidpcap and then you can run it on Windows or on Linux or on the Mac or whatever, any operating system and lidpcap is platform-independent, it will be implemented to do the packet sniffing. Also really cool is that you can specify an expression that defines which packets have to be printed or which packets to print or capture or how to print, how to capture. Very useful stuff for windowing out everything that's going to be in there. So we talked very briefly about that you need to set promiscuous mode on your network interface. So can all of your programs do that? If any program is running on your machine can it set promiscuous mode on your network art? Does it require pseudo? Yes. Does it require pseudo? Why would it require pseudo? Because it's part of the hardware. Because it's part of the hardware? You talk about hardware a lot though through the operating system that doesn't require pseudo, right? Or root, the L way of religion. Why would you need it? Do you need it? It might be by individual board you want to listen to so it might you stop that and find it. Exactly, yes. So this is actually a little forward preview but you have two applications running as two different users on your device or on your server. By default they can't access each other's memory they can't read each other's files unless it's explicitly allowed. They have privilege separation and it's a network application. It's probably reading on a certain port waiting for input files. So now if another file without any privileges can just listen for every packet that comes into the network and I've got all this other application's data and everything that comes in there, right? So you're essentially being able to elevate your privileges up from a normal application, a normal user to higher privileges. So that's why TCP dump requires root privileges to be able to set the interface to permissivism. One way to do this is you can have TCP dump output a file and then you can use TCP dump later as a non-root user to not have to do this. Cool, so let's look at an example. It's still held up. I don't know. Okay, this is the homework submission server but I should update that. It's not a good thing to show everyone. So I can run... So first I have to tell TCP dump what interface I want to listen to. So on Linux, I have configured, shows you all the interfaces that are configured and the default that shows you the interfaces that are up, right? These are the physical links. So this says Ethernet 0 it has this hardware address. So what's this hardware address? Mac address, exactly. And we have the internet address here. What's the mask name? We don't really talk about it. How's that mask work like this? Now, starting to build networks and ending to it with the hosts. It's relative to the subnet link. How much leads are reserved for the subnet? Yeah, exactly. So the mask specifies so the ones, right? 255, 255 is all ones. Those specify the subnet range and the zeros are the individual hosts in the subnet. So this means I'm on the subnet 172.21 right? Anything below that is on the same subnet. So I know I can probably pass packets there. So now if I do so if I just do if I do tzp dump actually kind of worried I'm doing this in front of everyone that's going to break, we'll see. Okay, I use the dash I option to specify exactly which interface I want to be listening on. I'll do Ethernet 0 what's the low? Hello? Let's still do back pose. Is it a physical? It's like a physical. To send to your site. It's like a kind of a I don't know, pseudo-design device. It's exactly the right term, but basically if you want to send a packet to yourself you can send it out to that device and it will just stay on your local machine within the operating system. It doesn't go out to the network if you try to do the hard thing to figure out how to get back to itself. I don't know what to do on this. What does it tell me? I don't have permissions. I tried to ask the operating system hey, set the permissions bit on Ethernet 0. It says no, because I don't have the permissions to do that. So I have to run it as pseudo. What does running as pseudo do? As root. Yes, it executes it as root. So we'll get into exactly what that means. If you're only used to Windows systems, root is basically the administrator to the machine. So we can run tcp.withsudo. Alright, and it's going to give me some output. Okay, good. I was waiting for it to give me a lot of output. Okay. So then it's giving me a whole bunch of information about this network, right? It's telling me that it's yeah, that there's and this is, let's see, okay, so part of the problem is so you see these IP addresses? Or this is the hostname, right? So actually we'll try to resolve IP addresses and turn them into hostnames for you to be nice. Honestly, they get in the way a lot of times. So I usually use this dash n to say don't do that. And minus v. Okay. Perfect. So now you can see here, so these are time stamps and these are the type of packet. So we can say at this time there's an IP packet from, why is there four? Why is there five octets here? What is that? For port. Yeah, the last one is the port. Exactly. So it's saying that IP 172.21.076 at port 22 set data to. So that's the directional. 1090.64.9 on this port. And these are the TCP flags that were set, the TCP sequence number, the act number, the window, any options that were set. That there's probably an act, yeah, there's an act back on this connection to know that we actually got the data and then received it. We're getting some, anybody know what an MBT, MBT, I think it is. It's not a rhetorical thing. Or I mean, I don't know. I don't know. We see other UDP packets, like this is running an open stack network. I don't know what other stuff's happening here. We can see here, very interesting, right? So it's saying that, right, so we saw this in the slide. So here we have a request for, hey, 172.21.068, who has that? And if you can find out, tell me at <IP_ADDRESS>.  So what's this, what's port 22? FTP? SSH? SSH, yeah, SSH. I think FTP is what, 20 and 21 or something? 21, 21, 21. There's two ports. SFTP is different. Yeah, FTP is a data in the control port. So there's like two. I don't remember exactly what they are. So 22 is SSH. So what is this traffic that I'm listening to? Who's SSH? Did I just stumble on the somebody's awesome SSH connection? One of my students, I can start messing with their experiment. Yeah, it's me. I'm SSH to this machine. This is my SSH traffic. Clearly don't want that. It's kind of boring. And actually, it'll just go forever, right? Because every time TCP dump outputs something, it sends data to me, to my machine over SSH, which means it's going to create a new answer in TCP. It's going to keep going forever and ever and ever. So then you can add options to the TCP dump to say, let's say we don't want port 22. So now this is going to be every non-EGDP packet. So R, we've got to reply. Okay. Yeah, so we say we have R. Where does that reply? It's there. Somebody said there. Down? There we go. Yeah, so we can see an R for fly, which probably I think was us. We're 172.21.076. But, right, we can see all this data. All this is happening constantly on the port. That's why you can look at the servers, right? They're constantly flashing. And it's all this stuff. It's all these packets. Our packets, every kind of packet is happening on the network. Yeah, we can even do, we can, if we want more information, I don't know what just doing Dash B does. Oh, that debugs the protocol more. So yeah, we can break down the protocol more. We can, let's say if we do, I think X will show us the actual Ethernet, the first couple bytes of the Ethernet. Sorry, of the packet itself. So we can actually look at the bytes and then look at them in text value. Oh, this is weird. We can learn a lot of stuff here. Oh. Okay, whatever. That's an IPv6 packet. So you can see lots of stuff in here. Lots of stuff happening on the network. That's why they're super complicated. So it has all kinds of things, all kinds of options. The ones I use are usually at Dash N to not translate the names from IP addresses to domain names. It also actually delays the TCP dump output while it's trying to resolve all these IP addresses so it's generating more traffic. You can print it in hex. You can use a specific network interface. You can repack it from a file. You can write to a file. The depth S option is really important. It used to be that by default it would not capture all the packets. Why wouldn't you want to capture all the packets? It's too much traffic. It could be too much data. You're trying to sniff on the network and it's just generating so much data. But the problem is if you're trying to, I've heard stories of people trying to do experiments and trying to do data capture. They forget the dash S option and they end up only capturing the headers of all the data, which is only about 60 bytes or something. You've lost all this really important data that you can't get. It is to capture all, so the default switch. It will capture all traffic unless you specifically tell it not to. Then you can specify a file for that filter expression that we were writing in the not port 22. This is the key. The frame body for the IP packet was 1500 bytes. Why would you want to set it to 65,000? Oh, the Ethernet. You may not be on Ethernet. I see. Because an IP could be that big. Okay, so those filter expressions are really important. You can define some kind of qualifier like a host. You can say where the host is a certain fully qualified domain name. PCP number was all that for an IP address. You can sniff certain subnets. So you can say you only want a certain subnet. Certain ports. The direction you can specify I only want to sniff packets that originate from host error. Or you can say destination. I only want packets that are going to a certain host. You can say both. I'm not going to skip over this. It goes faster. But you can specify the protocol. So if it's an Ethernet, I only want to capture Ethernet packets. I don't want anything else that's different. IP, ARP traffic, operators. So you can use and or not to develop as complicated of an expression as you want. What you can do here is that it's going to filter it from your file. Which can be handy if you're capturing on a system on a command line. And then you want to take that file transfer to your local machine to use Wiresharp to then look at that traffic. There's other kind of special characters. You can see it's a broadcast packet. It goes crazy as much as you want to do. The other thing, really cool thing is you have access to a raw packet data. So you can say give me all packets where a certain byte or bit is set. Like you can say IP datagrams with options. So you can say that IP0 and it with OXF is now 5. Then you can see all the IP datagrams that have options set. And so there's all kind of stuff you can do putting it all together. This is TCP dumping on an interface not resolving the domain names to domain names and all that packet info. This, the dash W is writing out to a file. R is just reading for the file. So what's the difference between the dollar sign and the hash or the pound? Ash is soon at first running as a root. So that's why there's no pseudo in front of there. So in the examples I'll try to keep that up. That's kind of the convention. When you're on a terminal or a shell that is running as the root user you be careful and think about what you're doing. Right? So this is the way to do that. Yeah, we can set an arc packets where the seven byte is a certain value or bit is a byte is a certain value. So it's actually built on, the really cool thing is it's built on this library lid pcap. So you're actually not just limited to using these premade tools, right? You're all programmers? Not your head? Yes.  It has a whole bunch of options I'm not going to get into. You get actually the raw packet and then you can do whatever you want to it. You can read all the bytes. You can alter it, change it. You can cast it to an IP packet to then understand what it looks like as an IP packet, all that kind of stuff. So this allows us to SNIP but we said all those packets that we were just SNIPing were basically for my machine or packets destined for anybody else really for that we saw. It didn't allow us to eavesdrop on somebody else's conversation. It was only broadcast because presumably that system is running on a switched network and not a hub based network. Because hub is just broadcasting everything out. So what can we do? You're going to switch network. You want to be able to SNIP all the traffic. You want to be able to get all the traffic. So what can we do? Come on with the tax, your hackers. Yeah, in the back.  So you're going to personally make them get some of the traffic. Look at all the hard requests and come up with all the hardware that's all the MAC addresses for all the other machines and then use that to kind of replace it to the switch. Yeah, you could do something like that. What do we know about a switch? Think about it. It's a layer 2 device. We can change the R table entries. It's a what? Layer 2 device. So we can change the R table entries. It's a device, right? The important thing is it's a device. How much memory does it have? A limited amount, right? Compared to your machine, right? I actually don't know. It's interesting to look at how much memory they have. It's probably safe to say it doesn't have 4 gigs of memory right? So what if we just flooded the switch with a bunch of MAC addresses, right? We made it, right? It's keeping track, just like you guys said, right? It's keeping track of all the R tables on the switch itself, right? It's mapping chords to our MAC addresses. What happens when that gets really big? It overflows. It overflows. You could overflow?  You could put yourself in Cisco, or Juniper, whatever you choose, right? You make a switch. What do you do when the switch fails? Reboot? What if it happens again? What's not a good thing you could do? There's like 5 days, right? We're thinking about the switch from a switches perspective. The switch itself, like an engineering type thing, right? Or even a business thing.  Why not? So what's about your product? If you just got a lot of traffic and you ended up crashing, right? Like, it's a crappy product. Yeah. That's more like a quality of service kind of thing of how to ensure fair bandwidth allocation of the switch, right? But they draw a package if they're not being used. Even if you are going to down this one, right? Yeah, but I can make packages really fast. Like, I send out thousands of just independent MAC addresses on the network. The active record, this is actually the memory system that's going to remove whatever's there on it and then put it as what you have. Maybe. Maybe it doesn't. It depends on how they go to it. But in general, right? So, yeah. Yeah, right? You want it to just still work, right? Forget all the switching stuff. It can work just as a simple hub, right? And it'll keep working. Yeah, exactly, right? So, hey. Then somebody, it crashes, whatever, something, don't care. It's still going to work. So, if we do that to our advantage, if we know the switch is built like this, we can flood the network with MAC with MAC addresses, send out a bunch of packets. It's maintaining this mapping, right? And in some, you know, I'm not claiming this happens in every case, right? With every system. But, you know, so you're saying that it'll not maintain the R table and directly forward to the... Yeah, it'll just crash, right? I mean, you can't, whatever, any error happens in operating system but an error happens, well, you don't want to stop shuttling packets around, right? But let's just switch into a hub mode. So, this would be one way, right? So, you just basically force the switch to turn into a hub. So, you're basically using the fail state of the device. And because it can fail to a hub, and yeah, you have a performance degradation but it's still working, right? So, from a, you know, safety that's, but from a security perspective, right? Now we're able to transition that device into an insecure or less secure state so that we can now sniff all traffic. Yeah, in effect. What if the second switch comes in to this... What happens to this? Well, you have other issues to deal with. Yeah, then it wouldn't be a problem. Or it'd be like, what if it just drops the last map entry? Like, what if it's loaded correctly and it doesn't do this? Then you have to try other things. That's what we'll look at. So, the other thing we look at, right? We talked to somebody who said earlier that, well, we just duplicate. We can actually listen to all of our broadcasts and we can make our own list of IP addresses and MAC addresses. And then we can send out on the court that, hey, we're at this MAC address, right? We can send out packets so that way it associates the victim's MAC address with our MAC address. And so, ideally, the switch will record this in the table and send that traffic to our machine or both machines, which would be really good, because then that machine doesn't know we're actually doing anything, right? They don't know if they're missing packets. Well, then it's coming to us and we're good too. But part of the problem there is then we come to this typing game, right? Well, but as soon as then that other machine sends out a packet, then it's just going to put that entry in its table and associate that court with that MAC address and then when the reply comes back it's probably going to go there. So we either have to do this a lot and continuously, right, to make sure our entry is in there. But then we've kind of taken that other machine off the network, right? Because that machine can't really talk to anybody because it never gets a reply back, right? It tries to make a request. All replies go to us instead of them. We sniff a packet and then stop wait for it to reply and then go again but then we're kind of missing, we're still missing the packets also that it's sending, right? We're not getting any packets that it's sending out. So this definitely is an option. It has some problems. So what do we know about the ARP and some broadcasts, right? So Sygnac Tower works. So we broadcast and say, who has 172, whatever, whatever IP address? I am this IP address and this MAC address. Yeah, they send back, hey, they send back a response that says I'm this MAC address and I'm this IP address. So we think back to the protocol. What linked those two requests and responses? The first question. The IP address, right? So yeah, so when I say, hey, who has IP address, we'll say 10, I'm IP address 9, right, and this is my MAC address. And then when they respond back they say, hey, I'm IP address 10 at this MAC address, IP address 9. Here you go. So the two pieces of information that link it, right, are basically the sender's MAC address and the sender's IP address. Because that's how it knows to send the ARP reply back to that person. Isn't there, like, an ARP request like doing the wood process? Our reverse, our ARP is reverse ARP. Reverse, our ARP is reverse ARP where you ask, I think I'm pretty sure it's the opposite where you ask who has this MAC address to tell me and then they tell you their IP address. It's not used as much. That's why they're covering it too much. So what guarantees in the system or the protocol that we can't send an ARP request a response before we receive a request? We need the IP to send the response. Yeah, we need to know the IP address, right? But when we're a machine, right, we send out a request, we get a response. There's nothing linking those two things. So if we just receive a response that says hey, I'm IP address 9 on MAC address B. So we say, okay, boom, we update our table. So can we broadcast our reply? We can't, I don't think we can broadcast a reply that maybe ignored. I'm not 100% sure. What we can do is we can try pinging or figuring out who's on our local network so we get that entire table and then we can send each of them a request to say that so essentially we're spoofing or poisoning their ARP caches and saying that hey, that IP address we want to talk to is actually me, my MAC address. So this is a super cool attack. So the goal is we want to actually, this is going to allow us to send all traffic in between two hosts on the network with this ARP spoofing. Basically we tell victim A hey, if you want to talk to victim B it's my MAC address and then if you tell victim B hey, if you want to talk to A you have to use my MAC address and so this way all the traffic goes through us and we're able to impersonate and man in the middle all of that traffic. So we'll get exactly how this works on Monday.