Hello everybody, it's Keatron Evans and I'm here with you getting ready to talk about incident response. This is another one of our skills, INFOSEC skills sessions here. And really, we're just going to dive right into it. Talk about specifically what it is you need to know to do proper incident response and kind of get into what the nuts and bolts of it is. We'll touch on some high level stuff just to kind of get us intro, but we'll then immediately jump right into the technical do's and don'ts. The techniques you need to master, the skills you need to have and account the tools you can look to have in your Arsenal. Now let's talk about what incident response is, what digital forensics is and how they're related, and this is our introduction to that. So if you look at this definition, this is the nest definition of incident response. And it's a pretty all purpose good serving definition, the mitigation of violations of security policies and recommended practices. Now these incidents could stem from internal incidents, it could be a cyber attack, a policy violation and a lot of other things that could be very much organizationally dependent. So if you look at this shortlist here, these are just examples of where an incident might stem from. But if you look at the different types of organizations out there, a lot of other things could be referred to as an incident. Therefore needing an incident response process applied to it on incident response effort to respond to whatever that incident maybe. Now why do we need it? It's likely that in organizations survival after they've had a data breach, any type of data loss or anything that might erode public or customer trust in how well they're handling and securing data. That's likely going to need some type of response to it, okay? Some of the things that you want to know is when, how, to what extent, how do you recover? These are some basic questions that any incident response program and policy should try to address. If you're not addressing these things, you're not really serving some of the core purpose of having an incident response policy. Now the incident response plan needs to be repeatable and documented, and I can't stress this enough. It's great if you've got that one in a million heroic person that you can throw into any incident and can make it look gravy no matter what the situation maybe. But whatever it is it needs to be repeatable and documented, okay? Because if not what you have is, when you have these heroics to where you have one person going in, doing everything and it's not a repeatable organizational process. In other words it depends on an individual that makes it into a situation where you have something that you can't repeat or you can't document. And that can get you in just as much trouble as not having our response effort at all, okay? Also if it's not documented it's possible that the response effort that the long wrongful that that person did that's doing heroics. They could be doing what they consider to be the right thing, but it may be something that's completely in conflict with what your organizational security policy say. And that's another reason why we want to make sure that when you have an incident response plan that that thing is built from your overall information security policies. So you use your information security policies is kind of like oversight into how you're going to start drafting your incident response plan. Now of course, we're going to use this framework and other things like that to help us have some structure to it that's somewhat industry accepted. But here's the most important thing, your incident response plan absolutely has to align with business objectives and overall business appetite for security and incidents and things like that, okay? Now sometimes it is required for compliance to have an incident response plan. And you also have to remember too that a lot of your insurance policies out there specifically dictate that if you have cyber insurance, if you don't have an incident response plan we may not cover you in the event that you have an actual data breach. So you need to think about that. And now we're starting to see that this is trickling over into just general loss insurance policies and things like that, that's don't even have the word cyber in it. If you lose data, if you're sued by customer, we have some language in the policy that where we may not cover you as much As much as you think, if you were shown to be negligent, or not following basic due diligence in due care when it comes to things like having a written and documented incident response plan, and having shown proof that you have a staff that's able to execute that plan. All of these things are the way it is now, so you can't get by with just having some cheap plan that you threw together real quick just to put on the books to say that you have a plan. It's got to be repeatable, it's got to be documented. And you need to be able to show proper alignment to the organizational business objectives and the organizational just appetite, in general sense of how they look at security. All right, that is the most important things. It also provides you a way to measure success and failures. I you don't have a plan, if you don't have some goals and objectives that you're trying to meet when you're doing eradication, when you're doing containment, and all these things, how do you know if you even successfully eradicated or contain that incident? How do you even know that you should be moving to eradication from containment if you don't have clear measurements of what a successful containment is, right? So a lot of times we've seen organizations be very loose with these definitions, and there's always conflict on are we contained or not? Should we move on to eradication or are we still in containment phase here? And a lot of that indicates that they didn't do a good job of making sure that they had these things laid out so that it can be measured, right? And when we say, measure successes and failures, we're talking about at each phase, and we'll talk about these phases here in a little bit. Now, let's just look at some numbers here, some data breaches by the numbers. So Boeing had an incident, and this is public knowledge, this is actually on the Boeing website. Boeing had an insider threat that named Greg Chung, who was inside for 30 years and stole two billion dollars worth of secret aerospace documents and gave them to the Chinese government. That's two billion dollars, all right, this was a 30 year attack that kind of happened here. That's two billion dollars, think about how much money that is. One individual, one threat, one incident that spanned for 30 [LAUGH] years, two billion dollars, right. Now, got some other interesting numbers, here. The average cost per data breach right now is about 3.86 million dollars, that's the average cost per data breach across all the companies that report their data breaches, all right? Now, we know that we have other data breaches that are much bigger that may not even be reported. So these numbers may be skewed from the fact that some of the bigger, more devastating data breaches never get reported, when you start adding government and things like that into it, all right. Another interesting number, the cost per lost or stolen record, the average cost is about $148 per record. Okay, the average saved with having a proper incident response team, or at least a structured incident response team, is about $18 per data breach. So think about that, if a company lost a million records, which a million records is really not that much these days, right? If a company loses a million records, the average amount saved by having a well formed, documented incident response process with a competent incident response team is about 18 million dollars per breach. We say the average loss is a million records per breach, so that is not insignificant. That's a big amount and the source for this is Verizon, so. And they're one of the leaders in what we all turn to in this industry as far as looking at data breach statistics. I think that probably the Verizon Annual Data Breach Report is the most cited and most used document in this industry, as far as getting hard numbers when it comes to corporate data breaches, okay. So, these are some very, very, very staggering numbers here, and if nothing else, just this one page is enough to justify to us why we actually have to have incident response. Now, if that's not enough, we got some more numbers here for you. Cloud services more than 70 million stolen are lost records, were a result of misconfigured Amazon S3 buckets. And what the staggering thing is, is hardly, if any, of these were the fault of Amazon, it was misconfigured services. We rapidly migrated to cloud services, we didn't properly think through. Through security, forensics, incident response, what we have access to, what we don't. How fast can we get access to things? This is what's happened, right? Also, 197 days is the average time to identify breach. Were talking about that I'm from when the breach happens to win, we identify it as a company or as an organization. Average time is 197 days, think about that. That is a lifetime. That is literally a lifetime, for a threat actor to be in your environment. And what IBM is saying here, is that the average company takes almost 200 days. Before you're even aware that you've been breached. Now, after you find out you've been breached, the average time to contain that breach is 69 days. 69 days, that's over too much to contain it, okay? Health medical, there was an 80% increase in the number of people affected by data breaches in health and medical. From 2017 to 2019. Look at that number again, 80% increase. So, these numbers are just staggering. And now more than ever, we definitely need competent people, that can actually do incident response. Now, when we look at this operational definition, we're kind of going a little bit deeper into the weeds here. And looking at the definition more from an operator, or a functional incident response persons perspective, okay? Now, incident response is a methodical approach to handling the aftermath of an incident. Such as an attack or a security breach. And the key thing I want to point out there is it says, such as an attack or security breach. But keep in mind, there could be lots of other things aside from an attack or a data breach. That leads us to do incident response. It could be a lot of things, internal things happening that may not be a security breach or an attack. It could just be improper usage of equipment inside the organization. If it's a government organization that improper usage and stuff like that could be a huge deal. So, we kind of of want you to understand that when we say Internet response. You could be responding to more than just, a data breach or an attack from the outside, all right? And that some of the high level stuff that we want you to kind of get your head wrapped around. To set the tone for you to understand that there's a reason. That this is going to be one of the more popular skills tracks that we have on this program. Is because of the fact that there is a huge huge monumental need for more competent people. And we're definitely going to put a lot of effort and a lot of quality into making sure. That when you're done with this skills path, that you will have some of those tangibles. Thank you for joining. This is And I hope to see you again in the next skills path video that I'm doing.
