NIST SP 800-61
Even though information security professionals plan to effectively manage risk, incidents still occur. NIST SP 800-61 is the National Institute of Standards and Technology (NIST) special publication that gives guidelines for organizations on how to handle security incidents. Read section 2.2 on page 6 to learn more about the need for, and the benefits of, an incident response capability. Also read section 3 on pages 21-44 to learn how to appropriately handle information security incidents. Before you move on, make sure you can explain the four stages of the incident response process: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity.
Handling an Incident
- Acquire tools and resources that may be of value during incident handling. The team will be
more efficient at handling incidents if various tools and resources are already available to them.
Examples include contact lists, encryption software, network diagrams, backup devices, digital
forensic software, and port lists.
- Prevent incidents from occurring by ensuring that networks, systems, and applications are
sufficiently secure. Preventing incidents is beneficial to the organization and also reduces the
workload of the incident response team. Performing periodic risk assessments and reducing the
identified risks to an acceptable level are effective in reducing the number of incidents. Awareness of
security policies and procedures by users, IT staff, and management is also very important.
- Identify precursors and indicators through alerts generated by several types of security
software. Intrusion detection and prevention systems, antivirus software, and file integrity checking
software are valuable for detecting signs of incidents. Each type of software may detect incidents that
the other types of software cannot, so the use of several types of computer security software is highly
recommended. Third – party monitoring services can also be helpful.
- Establish mechanisms for outside parties to report incidents. Outside parties may want to report
incidents to the organization – for example, they may believe that one of the organization's users is
attacking them. Organizations should publish a phone number and email address that outside parties
can use to report such incidents.
- Require a baseline level of logging and auditing on all systems, and a higher baseline level on all
critical systems. Logs from operating systems, services, and applications frequently provide value
during incident analysis, particularly if auditing was enabled. The logs can provide information such
as which accounts were accessed and what actions were performed.
- Profile networks and systems. Profiling measures the characteristics of expected activity levels so
that changes in patterns can be more easily identified. If the profiling process is automated, deviations
from expected activity levels can be detected and reported to administrators quickly, leading to faster
detection of incidents and operational issues.
- Understand the normal behaviors of networks, systems, and applications. Team members who
understand normal behavior should be able to recognize abnormal behavior more easily. This
knowledge can best be gained by reviewing log entries and security alerts; the handlers should
become familiar with the typical data and can investigate the unusual entries to gain more knowledge.
- Create a log retention policy. Information regarding an incident may be recorded in several places.
Creating and implementing a log retention policy that specifies how long log data should be
maintained may be extremely helpful in analysis because older log entries may show reconnaissance
activity or previous instances of similar attacks.
- Perform event correlation. Evidence of an incident may be captured in several logs. Correlating
events among multiple sources can be invaluable in collecting all the available information for an
incident and validating whether the incident occurred.
- Keep all host clocks synchronized. If the devices reporting events have inconsistent clock settings,
event correlation will be more complicated. Clock discrepancies may also cause issues from an
- Maintain and use a knowledge base of information. Handlers need to reference information
quickly during incident analysis; a centralized knowledge base provides a consistent, maintainable
source of information. The knowledge base should include general information, such as data on
precursors and indicators of previous incidents.
- Start recording all information as soon as the team suspects that an incident has occurred.
Every step taken, from the time the incident was detected to its final resolution, should be
documented and timestamped. Information of this nature can serve as evidence in a court of law if
legal prosecution is pursued. Recording the steps performed can also lead to a more efficient,
systematic, and less error-prone handling of the problem.
- Safeguard incident data. It often contains sensitive information regarding such things as
vulnerabilities, security breaches, and users that may have performed inappropriate actions. The team
should ensure that access to incident data is restricted properly, both logically and physically.
- Prioritize handling of the incidents based on the relevant factors. Because of resource limitations,
incidents should not be handled on a first-come, first-served basis. Instead, organizations should
establish written guidelines that outline how quickly the team must respond to the incident and what
actions should be performed, based on relevant factors such as the functional and information impact
of the incident, and the likely recoverability from the incident. This saves time for the incident
handlers and provides a justification to management and system owners for their actions.
Organizations should also establish an escalation process for those instances when the team does not
respond to an incident within the designated time.
- Include provisions regarding incident reporting in the organization's incident response policy.
Organizations should specify which incidents must be reported, when they must be reported, and to
whom. The parties most commonly notified are the CIO, head of information security, local
information security officer, other incident response teams within the organization, and system
- Establish strategies and procedures for containing incidents. It is important to contain incidents
quickly and effectively to limit their business impact. Organizations should define acceptable risks in
containing incidents and develop strategies and procedures accordingly. Containment strategies
should vary based on the type of incident.
- Follow established procedures for evidence gathering and handling. The team should clearly
document how all evidence has been preserved. Evidence should be accounted for at all times. The
team should meet with legal staff and law enforcement agencies to discuss evidence handling, then
develop procedures based on those discussions.
- Capture volatile data from systems as evidence. This includes lists of network connections,
processes, login sessions, open files, network interface configurations, and the contents of memory.
Running carefully chosen commands from trusted media can collect the necessary information
without damaging the system's evidence.
- Obtain system snapshots through full forensic disk images, not file system backups. Disk images
should be made to sanitized write-protectable or write-once media. This process is superior to a file
system backup for investigatory and evidentiary purposes. Imaging is also valuable in that it is much
safer to analyze an image than it is to perform analysis on the original system because the analysis
may inadvertently alter the original.
- Hold lessons learned meetings after major incidents. Lessons learned meetings are extremely helpful in improving security measures and the incident handling process itself.