91
5
Incident Response and Digital Forensics
Efciency is doing things right; effectiveness is doing the right things.
—Peter F. Drucker
5.1 Introduction
Incident response (IR) and digital forensics (DF) need both efciency and
effectiveness because if they are not done correctly, your efforts will be
futile. In this chapter, the fundamental processes for incident response and
digital forensic analysis will be discussed. Just today, an incident occurred on
my laptop, no less. Similarly to every other day, I dock my laptop upon my
arrival and start checking my e-mail. Within a few minutes, the IT admin
is at my door and announces that we have a problem. He said he received
a message from the main IT ofce—over 300 miles away and monitoring
over 20 locations and thousands of computers—that my laptop has been
compromised. He was instructed to remove it from the network and begin
the analysis process by scanning it for any personal information that may
have been accessed by a hacker. This is a great example of an incident; as
small as it sounds, it is, in fact, an incident. The ofcial denition of an
incident is a situation that has compromised the integrity, condentiality,
or availability of an enterprise network, host, or data. Other incident exam-
ples include attempting to gain unauthorized access to a system, a DDOS
(distributed denial of service) attack, unauthorized use of a system, website
defacement, etc.
Generally, the IR process is to detect, contain, and eradicate the incident,
and the DF process is to collect, analyze, and report the evidence. In other
words, once the incident is contained and eradicated, the DF professional
begins the evidence collection process. The goal of the analysis is to deter-
mine (1) what happened so that reoccurrence of the incident can be avoided,
and (2) whether this is a criminal case.
The cases where electronic evidence is critical are not always action packed
with computer break-ins, SQL (structured query language) injections, DDOS,
malware, phishing attempts, or company web page defacement. Some cases
requiring electronic evidence are disloyal employees who are suspected of
92 What Every Engineer Should Know About Cyber Security
industrial espionage,
*
breached contracts, an employee dismissal dispute,
theft of company documents, inappropriate use of company resources (e.g.,
possession of pornography), copyright infringement (music illegally traded
over the Internet), harassment (e-mail-based stalking), and identity theft.
5.2 Incident Response
Be prepared. We have all heard that before—especially if you were a Boy
Scout or if you read the preceding chapter. This is true of life in general as
well. For example, nancial experts tell us to prepare for job loss by having
three to six months of savings available. In a poor economy, we should have
more, but the point is that we are taught to prepare for that rainy day. When
an incident occurs on your system, it may be more of a hurricane. If you are
prepared and monitor anything that could impede success, when something
unplanned occurs, you are prepared to deal with the issue in order to get
your system back up. It is like being the only house with a generator after the
hurricane caused a neighborhood power loss.
The National Institute of Standards and Technology (NIST) has provided
a baseline for incident response. Here is the simplied view of the priority1
recommendations. The rst control (creating documentation of the IR
policy and procedures) and the last control (creating an IR plan) are part of
preparing for incident response, which were addressed in Chapter 4. The
other controls listed will be addressed in this chapter.
Incident response is a life cycle of stages shown in Figure5.1. We covered
preparation in the last chapter (e.g., establishing the computer incident response
team [CIRT], training the users, and installing the necessary hardware and
software). The next stage, detection/identication, is more difcult to address
because incidents are not always apparent; hence, constant monitoring (using
tools acquired during the prep stage) of the assets is required to detect an
*
Industrial espionage is an attempt to gain access to trade secrets.
Control Name
Impact Level
Low Moderate High
Formal documentation of the IR policy and procedures
✓ ✓ ✓
Incident handling capability to include preparation, detection
and analysis, containment, eradication, and recovery
✓ ✓ ✓
Implement monitoring and documentation of incidents
✓ ✓ ✓
Require incident reporting within a dened time period
✓ ✓ ✓
IR plan that is a road map for response capability and also
describes the structure and organization of the IR capability
✓ ✓ ✓
93Incident Response and Digital Forensics
incident. If an anomaly is detected, the situation is analyzed to conrm that
an incident is occurring. If the incident is conrmed, it needs to be contained
(so as not to infect other parts of the system) and eradicated. And, nally, the
recovery process will bring the system back to working order.
5.2.1 Detection/Identification
In this stage, the monitoring has produced an inconsistency or alarm that
needs to be investigated to determine if an incident actually occurred.
Incidents may also be discovered by a system administrator or even an end
user. In any case, the rst step is to verify that the “incident” is not actually
an error. For example, a user error, a system/software conguration, or a
hardware failure could present itself as an incident. Ways to conrm an
incident include analyzing the technical details such as reports and logs,
interviewing any personnel who may have insight, and reviewing the access
control lists of the network topology (Mandia, Prosise, and Pepe 2003).
If it is concluded upon analysis that the incident is not an error, the type
of incident needs to be determined. There are two types of incidents: (1) a
precursor that an incident is imminent, and (2) an indicator that the incident
is occurring or has occurred (Cichonski et al. 2012). An incident precursor,
for example, could be server entries of a vulnerability scanner, knowledge
of a new mail server exploit, or a directed threat at the organization. Some
possible incident indicators are, for example, IDPS (intrusion, detection, and
prevention systems) or antivirus alerts, a logged conguration change, failed
login attempts, a large quantity of bounced e-mails, or unusual network
trafc. It is not an easy process to validate an incident since an alert can be
a false positive. In order to perform an effective analysis when an incident
occurs, NIST (2012) recommends that the following items be in place in order
to determine the scope of the incident (or precursor) more efciently:
• Have the networks and systems proled for normal use so le
integrity and changes can easily be identied.
Recovery
Preparation
Eradication
Detection/
Identificatio
n
Containment
FIGURE 5.1
Incident response life cycle.
94 What Every Engineer Should Know About Cyber Security
• Understand normal behaviors of networks, systems, and applications
by reviewing log entries and security alerts so that abnormalities
can be easily identied.
• Create a log retention policy to determine how long log data from
rewalls, IDPSs, and applications should be stored. Log data are
helpful in the analysis of an incident.
• Perform event correlation between all of the available logs (e.g., rewall,
IDPS, application) as they all record different aspects of the attack.
• Keep all host clocks synchronized. As was discussed in the last
chapter, it is important during an investigation that all of the logs
show the same time that an attack occurred.
• Maintain a knowledge base of searchable information related to
incidents and the incident response process.
• Use a separate work station for web research on unusual activity.
• Run packet sniffers (congured to specied criteria) to collect
additional network trafc.
• Have a strategy in place to lter the data on categories of indicators
that are of high signicance to the organization’s situation.
• Have plan B in place. If the incident scope is larger than can be
handled by your team, seek assistance from external resources.
Finally, if an incident is a reality and the containment process is started,
make sure that any evidence is documented, a chain of custody of any
evidence collected is maintained, and the incident is reported to the
appropriate ofcials within a dened time period.
5.2.2 Containment
The goal of the containment stage is to minimize the scope and damage
ofthe incident. The containment strategy will depend on certain aspects of
the incident, such as the damage/theft of resources, the need for evidence
preservation, service availability, time and resources available to implement
the strategy, and duration of the solution (Cichonski et al. 2012). For example,
in a DDOS attack, shown in Figure5.2, the attacker is attempting to make
the resource unavailable to the users by a sending a ood of messages from
compromised computers, which the attacker is controlling, to a network.
Essentially, it is more trafc than it can handle, which means it will be
inaccessible to a legitimate user.
These types of attacks can bring your favorite social networking website to
a standstill for hours until the attack on the website stops. One containment
strategy for DDOS is ltering the trafc directed at the victim host and then
locating the machines doing the attacking. This is obviously more easily said
than done because there could be 300 to 400 unique IP addresses doing the
95Incident Response and Digital Forensics
attacking. DDOS attacks are not uncommon. If you think your assets are at
risk for a DDOS, then contracting with a DDOS mitigation rm—before the
attack occurs, of course—may be a good idea. If you are under attack, there
are DDOS mitigation rms that will help, but that is like calling on the heat-
ing, ventilation, and air conditioning service when your air conditioner does
not work during a heat wave.
Containment strategies for other incidents include maintaining a low prole
(so the attacker is not tipped off), avoiding potentially compromised code
(recall in the last chapter that some hackers like to install their own versions of
system utilities), backing up the system (in the event that evidence is needed),
and changing the passwords on any of the compromised systems (FCC 2001).
5.2.3 Eradication
The goal of the eradication phase is to remove the cause of the incident. In
addition to determining the type of attack, the containment phase hopefully
provided insight into how the attack was executed—information that
may help in determining an effective eradication strategy. For example,
eliminating the cause of the incident may involve removing viruses or
deactivating accounts that may have been breached as well as securing the
vulnerability that facilitated the attack. Therefore, a clean backup to reimage
Compromised PC
Compromised PC
Compromised PC
Compromised PC
Compromised PC
Compromised PC
Compromised PC
Compromised PC
Compromised PC
Victim
Attacker
FIGURE 5.2
DDOS attack.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.66.13