ITS 4350 - Disaster Recovery
Chapter 7, Incident Response: Response Strategies
This lesson is about chapter 7. Objectives important to this
- DoS incidents
- Unauthorized access
- Inappropriate use
This chapter begins with a horror story about a
student testing a worm
program. Read through it and think about the questions at the end of
the chapter. Who is responsible for the outbreak that has now happened?
What should have been done to prevent it? This is an example of what
Albert Einstein, Hans ěrsted, Ernst Mach, and others, called a Gedankenexperiment. (Nouns in German
are capitalized, even when mixed with English. It means mind/thought
experiment.) This is the way such an experiment (the article) should be
done because the consequences of carrying it out in the real world are
unacceptable. You could argue that the student in this case carried out
his thought experiment first, then found that the real world results
were not what he expected. That is the danger in doing thought
experiments: you may not know
enough yet to predict the actual results.
On pages 269 and 270, the text makes a case for gathering information while you are
investigating a problem, getting everything you can, then analyzing it to make a plan for containment, eradication, and recovery. The analysis and planning
stage is where the Gedankenexperimenting takes place. Note that these
actions are numbered steps in the chart on page 271, but there is no
explanation of what one is supposed to do. Thankfully, some thoughts follow the chart.
The text explains that containment
methods vary depending on what is happening.
- Is it spreading from devices on our network? Shut them
down, and pull them off the network.
- Is it coming at us from the Internet? Break the connection
to the Internet, identify the source and add firewall rules if
possible. Can we identify IP addresses that are sending the bad
traffic? Blocking those addresses may help. This is especially useful
for DDoS attacks.
requires repair of the damage done, and removal of the various viruses,
worms, altered files, and other kinds of mess left by the attacker. The
text reminds us that a particularly nasty attacker may decide to leave
behind software that will cause more damage after the initial attack
has ended. If, on the other hand, the attacker intends to return, there
is more likely to be a new back door to the system, created by the
attacker to make it easy to re-enter the new favorite data source.
Finding new accounts with elevated rights should make your admins
wonder what else has been changed about the system.
Recovery, as usual,
means restoring the state the system was in before the incident.
However, in the case of an attack, the system should be better than
before by being guarded against that specific attack. Recovery may mean
restoration of data, reinstallation of operating systems and programs,
and may also include changing any compromised attack surfaces.
This leads to another issue. The text presents a story about a software and hardware business that was hacked,
resulting in the theft of customer account information including credit
card numbers. The people running the business chose to send a series of
letters to customers, each worse than the last, describing the loss and
how large a segment of the customer database was compromised. The
current law about this sort of thing is to tell
the customers the truth, not to hold back the bad news. Stolen records
are never recovered, so there was no reason to expect the situation to
get better by waiting to tell the customers their data had been
The text moves on to consider handling an incident. It is the second
text this term that has discussed security incidents in terms of four
categories, and a fifth that is a combination of the other four:
- Denial of Service attack
- Malware attack
- Unauthorized access
- Inappropriate usage
- Hybrid attack, having the characteristics of two or more of the types above
The text presents a discussion of handling each of the four major types. The advice here is more informative.
For a DoS attack:
- Coordinate with your ISP. If you are under a denial of service attack, so is your Internet Service Provider.
- Watch for deviations in your normal network traffic to detect the attack sooner.
- Use packet filters to drop traffic that makes no sense for your network.
- Filter based on the characteristics of the actual attack once it begins.
For a Malware attack:
- Warn your users about malware that has been reported by protection vendors. If they have seen it recently, you may see it, too.
- Filter spam out of email. Remind users not to run programs attached to email.
- Check for antivirus solutions from your own vendor and others.
- Scan your systems for open ports that you have not opened
yourself. It could indicate a malware program that has opened the port
for its evil purposes.
- Audit processes running on your servers.
For Unauthorized access:
- Note the examples on pages 288 and 289, which give us behaviors to watch for.
- Require passwords with increased complexity, and with shorter lifespans.
- Run regular vulnerability scans and take action on the findings.
- Deny all traffic that is not permitted by a valid rule.
- During the attack, disable compromised accounts and ports that are associated with the attack.
For Inappropriate use:
- This can run from the completely innocent use of company
equipment to the intentional misuse of it for malevolent purposes. Use
restraint in applying discipline.
- Educate your users about appropriate and inappropriate use
for every kind of new equipment. Remind staff about appropriate use of
old equipment from time to time.
- Collect evidence and take action that is appropriate to the level of the offense.
The text closes the chapter with a recommendation to use automated detection
and automated response systems. A technical control that kicks in
sooner than a live administrator could act can save a lot of your