Now we're gonna move on to talking about incident management
and let's get a couple of terms to find out of the way first, because a lot of times these terms were used interchangeably. We have events alerts in incidents,
so an event is an observable change in state. It's neither positive nor negative. So when a system starts or service starts, that's an event. A. It's a change in ST
now, when we have multiple events that have an adverse effect on the system or network, that becomes an incident
and many times alert, sir configured to let us know if certain incidents have taken place. So that's how the three work together. An event really is neutral, but multiple negative events. Macon Incident and alerts are used to help us trigger a warning. In case these incidents happened, so
and alert might be set up to send me an email message.
Should we run out of space on our hard drive or whatever, that might
many, many different incidents usually and certainly on this place. When we talk about cyber incidents or incident response, I always want you to think about an attack. I always want you to think about malicious, malicious intrusion. Whether it's not love surfaces. Packer distributed denial of service attack
and you'll hear those pronounced dos attacks or de dos attacks.
The main purpose of these types of attacks is to affect the availability of a system that's really all the Attackers looking to do is they're looking. And sometimes it's just for bragging rights, you know? Hey, I took the Google server down for two minutes or,
you know, if you're familiar with the Group Anonymous that's been in the news a lot lately
on they bring the form of, um,
of vigilante ism that we call hacktivism. So they're expressing their political frustration right now by hacking into servers of people that they, they believe are worthy of attack. So, you know, Anonymous started to come on the scene back with Wiki leaks
and the founder of Wikileaks, They felt like he was being unfairly persecuted and prosecuted.
And so they did a distributed denial of service attack,
uh, where they took several of the major credit card companies off line for a period of time one morning.
So, again, the whole purpose there wasn't really to steal data or divulge private information. It was just to cause that organization to suffer loss based on its time off line.
You know, for my company to be off line two minutes Wouldn't be such a big deal. But you taken Amazon or Visa MasterCard and you knock them off line for 2345 minutes now, suddenly have a tremendous loss of income.
All right, Another term malicious code. A code that sort of an all size fits one size fits all term. So whether we're talking about viruses or worms, Trojan horses, logic bombs, those all fall under the category of malicious code. So it's any type of code
that, uh, looks at exploiting vulnerabilities on the system.
Other types of incidents. Unauthorized access to resource is so a subject that shouldn't be at authorized
access. Something gets authorized. You know, it could be something as basic as, um, social engineering. I've gotten you to divulge your password to me.
Maybe I have guessed your password.
created some mechanism. We talked about a race condition where authentication happens, actually after authorization. Whatever the means is, somehow a subject has gotten access to a resource that they shouldn't have. You know, when we talk about biometrics,
biometrics, maybe we're gonna use
So my signature is gonna authenticate me.
Well, when I sign the sheet of paper or I signed the digital register, whatever it is I'm signing,
if my signature looks close enough to the temperature to the baseline signature, you're gonna allow me to gain access.
So maybe I've created a reasonable forgery and I've gained access to an object based on, you know, this forged access of Tim. So however it's
whatever means makes its successful, we refer to that as unauthorized access someone that shouldn't be allowed. Access is given access.
We can also talk about inappropriate system usage. Um, the acceptable use policies of a system or of a service or a mechanism when those air violated, we refer to that is inappropriate. Inappropriate usage. OK, so with incident response, we have a four step
process that would be followed to prepare our incident response.
And the first step is preparation.
Now, with preparation, I have to pull together a team. I have to train the team. I have to have a set of policies and procedures in place. I have to have the necessary tools. Preparation is where we're gonna spend a lot of work, a lot of time and effort, because if we're not well prepared, we will make mistakes
and we won't wind up
losing. Valuable evidence will wind up. Perhaps losing valuable data
will wind up notifying an attacker that we're onto them and maybe give them opportunity to erase any sort of trail they may have left behind. If we're unprepared, we need to really look att, outsourcing our incident response because we could do more damage from an UN prepared response,
then we can really, almost from no response at all.
Okay, After we prepare, we look to detect and analyze the incident. So we want to figure out what systems are affected, and we want to start looking at the root calls and doing the analysis there and figure out, you know, how did this code and get on their network? What's the scope of the damage? What
did the activity, you know, what was the nature of this attack?
Then we move on to containment eradication and recovery that's more focused about getting back up and running. So we recorded our information with documented We have done our analysis. Now let's get back up and let's get restored to the environment, which we were before the attack. And then, of course,
after we're done, there will always be a post incident review.
Where we take our team members, we debrief them and we want to create a document called Lessons Learned. And with those lessons learned, we want a document. How was that attacker successful? To what degree were they successful? What tools did they use? What internal vulnerability did they export?
Because we want to become a better a stronger environment as we move forward, so we can't guarantee that incidents won't happen. But what we do want is for every incident that is successful, we want to become stronger because our knowledge increases.
Now. An incident with an unknown calls or an unknown origin is called a problem,
and problem management really has several of the same
steps and factors involved. One of the things you'll see, though, is root cause analysis because we don't really understand what the source of this Maybe we've lost power to our building. We have no idea why. So we've got to notify and incidents happened and now we've got to get to the root of it because I can't fix the problem
unless I know the source of the problem.
So we do that root cause analysis that would lead us to a solution.
And then we implement a request for change. The solution gets implemented, then we continue to monitor so a problem. It's just simply an incident with an unknown origin.