Time
5 hours 54 minutes
Difficulty
Intermediate
CEU/CPE
6

Video Description

This lesson focuses on incident response. Incident management centers on the following: • Events: an observable change in state • Alerts: flagged events to determine if something has taken place earlier • Incidents: adverse impact to a system or network. Types include: o DoS o Malicious code o Unauthorized access o Inappropriate usage When an incident occurs, it is important the resulting response is consistent and well controlled. This is a four step process: • Preparation • Detection and analysis • Containment, eradication and recovery • Post-Incident review This lesson also briefly touches upon problem management, which occurs when there is an incident with an unknown cause.

Video Transcription

00:04
Now we're gonna move on to talking about incident management
00:07
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,
00:18
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 change in ST
00:30
now, when we have multiple events that have an adverse effect on the system or network, that becomes an incident
00:39
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 alert. You're used to help us
00:55
trigger warning in case these incidents happened so an alert might be set up to send me an email message.
01:02
Should we run out of space on our foreign drive or whatever, that might be?
01:07
All right, so 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, uh, malicious intrusion,
01:23
Whether it's not with surface attack or distributed denial of service attack
01:27
and you'll hear there's 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
01:48
yeah,
01:48
um, you know, if you're familiar with the Group Anonymous that's been in the news a lot lately. Ah, and they bring a form of, um, of vigilante ism that we call hacktivism. So they're expressing their political frustration right now by hacking into
02:06
servers of people that they they believe are worthy of attack.
02:08
So, um, 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,
02:24
uh, where they took several of the major credit card companies off line for a period of time one morning.
02:31
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 his time off line.
02:44
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.
03:00
All right, Another term malicious code. A code that sort of an all size. It's 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,
03:19
uh, looks at exploiting vulnerabilities on the system.
03:23
Other types of incidents. Unauthorized access to resource is so a subject that shouldn't be at authorized
03:30
toe 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.
03:40
Uh, maybe I have guessed your password.
03:45
Maybe I have, um,
03:47
uh,
03:49
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.
04:03
You know, when we talk about biometrics,
04:05
biometrics, maybe we're gonna use signature.
04:10
So my signature is gonna authenticate me.
04:13
Well, when I sign the sheet of paper or I signed the digital register, whatever it is I'm signing,
04:19
if my signature looks close enough to the temperature to the baseline signature, you're gonna allow me to gain access.
04:28
So maybe I've created a reasonable for Cherie and I've gained access to an object based on, you know, this forged access attempts. So however, it's
04:39
whatever means makes its successful, we refer to that as unauthorized access. Someone that shouldn't be allowed. Access is given access.
04:47
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.
05:03
Excuse me. Okay. 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.
05:15
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
05:35
and we won't wind up
05:38
losing. Valuable evidence will wind up. Perhaps losing valuable battle
05:44
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,
06:00
then we can really almost no response at all.
06:04
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? Um, what
06:24
did the activity? You know, what was the nature of this attack?
06:28
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
06:42
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.
06:50
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 exploit?
07:10
Because we want to become a better ah, 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.
07:29
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.
07:43
One of the things you'll see, though, is root cause analysis because we don't really understand what the source of this
07:48
Maybe we've lost power to our building. We have no idea why. So we've gotta 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.
08:07
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.

Up Next

ISC2 Certified Secure Software Life-cycle Professional (CSSLP)

This course helps professionals in the industry build their credentials to advance within their organization, allowing them to learn valuable managerial skills as well as how to apply the best practices to keep organizations systems running well.

Instructed By

Instructor Profile Image
Kelly Handerhan
Senior Instructor