The National Institute of Standards and Technology (NIST) published the Computer Security Incident Handling Guide...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
800-61 v2 in August 2012. It provides guidance for incident handling, particularly for analyzing incident-related data and determining the appropriate response to each incident. It takes a pragmatic approach to incident handling. It is adaptive and flexible so it can be applied to small and medium-sized businesses (SMB) or large enterprise environments.
The NIST Incident Handling process introduces four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Each of these phases is iterative in nature. When a security incident occurs, rather than reactively jumping into its remediation and expending a considerable amount of time, cost and resources for identification, containment and recovery, the NIST incident response guide suggests that being prepared for such incidents is the best defense.
Security incidents happen: Be prepared
Not all security incidents are equal, and defenses against potential incidents should be considered based on the impact they could have on an organization, the likelihood of them occurring and the criticality of the assets affected. This is typically determined by a formal risk assessment that can identify potential IT vulnerabilities so an organization can implement proper protection and prevention countermeasures.
Once an enterprise has determined its risk appetite and has identified higher-level risk environments, it should then develop an incident response plan (IRP) and a Computer Security Incident Response Team (CSIRT) to manage each of the NIST phases. The CSIRT will maintain the IRP current, ensure the CSIRT members are knowledgeable in the IRP, and the IRP is periodically tested and approved by management. Each of these tasks is critical to ensure the enterprise is prepared when an incident occurs that would otherwise cause great harm to its finances, operations and reputation.
Security incident detection and analysis
Detection includes alerts and notifications, but it also includes periodic or continuous monitoring and follow-up. Many organizations say the expense and effort of monitoring, detection and analysis far outweighs the risk, and since they have never had a breach, those defenses needs to take a back seat to other, more critical projects. That could very well be true, but experience shows there are instances when an enterprise becomes aware of a data breach or attack only to later find out that it has been occurring for several months or longer. For example, in the cases of Target and Home Depot, it was found that hackers had been stealing critical information months before they were identified.
The importance of incident analysis of cannot be overemphasized. It will help identify the source, extent, impact and details of the breach. Without proper analysis, it will be difficult to enter the next phase.
Containment, eradication and recovery
Without preparation, this is typically the first phase that is acted upon. Enterprises react to an incident, contain the problem, eliminate it and attempt to restore the system to the state prior to the incident. This can be time-consuming, disruptive and costly. It will take time to identify the incident -- if it's a breach or malware attack, for example. As security engineers work toward identifying the extent of the breach, users may not be able to do business as usual. This can be costly and could result in revenue losses.
Once identified, the breach needs to be contained and eradicated. This remediation effort might require additional downtime. After remediation, all affected systems need to be restored to the state and condition they were in before the breach. Proper planning for breaches and disruptive security breaches will greatly reduce the cost, time and effort required for this phase.
Post-incident activity: Lessons learned
When the incident has been contained and remediated, and operations have normalized, the post-mortem should focus on lessons learned. Ask questions like how did this incident occur? How can it be prevented from reoccurring? What preventive measures can be strengthened? How can monitoring and alerting processes be improved for more timely notifications? How can the containment, remediation and recovery processes be better streamlined to minimize downtime and disruptive behavior? How can management ensure that the incident and others like it have not negatively impacted the business?
NIST incident response: Defense in depth
Preventive controls are most effective if placed at the closest point of entry as possible. However, multiple security countermeasures should be deployed in different stages of access flows. In information security, this is called defense in depth. Analysis and monitoring of these controls should be continuous. Based on proper preparation and insightful planning, when another incident occurs -- not if another occurs -- the enterprise can bounce back quickly with minimal interruption.
Lastly, it is essential to communicate the IRP, IRP tests results and possible breaches to executive management in a clear non-technical fashion. This will give management confidence in the information security group to continue to stand fast and stand competent.
About the author:
Miguel (Mike) O. Villegas is vice president for K3DES LLC, a payment and technology-consulting firm. Mike has been a CISO for a large online retailer, partner for a "Big Four" consulting firm, VP of IT Risk Management, IT Audit Director for large commercial banks and owner of an information security professionals firm over a span of 30 years.
Find out how to comply with the changes in the NIST incident response guideline.
Incident response management can be tough. Learn how to use NIST SP 800-61 as a baseline for a successful strategy.