-: Incident response phases.
So when we start talking about incident response,
these are conducted in phases, and there's generally
four phases that we're gonna go through.
This process isn't linear, though.
It's much more cyclical, as you can see here on the screen.
As we go from preparation to detection analysis,
then we can go to containment, eradication, and recovery.
Sometimes we'll find more stuff.
We have to detect more and do some more eradication.
Eventually, we'll get to post-incident activity,
and then sometimes,
that'll get us back to preparing for the next one.
And you'll see these things happen in cycles
as opposed to just a straight line from one to four.
Now, where do these four phases come into play?
Well, we get this from the NIST manual.
It's a special publication 800-61,
which is your Computer Security Incident Handling Guide.
And this is a national publication
made by the US government.
It's not required.
It's not legal that you have to follow it,
but it is a great guideline and can help you
as you're building your own incident response plans.
For the purposes of this class,
we're going to follow the NIST SP 800-61,
the Computer Security Incident Handling Guide,
because it gives us some common framework
for all of us to talk about as opposed to using one
specific to my organization or your organization.
But most organizations base theirs off of this guide,
so it's a great place for us to consider.
Now, preparation, which is our first step in this process.
This takes preparation for us to build
a well-oiled machine or team of this CSIRT.
So this Computer Security Incident Response Team,
you have to prepare for it to be effective.
This is gonna require a proper policy foundation
within your organization as well as preparing
proper cyber defenses inside the organization.
I can't just hire on a CSIRT and expect them to be able
to do their job if I have not put the proper censoring
in place or the proper logging in place,
and we're gonna talk all about censoring the network
and logging these events
throughout our time together in the next couple hours.
But just realize that we have to plan all of that.
Otherwise, it's gonna be ineffective for us.
Also, we need to identify and train our personnel
and build their skillsets.
Hiring somebody in and having them not understand
how your network is built is a recipe for disaster.
Instead, we need to make sure that they have
continual training, and they're continually learning
and evolving on your network to know
what normal looks like and what normal doesn't look like.
As we prepare, we also have to have the right toolkits.
There's lots of different tools out there
that we're gonna buy, and this is the best time to do it,
because you're not in the middle of a crisis.
You're not in the middle of an incident.
So as we're sitting here during daily operations,
this is the time to buy and learn how to use your tools,
things like digital forensic workstations,
forensic software, packet capture devices,
spare servers and network gear,
backup devices and blank removable media,
collection, analysis, and reporting laptops,
portable printers, office supplies,
evidence collection materials, and more.
You take all of this information,
you pack it up into what we call pelican cases
or some kind of carry-on totes
so that when there's an incident, we can respond quickly
and just grab the gear and go.
Now, this gear should be taken out often and played with
and tested, but it should always be returned
back to a known good state so you're ready
for the next incident whenever it does occur.
The second phase we're going
to talk about is detection and analysis.
This is the hardest to standardize,
because detection really is part of an art form,
as people all do it in a different way.
There are tools that help us in detection,
but it takes a trained analyst to really figure out
what they're reading in the logs and how that applies
to your network to perform that analysis.
When detection occurs, analysts are going to shift
from a validation mode to an analysis mode
and start digging in to figure out what incident happened
and how it's spreading and what we can do about it.
This is primarily done through passive activities
designed to uncover and analyze an incident,
but there are some active analysis methods as well
that we can talk about.
So, when we start talking about analysis,
there are event indicators,
and there's really four things that can really signify
that an event has occurred,
and that event may turn into an incident.
The first one is an alert.
This can come from an IDS or an IPS, an intrusion
detection system or an intrusion protection system.
It can come from seam, which is an integrator for your logs.
It can come from any virus or other software alerts.
Any of these can pop off, and you can go, oh, no,
there may be an issue here.
You'll then analyze it, look into it further,
and decide if there was an issue or not.
You have logs.
These can come from operating systems,
services, applications, network devices, and network flows.
All of these logs should be correlated.
They should be time- and date-stamped,
and then we can figure out
what is going on in our network, and is it normal or not?
We'll talk a lot about that throughout this course.
You also look at publicly available information.
For example, you may have read in the newspaper this morning
that a new type of ransomware is out there on the market,
and that people are being affected by it.
This is something that could affect you,
and you'll start looking through your logs to see,
am I detecting that in my own networks?
People.
People are another great indicator,
because suspicious activity
can be reported by your end-users or by your admins.
For example, in one organization,
I got a phone call from one of my users
that said hey, my mouse is running all over the screen,
and I'm not touching my mouse.
That can be an indicator
that there's malware on that particular machine,
and it's something that we then needed to look at,
and we did our detection analysis of that machine
to determine if there was malware of if there wasn't.
Now, when we start talking about detection analysis,
there are best practices for analysis.
You wanna profile your networks and systems
so you can start creating and understanding your baseline.
Your baseline is what normal is.
What is normal activity for this particular machine,
this particular network,
or this particular operating system?
You're there to create good logging practices,
because without good logs,
you'll never be able to recreate the events.
You wanna conduct event correlation,
and the best way to do this is ensuring that all
of your systems have the synchronized network
and time clocks are all the same,
because if I have five o'clock over here and 1:30 over here,
even though they're on the same exact time
in the real world, if their clocks weren't synced,
those events can be very difficult to correlate later.
We also wanna maintain an organizational knowledge base
so we can understand what is normal for this organization
and what kind of things we see over and over again.
We wanna capture our network traffic
as soon as we think there is an incident.
So we may not capture every piece of network traffic
out there during day-to-day operations
because there's just too much data
and we don't have enough collection or storage ability,
but as soon as there's an incident,
we wanna start getting packet analysis
and packet capture done immediately.
We also wanna filter out the information
that's not useful to us so we can reduce confusion
and focus on what's really important,
and finally, we wanna make sure we understand
when it's above our pay grade,
when we don't understand how to do something
and we need to bring in the big guns
and bring in some outside assistance through contractors
or outsourced employees,
because they might be able to help us a little bit further.
Now, the next phase, when we get to phase three,
is containment, eradication, and recovery.
So we have seen there was an incident.
We have now detected it.
We've analyzed it.
Now we're going to focus
on stopping the spread of the incident,
removing it from the network,
and recovering from it and getting ourself back to normal.
This is gonna focus on active detection
and removal of the incident.
Now, we do this through five steps.
First, we're going to pick a containment strategy.
Is that isolation?
is it segmentation?
Are we going to just turn off the machine,
or are we gonna put it in its own little box, right?
We're gonna use this strategy to limit the damage
the incident causes, because if we can do segmentation
and have it only affect maybe the human resource area,
the rest of the business can keep operating.
And so those are decisions that we're gonna have to make
as a CSIRT and as management.
We're gonna gather evidence needed
for any potential future legal action.
So if we think we're gonna have to sue somebody over this,
if we're gonna have to go take 'em to court
or the FBI needs to get involved or the local police,
this is the time we need to start collecting that data
so we can use it later.
We need to identify the attacking system or attacker,
and with do this for many reasons.
One may be for legal actions.
One may be just so we can block them
so they can't get to us further.
And then we wanna remove the effect of the incident
and recover normal business operations.
We wanna get this incident behind us,
get it in the rear-view mirror,
and move on with normal business operations.
That takes us to post-incident activities.
The CSIRT isn't done
once any incident is contain and eradicated.
They still need to conduct other things,
and that can be event reconstruction,
lessons learned, and evidence retention.
So when we talk about event reconstruction,
we are creating a timeline of the incident.
This is where we take all those logs
and we figure out, what was the root cause?
Was caused the intrusion, and what was that incident?
We're then going to conduct consultations
with the system administrators and management
and put this into a timeline based on all the logs
so we know what happened, what our responses were,
and what we saw afterwards.
Then we're going to do our lessons learned.
Lessons learned are going to utilize that timeline
to aid in the improvement processes
and procedures for our CSIRT.
This is gonna include things like group discussions
to determine how the incident was handled,
what went good, and what went bad.
This is gonna help us feed back into our proper
ITSM procedures, our IT service management,
so that in the future, we can do things better,
more efficiently, and recover much quicker.
Now, when we talk about lessons learned,
what are some of those things we want to find out?
Well, we wanna figure out what happened and when.
We wanna figure out, how did the staff perform?
What procedures were followed?
Were the procedures good enough?
What should we have done differently
so we can do this better and faster next time?
Did we effectively share information from the team
back to management and out to the outside world?
How could which have detected this incident sooner
so that we could have solved the problem quicker?
And what new tools of resources does the organization need
to be able to do this more effectively in the future?
These are all important questions that we have to consider
as we go through and figure out what we can do better.
And then the final thing
we're gonna do is evidence retention.
There's going to be lots of information
that's going to be collected during this.
We're creating timelines.
We're creating log files.
We're creating packet captures.
All of that is going to be collected
and takes up storage space.
Well, what are we going to do with all of it?
Where are we going to store it,
and how long do I have to keep it?
Well, the CSIRT must identify what your internal
and external retention requirements are.
If you're gonna have legal actions, you need to consult
your attorney before destroying anything.
We don't wanna just go, oh, we're one with this.
Let's wipe the hard drives.
We may need to back that all up
and store it off in the archives,
because there may be a lawsuit that's coming in two years.
Now, when we talk about evidence retention timelines,
what timeline should you retain it?
Well, if you work for the US government or a US government
agency, you have to maintain it for at least three years
due to their legislative requirements,
but if you're in a regular organization,
generally, we consider two years as good enough,
unless your organization has other requirements
or you fall into regulatory requirements like HIPAA
or FERPA or Sarbanes-Oxley or GLBA.
Now, with that said,
data storage is cheap nowadays.
There's really no reason
to start deleting stuff prematurely.
Keep it as long as you think you're gonna need it.
Two to three years is a good rule of thumb,
and so I recommend keeping it at least that long.