In this lesson, we're going to discuss
the incident response process and its different phases.
First, let's define what an incident is.
An incident is an act of violating an explicit
or implied security policy.
There are lots of different things
that could be categorized as an incident.
For instance, if I stole your password
and tried logging into computer issue,
that would be classified as an incident
because it goes against the organization's security policy
that state and employee should only log into their account
using their own account credentials.
Similarly, if an attacker wanted
to install malware on the system,
that would also be considered an incident
because it breaks the security policies inside
of your organization.
There are lots of different things
that could be categorized as an incident,
but in this lesson we're going to be focused on what steps
or phases will be conducted in response
to any generic incident that should occur.
There are different ways to define the phases
of an incident response,
but one of the most commonly used is produced by NIST,
the National Institute of Standards and Technology.
In the NIST Computer Security Incident Handling Guide,
special publication number 800-61,
NIST defines a four phase incident response process,
which includes preparation, detection and analysis,
containment, eradication and recovery,
and post-incident activity.
Often though, when conducting an incident response,
you will start an incident, move through preparation,
then go into detection and analysis.
Then when you find something more suspicious,
you might move into containment, eradication and recovery.
Just when you think you have gotten everything handled,
you find something else suspicious
and have to move backwards to detection and analysis again.
And so, you can see that this isn't always strictly
a linear process, but instead,
you'll often loop around in the four phases.
Inside each of these four phases,
there are different actions that we're going to take,
and these are all based on different procedures.
When we talk about incident response procedures,
these are procedures and guidelines
that are covering the appropriate priorities,
actions and responsibilities,
that should occur in the event of a security incident.
As I said earlier,
there are many different incident response processes used
in the cybersecurity industry,
and the NIST guideline is by far the most common one.
But for the exam, CompTIA actually breaks down detection
and analysis into two different phases.
And the containment, eradication, and recovery phase,
from this into three separate phases,
creating a seven phase model.
During the exam, if you get asked about the phases
of the incident response,
you should use the seven phase model covered in this lesson.
The seven phases of the CompTIA incident response cycle are,
preparation, detection, analysis, containment, eradication,
recovery, and post-incident activity or lesson learned.
Let's go ahead and look at these seven phases
in a little bit more detail.
First, we have preparation.
Preparation is a phase where cybersecurity practitioners try
to make the system resilient to attack
by hardening their systems and networks.
This is also the phase where policies
and procedures are written.
And your communication plan is created
to set up encrypted out-of-band communication paths.
The preparation phase is focused on doing everything needed
to get ready for some kind of future incident to occur.
During the preparation phase, you'll also conduct training,
testing, and exercising of your staff
with simulated incidents,
as well as the creation of incident response kits.
Second, we have detection.
The detection phase is really focused on determining
whether a security incident has occurred.
Your organization's cybersecurity and triage analysts
play a crucial role in categorizing
and assessing the potential incident severity.
Once an incident is categorized and triaged,
we can then move into our third phase.
Third, we have analysis.
Analysis occurs when an incident
is thoroughly examined and evaluated.
Analysts work diligently to understand the scope
and impact of the incident
and to provide valuable insights into the nature
and potential consequences.
Subsequently, relevant stakeholders are notified,
containment phases is initiated,
and the implementation
of the necessary initial response action is completed.
Fourth, we have containment.
Containment is used to limit the scope
and magnitude of the incident by securing data
and minimizing the impact on business operations
and your organization's customer and business partners.
For example, if a piece of malware was detected
on a given system in the detection and analysis phase,
our goal in containment is to prevent that piece of malware
from spreading to other systems on our network.
In this case, we might disconnect the infected client
from the network and lock out the user
from using the workstation
until we can clean the effective system.
Fifth, we have eradication.
Eradication begins once the incident is contained
and it's focused on removing the malicious activity
from a given system or network.
For example, using a previous malware example,
if we have stopped it from spreading
by disconnecting the client from the network,
we can now remove the malware from that system,
or reinstall a known good image to a client
to eradicate that malware fully from the system.
Sixth, we have recovery.
Recovery is focused on restoring the effective system
and services to their normal secured state.
Recovery often involves restoring a system
from a known good backup, installing security patches,
or implementing configuration updates,
to ensure that any vulnerabilities exploited
during the incident have been fully
and appropriately remediated.
Additionally, your organization's recovery procedures
may include monitoring systems
for any signs of lingering threats
to ensure a smooth return to normal operations.
The ultimate goal is to minimize the impact of the incident
and ensure the organization can resume
its regular activities with increased resilience
against future threats.
Seventh, we have post-incident activity or lessons learned.
Post-incident activity occurs after the system
has been contained and malicious activity was eradicated
and the system is fully recovered
and restored to operations.
At this point, we will spend some time analyzing
the incident and the response
to identify whether the procedures and systems
that we had worked properly,
or is there anything else we can do better next time.
During the post-incident activity,
there are three major actions that occur.
The root cause analysis, the lessons learn process,
and the after-action report.
The root cause analysis is a systematic approach
to identify the initial source of the incident
and how to prevent it from occurring again.
This analysis usually occurs using a four step process.
One, define/scope the incident.
Two, determine the causal relationship
that led to the incident.
Three, identify an effective solution.
And four, implement and track the solutions
to ensure that the incident is fully resolved.
So, let's consider an example of a malware infection
in your organization.
First, you would want to determine
the initial cause of the incident.
Maybe it was caused by malware
being introduced to your network
by a user plugging in a thumb drive to their workstation.
Whatever the initial vector was,
you want to find it and prevent it from occurring again.
So, how can we prevent this from occurring again?
First, we might ensure all of our workstations
have the latest version
of our vendors' antivirus signatures on them.
Next, we might also want to prevent data transfer
from the USB devices like thumb drive for all the users.
And third, made with this particular piece of malware
was found to only infect the windows machines
that are missing a certain software patch.
On with this information,
we can develop a plan to correct the incident,
update all of the antivirus signatures,
reconfigure the workstations to prevent USB devices,
and install the windows patch across our network.
Our IT management team can track the implementation
of the solutions as we fully recover from this incident.
Next, we have the lessons learned process.
This process is a formalized method
to document the things we've experienced during an incident,
what went right, what went wrong,
and what could we do better next time.
All of these things should be recorded
in our internal organization.
Processes should be improved,
so that the same issue does not occur again
in our next incident.
For example, maybe the change management board was too slow
to approve the security fix we needed to implement
to fully secure the network.
One lessons learned that might be captured
is the need to decrease the approved times
for emergent change requests during an incident.
We don't have to redevelop and change processes
during the lessons learned.
We just need to identify what could be improved.
Finally, we have the after-action report.
This is a formalized report that collects information
about what happened.
In this report, you should have the root cause analysis
and the recommendations for improvements
from your lessons learned.
Depending on your organization,
the report may be very detailed and technical,
or it may be written instead as an executive summary.
Incident response and recovery
is a truly important function in our organizations
because it seems every day there's another story
of a major data breach in the news.
Try as we might, we can never make our networks
a hundred percent secure.
And that means, eventually, we will likely have to reform
an incident response and recovery.
How you handled this situation during that critical time
will determine how bad the incident will truly become
for your organization.
In order to conduct a proper incident response,
your organization should utilize a team of professionals.
But what does this incident response team look like?
Well, the core team is made up
of cybersecurity professionals
with incident response experience,
and they're supplemented by temporary members
that are brought in for a specific incident.
For example, if a database is involved,
you may wish to deputize a database administrator
be part of the team during this response.
Large organizations often have dedicated
incident response teams
where the members perform this role fully,
but smaller organizations
will instead create temporary teams that are brought in
and brought together for a specific incident.
These roles on the team become a sort of additional duty
for an IT administrator or other employees
in addition to their normal job functions.
The team is made up of a leader,
who is a skilled incident responder,
subject-matter experts, IT support staff, legal counsel,
and human resources and public relations.
Your organizational leadership and management teams
are responsible for ensuring the team has funding,
resources and expertise,
needed to conduct the incident response.
Management is also required
to make the critical business decisions
during the incident's response
and communicating those decisions to key stakeholders
or the media as appropriate.
The other method that some organizations
have taken to handle incident response,
is to outsource the incident response teams.
While this can be effective,
since these teams specialize in doing nothing
but incident response all day long,
this can be a very expensive method to utilize.
The other challenge with outsourcing your incident response
is that these outside organizations are not familiar
with your enterprise networks,
so they will have to spend some time learning your network
before they can conduct their response efforts.
From my experience, when it comes to incident responses,
they are not something
that you should be looking forward to.
They are stressful and they include days without sleep
and the constant threat that the threat actors
are still one step ahead of you.
So, remember, our job during the incident response
is to contain the issue, mitigate the threats,
and get the organization back until solid footing
as quickly as possible.
This includes detecting the incident,
responding to the threat,
collecting evidence, containing the issue,
restoring the network to full functionality,
and further securing it to prevent reinfection.