Incident Response Lifecycle Remediate Eradicate and Lessons Learned

00:04

okay after containment. Then we're gonna look at eradicating and remediating so removing what's there that shouldn't be there and then ultimately lose that.

00:18

So if we have had some form of Mao were, ah that has infected the system using air, any virus or any mild where software to remove that To eradicate the this malicious code,

00:33

we may have to re image systems, you know, with our client computers. That's that's not such a big deal. We generally have a baseline client configuration image, and if your system is affected, then we're just gonna push out an image and re image your system

00:50

That can be much more complex. If we're looking at

00:54

domain comptroller's Web servers, database servers and the like. It may not be that quick and easy to re image or to rebuild.

01:02

Um, sometimes we have to restore from original media. You know there's certain attacks, like root kits that get in bed with the operating system kernel, and we don't want to restore that system from backup because that room can't may already be in the backups as well.

01:19

So in that instance, it's usually safe. It's just a reinstall operating system just

01:23

blow out the system, reinstall the operating system for media and then recover the data from backup

01:33

accounts may have been created or compromise. We wantto leave those accounts. We want a disabled them. If service's have been launched, then we won't disable. Those service's ports have been open. Closed those ports. Make sure that we hard in our systems,

01:52

you know. And ideally, we have a baseline configuration image

01:56

where the systems were hardened. But obviously, in the event of this compromise, we need Thio Take a look at where we failed. Where was their system, not harden. What allowed this point of compromise?

02:08

Um,

02:09

after the event of an attack were certainly goingto watch increase our activity in relation toe monitoring and reviewing log files. Often, Attackers continue to go back to the same target again and again and again. And they view a compromise

02:29

as an indication of a vulnerable system or vulnerable environment.

02:32

So I may correct this law. Ah, but the Attackers gonna just keep knocking and keep knocking. Keep trying. Keep trying. So we want to make sure that we're reviewing those security loves on a very, very regular basis.

02:46

Um, we want to scan our systems and scan the networks are systems We're gonna scan with any virus software on a regular basis, maybe nightly. But we're also going to conduct regular scans of our networks looking for unauthorized devices. Unauthorized service is that maybe running.

03:06

So when it comes to eradication

03:07

and remediation, we're looking to remove whatever

03:13

we're looking to reverse the results of the attack idea. And then our final step along the way is word in a document document document Document.

03:24

What happened? How did it happen? Um, what do we think led up to the attack? What did we missed? What worked in mitigation and what didn't work? And we take all this information, we pull it together in a document called Lessons Learned. We're going to get feedback from our incident response team,

03:45

and each member may have a unique perspective. So we want to solicit that information

03:50

from our incident response team through making the briefing session once about maybe questionnaires. But we want to pull all the information we can from that team because it's most important that we don't fall vulnerable to a similar attack in the future.

04:05

We're gonna document those findings and Ultimately or often, what we found in what we've documented for lessons learned may trigger the need for a modification. The need for change. Maybe we wanna reconfigure security baselines

04:24

because we found that there was a vulnerable service running

04:27

or our baseline didn't contain the latest security, I think, whatever that may be, remember, we have a formal change control process in place, so we don't just run around making these changes because we think it's a good idea. But this is a good point to collect information that very well may trigger

04:46

updates.

04:48

Look at our risk responses, figure out what worked and what didn't work.

04:53

Always with the goal of improvement. Sometimes we might find retraining is necessary. We may need to retrain our users. Maybe it was an incident that the user allowed to happen, or that the user generated. Or maybe our response team didn't perform. Or maybe

05:10

we found a different way that might be more effective.

05:14

So we may need retraining of our staff of our team, Uh, of really. Anyone within the organization can benefit from retraining as a result of successful incidents, detection and how we responded to it again. Let's make sure this doesn't happen again. So ultimately,

05:32

those are the steps of the life cycle for incident response,

05:36

and as a schism, I'm responsible for making sure that I am actively involved in each of the steps of the life cycle process, making sure that we have to support the documents, the tools, the training and everything that we need

05:53

tohave aware bust, uh, environment in place to which we can respond to incidents.

05:59

Now the next chapter is on business continuity and disaster recovery. So when you're incidents of small scale escalate and they affect the organization as a whole, now we start to shift over to those situations. World might

06:15

look at it being a disaster in place, and they have to do a large scale,