>> Hello Cyberians and welcome back
to incident response and advanced forensics.
My name is Max Alexander and I'll be
your subject matter expert for
today's course, incident recovery.
Everything that we've talked about so
far through this course
has suggested that incident response
is not just a technical solution,
but it's going to be something that is going to run
across all domains within your organization.
Likewise, because incident response
is not just a technical solution,
your recovery process is going to
be a purely technical solution as well.
Recovery is going to essentially
involve all aspects of your business model.
As we looked at the Sony hack case, obviously,
that particular incident required
individuals from all facets of the company.
More than likely they had legal representatives,
they had their public relations,
they had human resources, senior management,
IT, and probably a lot more individuals in that company
trying to help resolve
and remediate and recover from that incident.
As we talked about, a lot of the above
the waterline cost are miniscule
compared to everything that
happens below that water line,
having to pay those legal fees,
those attorney's fees, loss of brand reputation.
In that incident response process,
you're going to have a lot of those people
come in and try
and restore the company
to its former state and that can be
very expensive, timely process.
Also involved in that process
from outside of your organization could
be entities such as
law enforcement if it's a criminal matter,
such as the Sony hack case,
they brought in the FBI to help investigate this,
so you might have to work with
those law enforcement agencies.
You may also have to work with
data recovery and forensics experts,
especially if you don't have those folks on your staff.
Then lastly, remediation specialists.
The Sony hack, it was obviously a large hack,
so they may not have had enough staff
on hand to begin that remediation process.
They might have had to call in
outside experts to help them with that.
Or if you just don't have them on staff, again,
that's something you may have to
pay for as an outside service.
What is incident recovery?
First and foremost,
incident recovery is going to mean stopping
that threat and keeping it from getting worse.
Everything that we've done throughout
the course so far has been to
help identify some of the triggers for that threat,
some of the information that we
can take away from that threat so we
can formulate some type of plan to, one,
stop the threat, and then figure
out how it got into our system and
then essentially shore up
those weaknesses that we've had.
After we've stopped that threat
and we've stopped its progression,
then we can move on to
the remediation and recovery from that incident.
The first step in remediation is to
ensure that the threat is
removed from your system or network,
and then we want to prevent that from coming back.
In securing your network,
we want to limit the ability
of the attacker to access the network.
By limiting our ability and removing
the ability of the attacker to
send packets into your network,
that should provide a good method
to prevent that attack from coming back.
That action seeks not only stop
the attack at that one endpoint
that we may have identified,
but it seeks to stop the attack network wide.
The way that we're going to do
that is we're going to block
the IP addresses that are known
threats at the edge of the network on our firewall.
Also, if we are doing business in certain countries,
but are not doing business in other countries,
we could essentially block access to those countries,
and that would essentially
>> prevent any traffic going into
>> or out of our network to
those countries and just
provide us another level of protection.
Then lastly, we would want to deny servers and
critical infrastructure the ability
to directly communicate with the internet,
so essentially nullifying
any outbound connections from those devices.
That's just another way we
>> can shore up that network and
>> help prevent the attacks from occurring in the future.
The next thing we want to do is remove
the files that essentially corrupted our network.
That's a no brainer.
We want to get rid of the bad files.
Also, we want to identify the application, the service,
or the protocol that was presented
in the initial vulnerability and
what we want to do is modify
those shortcomings to prevent future attacks.
Those actions could include everything
from deleting the known bad files,
disabling unused or high risk services,
such as those that transmit in plain text,
removing software applications that
have little business use,
and updating or installing
industry standard anti malware application.
The key takeaways for these actions are to
find and remove the files
that's responsible for the attack,
delete or disable the processes or
protocols used to launch the attack.
Then lastly, remove the service or
application that created the vulnerability.
The next step action that we want to take is
removing the affected devices from our environment.
Removing the infected asset or
assets and files and returning
the assets to a known good state is
a reasonable goal for
the majority of incident response plans.
However, I'm going to caveat that
with an important note that deleting files,
powering down a system to replace a hard drive,
or restoring the system to
a previous version is going to destroy
any type of forensic evidence that can be used
to determine the root cause of that incident.
>> In many cases, capturing that information prior
to restoring the system is
the only way to essentially determine what happened.
>> If you can't do it, the forensic
>> collection process should be done first.
>> As that's the cornerstone for any and
all legal action to take as a result of the attack.
Some key takeaways for this are to
collect the images of the volatile system data,
the RAM, and the hard disk,
if at all possible.
Then power off the device
and disconnect it from that network,
again only after imaging it.
Then lastly, restore the effective devices to
a known-good state via backups or snapshots.
After we've done this remediation process and
we've gotten the files off our system,
we've got new computers online,
we essentially shorn up our firewall,
we then come to the question of,
do we share this information with others?
Ideally sharing is going to
provide the indicators that we
saw and the TTPs that we
solve to other professionals in the field.
Sharing information is going to create
a reciprocal relationship with
whomever we've shared that information with.
If I'm working at a commercial big bank
and I see some type of attack,
and I want to share that with
my buddies in other commercial big banks.
Ideally, we're going to be
creating an information-sharing consortium.
That way that's going to help me understand what
they're facing and will understand what I'm facing,
and we can protect each other.
Likewise, if you share that with the federal agencies,
they will also in turn generally share some information
to you from attacks that they have
seen that are ongoing and reoccurring.
That information sharing throughout
the community only helps to make everyone stronger.
Then the sharing of the information also helps
provide a more proactive threat intelligence team.
If you have essentially individuals that sit within
your incident response team
that are doing some intelligence work,
where we sit down aside your incidence response team.
Any information that you can
provide them or indicators of
compromise or TTPs that were used in this incident,
that's going to help them provide
better tactical information to
the cybersecurity professionals.
That way, those individuals can take proactive steps to
help protect the network and hopefully
prevent the incidents from occurring, period.
This is just an overview of that intelligent cycle.
If you do have one of
these threat intelligence
>> units within your organization,
>> the threat intelligence cycle will
essentially start at the top with requirements.
That's just going to be asking the question.
What does make this occur?
What causes this?
What do we see when something happens?
It's that initial asking of the question.
Then that goes out to
the collection individuals who
are trying to find answers to that question.
A lot of times, for incident response,
that's going to be your incident responders.
Oftentimes it may not be that they have a requirement,
it's that the collection may
occur before there's a requirement.
Then that's going to essentially
drive the rest of this intelligence cycle.
But once you collect that information,
somebody needs to do something with it.
It doesn't actually become intelligence until it's
been processed and evaluated and analyzed.
There are a couple of steps in that when you do
get the information and the indicators of
the compromise and you write your report,
you're going to send that to
your analysis shop and they're going to look
at that and they're going to process that information,
determine, "Yes, this matches
some things that we've seen.
Yes, we've seen this IP address before.
Yes, we've seen this technique used",
and they can package that together as they
should have that bigger picture
of things that are going on.
After they package that information up,
they can then begin to disseminate
that information to the individuals who may have
asked those questions or to other teams who
are going to take actions to
help prevent future attacks from occurring.
Then that dissemination of
information should draw feedback of,
"Yeah, we like this information.
Oh, we already saw this".
Or "No, this is not relevant to us".
Then the cycle essentially will
repeat itself over and over again.
That is just an example of how
information sharing can help drive
that intelligence cycle to make
your processes better in incident response.
Then lastly, after we have done
the analysis of that information and we've
seen some of the trends that are occurring,
we want to educate the workforce to make them better.
Essentially smarter users make smart choices.
A lot of times we take for granted that we
have a lot of IT education,
training, and experience,
and we forget that many users do not have
formal computer training or
have not had training in a long time.
Ideally, you want some type of
annual refresher training to remind
your employees of
some basic security awareness procedures.
Hopefully, that would prevent a lot of
these incidents from occurring, to begin with.
Keep in mind, I read
a study I think a couple of weeks ago that showed
many users are going to click on links in their emails
regardless of the content within the email message.
That's something that we failed at as a whole
in the computer security realm and community.
We have to educate these users on
proper ways and proper protocols of computer usage.
Otherwise, we keep getting
drawn back in the same incidents,
the same problems,
and if we could spend more time educating
users on proper protocols,
we might actually have to spend
less time on certain incidents.
Ideally, the more that you know about something,
the better you can defend against that.