Best Practices for Security Incident Response
Thursday, July 1, 2004
Picture this scenario: you arrive to work on Monday
morning to find problems on your network. You can't login,
some servers seem to be down, and the phone is going
crazy. You consider the possibility of two causes :
- some fault has occurred and needs fixing
- you network is ( or has been ) under attack
What you do next is critical. Every decision you now make
means a huge difference to the productivity of your
business. This paper presents a short list of what needs
to be done to address this situation : you have a security
problem, it may be malicious hackers, or it could an
entirely accidental problem.
Stay calm.
Its important to stay calm and maintain professionalism throughout the incident.
Do no damage
Make sure that no matter what you do, you do not make the
situation any worse. Take preventative measures such as
taking backups of the affected systems, recording
configuration details, and documenting the current state
of affairs. This is particularly important if there will
be any criminal prosecution arising from the incident in
which case you will need to preserve any evidence of the
criminal activity.
Fully assess the situation
Do not make any changes or corrective actions until you
have fully assessed the situation. Be very careful of
performing knee-jerk actions which can often make the
situation a lot worse.
Identify your team
Handling the incident will be easier if there are two ( or
more ) people working together. For example, one person
can perform corrective actions while the other documents
them and reports back to management. Keep others out of
the way. Be aware of your limitations. Call in experts if
required.
Document everything
This includes every action that is performed, every piece
os evidence, and every conversation with users, system
owners, management, and others regarding the
incident. Include dates and times.
Analyse the evidence to confirm that an incident has occurred
Perform additional analysis and research as
necessary. Make use of Internet search engines and
software documentation to better understand the
evidence. Reach out to other personnel within the
organisation to help.
Notify the appropriate people
This should include the Chief Information Officer ( CIO ),
the head of information security, and the local security
manager. Operations managers and ( to some extent )
technical operations people should also be notified in
case their assistance is required. Use discretion when
discussing details of the incident with others; tell only
the people who need to know and use communication
mechanisms that are reasonably secure. (If the attacker
has compromised Email services, do not send Email about
the incident ).
Stop the incident if it is still in progress
The most common way to do this is to disconnect affected
systems from the network. In some cases, firewall and
router configurations may need to be modified to stop
network traffic that is part of an incident, such as
a denial of service ( DoS ) attack.
Identify the
single most important and immediate problem
Concentrate on resolving this problem. Be aware that there
may be more than one problem - there may be multiple
attackers entering the network, there may be a combination
of hardware faults and malicious attackers.
Preserve evidence from the incident
Make backups ( preferably disk image backups, not file
system backups ) of affected systems. Make copies of log
files that contain evidence related to the incident.
Wipe out all effects of the incident
This effort includes malicious code infections,
inappropriate materials ( eg. pirated software ), Trojan
horse files, and any other changes made to systems by
incidents. If a system has been fully compromised, rebuild
it from scratch or restore it from a known good backup.
Identify and mitigate all vulnerabilities that were exploited
The incident probably occurred by taking advantage of
vulnerabilities in operating systems or applications. It
is critical to identify such vulnerabilities and eliminate
or otherwise mitigate them so that the incident does not
happen again.
Confirm that operations have been restored to normal
Make sure that data, applications, and other services
affected by the incident have been returned to normal
operations.
Create a final report
This report should detail the incident handling
process. It should also provide an executive summary of
what happened and how a formal incident response
capability would have helped to handle the situation,
mitigate the risk, and limit damage more quickly.
Make notes about how your incident response could have been handled better.
Learn from the situation.
