Responding to a Cyber Incident

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 19 minutes
Video Transcription
Well, we have made it to module five. I hope you have enjoyed this course as much as I have teaching it,
and I'm looking forward to the remainder of the material that we have here.
So in module five now we're going to be talking about to me the fun part, and that's responding to the cyber incident. And we have gone through detection and preparing the program and continuous monitoring and policy. We've covered a lot of material here and now we'll get into
the nuts and bolts of one. Some things happen and you need to respond.
How should you go about doing that?
So in this particular lesson, we're gonna talk about why tabletop exercises air so important
and also the different IR frameworks that are available. We'll look at the use of checklists during IR activities.
How playbooks can be used in IR.
We'll discuss the order of volatility when responding to an incident
and the roles that should be staffed while responding to an incident.
It's so important to practice your i R plan, the one that we've been talking about throughout this whole course to create needs to be practiced in the best way to do that is through tabletop exercises.
I frequently come into organizations and help them and actually facilitate tabletop exercises so they can practice all of the things that they have put into their plan. I have told you earlier that I spent 11 years in law enforcement before that, and I didn't mention this is I spent eight years as a firefighter and
in E m. T. And one thing I can tell you from all of those years and public safety is you train, train, train and you make sure that your training is realistic that way when the incident happens, whether it's a structure fire or you have to do something,
uh, save someone's life in a car crash or whatever the case is that you know exactly how to do it. You've practiced it before and you've practiced with your team. So you all know each other's capabilities training experience, and you know the roles and responsibilities.
There is no difference between that and a cyber incident where your team should be training together. You should work your plans and do tabletop exercises. Have scenario based training where somebody, whether it's internal or you bring in somebody like me to walk you through
the incident of the scenario and you row plate and you try and make it as realistic as possible. Put some pressure on people and have things come out about
while we don't have a plan for this or we didn't include this person or we don't really have visibility into that kind of, ah scenario in it. How it helps highlight all of the gaps that there might be in the program from a training perspective and a technology perspective or a people perspective. So I can't
stress this enough
that you should be practicing your i r plans in your playbooks by using tabletop exercises as a team.
And really make sure the first time you're not using these is when you have a true incident going on.
A framework to consider when you're doing these things is the Yoda Luke. This is an Air Force concept that I really like. I use this all the time with all sorts of different things, but it stands for observe, Orient, decide and act.
So when you are faced with a situation, these are the steps that you want to look at and whether it's Ah fire or an incident that you're responding to, you have to observe what's going on, orange yourself to the situation, decide and then act. You also want to consider checklists. There is a reason that pilots use them
having checklists take a lot of the
questions off the table. And also, if you have certain people that just don't do well under pressure, checklists are great for that, too. So you want to make sure that you have checklists, that they're available and people have trained on them and know how to use them. Necklace that I've created in the past on the left hand side is just a screenshot of one of mine,
but I used to create checklists for different roles.
So the i R team lead had a checklist. Our communications person had a checklist. If we had to respond off site so sometimes we would get requests from other agencies because we had a pretty well known I our team that was very proficient. We would have people call us and say, Can your team come in and help us with this incident?
A. Soon as we got the request, I had a checklist I would send off to the people making the request.
That says, before we hit the ground, here's all the things we need from you and it was great cause as soon as we got there, they would say Check, check, check. We did those things. Here's everything he asked for. Let's get going. Ah, the certain manager. And then I t also your sys admin is your network administrators, maybe service desk
are some other areas that you might want to have a checklist for.
Now, here's a sample playbook that you could create on phishing email. So I'm just gonna walk you through this as an example. But emails received goes through your typical gateway inspection looks at the I P Address for reputation. If there's attachments that may detonate those in a sandbox,
how did the girls look? Is this known spam? Malicious attachments, etcetera?
Then it goes down. Is it malicious? No, Give it to the person isn't malicious. Yes, we block it and report it. That's pretty simple, and this is what happens millions of times every single day.
But then we break and we look over on some additional playbooks. There's a report of a fish. Maybe you got a retrospective alert. We've talked about those. Or threat intelligence tells you that a fish got through into your organization.
You review the email, header the contents of the email, you submit the attachments to a sandbox or you have somebody reverse engineer them based on that. Is it malicious? Yes. While we're going to go to the next phase. If not, then you can disposition it out. So you investigated it. You determine. In fact, it was not malicious. And you leave it with the user.
If it is malicious. Now we look at things like who got the message? We need to identify all the recipients. We can do that in exchange logs. Or if you're using G suite, you can look at their logs, whatever you have to look through. Who got this message and then was it forwarded to anyone afterwards? Internal. And you really want to run this down
and then search your sim your firewall logs proxy logs for any systems accessing the
de and s the domain name included in there. The I P address. However, it's in there to see whether or not you have any systems reaching out. Typically, what happens in these phishing emails is it may give a dropper some very small file to the system, but then that calls out and downloads the entire payload
search systems with your er tool for any evidence of execution and to see if those attachments still exist.
Remove the files with your PDR tool and if, in fact you find systems are infected. Now we go to our malware playbook. But this is a great example of something you could use with a sore tool as well to automate some of this, but it this is just great for your incident handlers to just to go through.
I didn't think about looking in the SIM to see who got this message, or
I didn't think about looking in the firewall logs to see if anybody had actually reached out to that I p address. So it helps eliminate those things that might be overlooked.
If you're collecting memory on a system, there is an order of volatility, meaning the order that you should collect first, because this stuff is more fragile and volatile than the other data. So the first thing we want to collect, of course, is the memory from the system,
then the system information. After that, the network data from the system and then finally the processes and drivers that are installed on that system and the processes that are running and executed on the box.
Now, as you start going through your incident response phases, you want to determine the scope of the incident. This is a screenshot of spreadsheet that I use that's just simply affected hosts, and I start tracking. What's the internal I. P. Address of the host? The host name the S. The role
is it? A domain controller is a desktop.
And then the physical location is it in our California office or New York office or Texas office? And start tracking that, And this will really help you define the scope of the incident, which is extremely important. Is this a single host? Little I incident? Or do we have multiple hosts
across the country across different subsets of our network
that are infected and you're going to want to keep this list for remediation reasons, but also to help just brief executives and anyone else who needs to know what the scope of this incident. ISS
some steps to consider is, once your scope is determined, make a coordinated and simultaneous attempt to remove everything from the network at once. That's why the scope is so important. Now, this should be done in close concert with
legal and with executives and the c i. O.
And I'm gonna talk through some of that later. But this is just one thing. When you look at your scope, one reason we do this is you can knock out everything at once. You do not want to start just pulling systems off line. Because if you have an advanced adversary who detects the fact that you're onto them and you're starting to disconnect systems
than for those systems, they still have a foothold in.
They can immediately start extra trading as much data as they can and also trying to move laterally very quickly. So you really don't want to tip your hat until you absolutely have to.
You can block known attack, command and control domain. So if you see multiple systems all going to an I P address that you don't recognize or is known to be bad at the firewall level, you could block access to that
again to calculated move. They could have another I p that based on the malware that if it detects it, can't go toe one. It automatically switches to two, and it starts. Expel trading data. So be on the lookout for things like that.
You may need the block dynamic. DNS. Providers change all compromised passwords that maybe something you need to dio. Actually, this is one thing. Anecdotally, just to keep in mind. It's not easy to change all the passwords in your environment. You have application passwords, probably some old hard coded passwords.
Active directory stuff's easy kind of. I mean, you still have to
notify users and go through the the headache of that process.
But you should actually have some documentation on what all passwords air out there and what the process is like desktop instructions on how you would change those if you had to do it. I say this with experience, rebuild or replace compromise hosts is something you may need to dio remember those gold images and how important those are
now. One thing just to do just all the time, in my opinion, deny uncapped ago rised Web traffic. A lot of our next Gen firewalls have unified threat management that gives you the opportunity to deny traffic to uncap tego ries domains.
And this means domains that hasn't been looked at by somebody and says, All right, this is news and information. This is technology.
Ah, this is sales or whatever it might be. If it's just uncapped ago rised. It probably means it hasn't been seen before, and generally no good ever comes from going to those websites, so just blocked that whole category.
Of course, patching systems and hardening them is something you should do all the time. Reconnect and monitor. So if you've rebuilt systems, you've patched them. You've hardened them with benchmarks or Stig's. And now you reconnect. You wanna watch closely of any new network traffic that's coming up that you wouldn't expect.
And if there's additional malicious activity, we just start all over again. There's some pretty advanced malware out there that can be
in the kernel level or the bios of a system that really nothing you're going to dio from a software standpoints going to fix it. So you do want to be mindful of that.
Some roles to consider staffing in an incident response process or event is log collection and analysis. You may give somebody the job of just going and collecting logs and reviewing those.
You should have somebody leading it. You need a certain lead. This shouldn't normally be the cyst, so
or the sock manager. It's normally a lead technical person that's going to be running as the case agent for this
forensics. You need somebody doing digital forensics, of course. Evidence collection we mentioned already. Earlier, we talked about
the importance of proper evidence handling and collection, and it's usually a good idea to assign that toe. One person for chain of custody reasons. Communications. Who's going to be giving messages out to end users to executives, maybe to the media?
Ascribe. As funny as that sounds, it's actually a really good idea for fast paced incidents to have somebody assigned to nothing but taking notes.
Who did what? When did we learn about something? Who did we call? What? Maybe they could do the spreadsheet I showed of affected hosts. That sort of thing can really be useful down the road. Reverse engineer would be another one to have
ascribe may sound like a funny position have, but it actually can be very valuable
documenting things like Who did what Who did we call? What hosts are affected, What have we discovered? And when they're all really good things to have documented and can be extremely helpful later on. A reverse engineer person can be a great asset. And then
somebody assigned to eradication and recovery after the incident has been handled.
We've talked about racy many times. Checklists can be good for all of those positions I just went through, and I typically have checklists for all of them. So here's an example of a checklist for a forensic examiner. They may need to identify hosts. Perform live response, poll physical memory from the box,
acquire the system dating time the system information it, Sentra. You can read that there.
This is an actual checklist that I use for forensics on these incidents, and I've got one for all of that circle side. I just showed you have got one of these checklist for those positions.
Now there's a couple of frameworks I just want to introduce you to very quickly and at a high level. I'm not going to go in depth, but you can look at these have included the links below.
This is called the Diamond Models, a model created by somebody within the Department of Defense. And it essentially says that every event has these four characteristics associated with it, which is the sides there, the corners of the diamond here,
they all have an adversary.
There's capabilities associated with that adversary that you need to be aware of. There's a victim involved in the attack, and then there's infrastructure to be aware of. This slide here shows some examples,
and then these diamonds can build off of each other, depending on the situation. And there's just a lot of information that you can download as well on this model and learn more about it, so wanted to just introduce it to you. The next one I want to go over is something that is used frequently, and this is the miter attack framework.
It's an awesome framework.
There's just a ton of information here. I'm not going to go into it anywhere. There's probably other cyber recourses on all of these, but
the link is below for this, but this gives you use cases and how adversaries may react to things how you can try and prevent them, what you can expect from different attacks. So a really good framework to look through if you're not familiar with it already,
and then the last one I want to introduce you to you may have seen it. Is Lockheed Martin's attack kill chain very popular. We see it all the time on different cyber trainings, and it talks about the seven steps that we see Attackers go through from reconnaissance all the way down to meeting their actions and objectives
through hands on keyboard type of work. You are obviously remotely
so. This is another really logical framework to use, and you can align all of your activities to this kill chain as well. Okay, this was a pretty good lesson, and what I want to go through is a couple questions on it. First, why should I? Our team's conduct tabletop exercises
A. Because they're fast and easy to set up,
be in order to practice plans and find gaps or deficiencies before an actual incident
or C, because the CFO will require it.
Well, if he answered, be you are correct.
In order to practice your plans and find gaps or deficiencies before an actual incident, just like I talked about with the fire department going out, they have trained on all the types of scenarios that they're going to encounter. They know exactly what to dio, who's going to do what, and you should be the same way with your incident response team.
Next question. What does the Buddha loop stand for? Observe Orient, decide and act for a be organized, observed and deny access
and see observation, orchestration, determined and automate.
All right, The right answer for this is a Remember we're observing were orienting ourselves. We're going to make a decision and then we have to act on that decision.
So in summary on this lesson, we talked about why tabletop exercises are important and how to conduct them. We talked about different IR frameworks that are available. We talked through the use of checklists during IR activities. How playbooks can be used,
the order of volatility when responding to an incident
and roles that should be staffed while responding to an incident
Up Next