- [Instructor] Once you've successfully contained
a security incident, you can take a moment
to breathe a sigh of relief,
but the work of incident response has only just begun.
You've managed to contain the damage caused by the incident,
but now you must move on to the eradication
and recovery stages of the process.
Your goal during eradication
is to remove any traces of the incident
from your systems and networks.
If attackers compromised user accounts,
you'll need to secure those accounts.
If they compromised systems or network devices,
you'll need to secure those configurations as well.
Basically, you need to go through your network
and remove any traces of the security incident
so that you can be certain
that you've effectively secured your organization.
The second goal you have
during this stage of the process is recovery.
This means that you need
to restore normal business operations.
Now, while the process describes eradication and recovery
as two separate activities,
they are very closely linked and the reality is
that eradication and recovery activities
often take place side by side.
It's sometimes difficult to say whether an activity
you're undertaking should be classified as eradication
or recovery, and frankly, it doesn't really matter.
During many security incidents,
attackers gain user or administrator-level access
to one or more systems or devices on your network.
It's often difficult to tell how much access they gained
and what back doors they might've installed.
Therefore, security professionals consider it
a good practice to reconstruct any systems
that were compromised during a security incident.
This reconstruction typically consists of rebuilding
or reimaging the machine or doing a reset
to factory defaults for network devices and appliances.
Performing reconstruction in this manner ensures
that the attackers didn't leave a hidden back door
in your system that allows them to regain access
once you resume normal operations.
When you're rebuilding a system,
remember that you may need to build it differently
than you did in the past.
If an attacker compromised the system,
you have to understand how they compromised it.
If you were missing a security patch,
make sure that you apply that patch
before bringing the system back online.
If user accounts were compromised,
make sure those user accounts are secured
before you go live.
If you rebuild a system using the pre-attack image,
you'll likely have the same security vulnerability
that allowed the attack to take place,
and you might find yourself repeating
the incident response process in only a few hours.
Now in most cases, an incident occurred
because an attacker exploited one or more vulnerabilities.
During the incident reconstitution effort,
administrators must identify
and remediate those vulnerabilities.
This may include endpoint security actions,
like deploying application whitelisting or blacklisting
and deploying quarantine technology
that automatically isolates future compromised systems.
In cases where you can't completely remediate
a vulnerability, you'll want to deploy
a compensating control that addresses the security risk
created by the uncorrected vulnerability.
You'll also want to put some effort
into strengthening access control measures.
After all, if you simply restore systems from a backup
and bring them back to the state where they were
before the incident took place,
that state probably includes the same vulnerability
that started the incident in the first place,
and you're just setting yourself up for another disaster.
The recovery phase is also a good opportunity
to examine improvements to your cybersecurity tools.
You may need to make configuration changes,
such as modifying firewall rules
to prevent future incidents,
reconfiguring or deploying
mobile device management technology
to lock down smartphones and tablets,
using data loss prevention solutions
to prevent the exfiltration of sensitive information,
deploying URL filtering and content filtering solutions
to prevent users from accessing malicious sites,
and updating or revoking any digital certificates
that may have been compromised during the incident.
Sanitization and secure disposal are also important
incident response activities.
You may find yourself needing to dispose of media
that contains sensitive information,
and you should take steps to ensure
that you've removed any traces of that sensitive information
before disposing of the media.
NIST provides a set of guidelines
for secure media sanitization
in their Special Publication 800-88.
It includes three different activities
for sanitizing electronic media.
Clearing is the most basic sanitization technique,
and it consists of simply writing new data
to the device that overwrites the sensitive data
that was stored on it.
Clearing is effective against most types of casual analysis.
Purging is similar to clearing,
but it uses more advanced techniques and it takes longer.
Purging might use cryptographic functions
to obscure media on the disk.
Purging also includes the use of degaussing techniques
that apply strong magnetic fields
to securely overwrite data.
Then destroying is the ultimate type of data sanitization.
You can shred, pulverize, melt, incinerate,
or otherwise completely destroy the media
so that it is totally impossible for someone
to reconstruct it.
Now, the downside of destruction, of course,
is that you can't reuse the media
as you would with clearing or purging.
Here's a flow chart that can help you make decisions
about what type of sanitization technique to use.
It comes from the NIST guidelines,
and it's widely used throughout government and industry.
You begin the flow chart at one of three locations,
depending upon what classification of information
was on the media, and then you walk through a series
of decision points based upon whether you plan
to reuse the media
and whether it will leave your organization.
The flow chart then leads you to advice
on either clearing, purging, or destroying the media.