- Email: info@clearinfosec.com
- 1800 760 5656
Computer security incident response is a very important component of information technology programs. Because performing incident response effectively is a complex and time-consuming task, establishing a successful incident response capability requires substantial planning and resources. The NIST Computer Security Incident Handling Guide provides in-depth guidelines on how to build an incident response capability within an organization.
So, in this blog, we will talk about steps defined by NIST to approach Security Incidents Handling. The NIST incident response lifecycle breaks incident response down into four main steps: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity
Now, let’s take a look at each step individually.
NIST’s Incident response methodologies typically emphasize the preparation part by giving many guidelines for establishing an incident response capability so that the organization is ready to respond to incidents when needed. Along with that it also emphasizes preventing incidents by ensuring that systems, networks, and applications are sufficiently secure.
The below image provides the starting point that is very useful during the preparation of incident handling.
Keeping the number of incidents sensibly low is vital to secure and protect the business processes of the organization. Incident response teams are generally not responsible for securing resources, but they may be able to identify problems that the organization is not mindful of. This can be very significant for risk assessment as it helps to identify gaps.
The National Software Reference Library (NSRL) Project maintains records of hashes of various files, including operating system, application, and graphic image files. The hashes can be downloaded from http://www.nsrl.nist.gov/.
The most challenging part of the incident response process is accurately detecting and assessing possible incidents. To make it more manageable we can look into signs of an incident.
Once an incident is detected, every organization should have step-by-step instructions to be prepared to handle any incident. Incident can happen in countless ways, but some common attack vectors are covered here, which can be a starting point in the development of specific handling procedures.
When an alert is suggesting that an incident has occurred, the team should rapidly perform an initial analysis to determine the incident’s scope. Performing the initial analysis and validation is very challenging, so we have covered some basic recommendations.
Immediately after an incident is suspected, it should be documented properly.
The most critical decision point in the incident handling process is to Prioritize how an incident handling will take place. According to NIST, Incidents should not be handled on a first-come, first-served basis, because it will result in resource limitations. Instead, it should be prioritized based on the relevant factors, such as the following:
When an incident is analyzed and prioritized, the incident response team needs to notify the appropriate people so that all who need to be involved will play their roles. The exact reporting requirements can vary in every organization, but we have a list of people that are generally notified.
3.Containment, Eradication, and Recovery:
Once an incident is detected, it can easily overwhelm resources and that may increase damage. That’s where containment comes, as it provides time for developing a step-by-step remediation strategy. An essential part of containment is decision-making (for example, which system to shut down, which system should be disconnected from a network, which functions should be disabled for how much time etc…).
After an incident has been contained, Eradication and recovery should be done in a phase because at that time all the remediation steps need to be prioritized. For large-scale incidents, recovery may take several weeks to months. So, the early phases of recovery should only be focused on increasing the overall security with relatively quick (days to weeks) high-value changes to prevent future incidents.
4.Post-Incident Activity :
The last part of the NIST incident response methodology is learning from previous incidents to improve the process. So after remediating an incident, the organization should take steps to identify and implement any lessons learned from that incident.
Lessons learned activities should produce a set of objective and subjective data regarding each incident. Over time, the collected incident data can be useful in identifying security weaknesses and threats, as well as changes in incident trends. This data can also help develop the risk assessment process, which all can help in the determination and execution of extra controls.
The checklist provided the following covers the major steps to be performed in the handling of an incident. Actual steps performed may vary based on the type of incident and the nature of individual incidents, but this can be taken as a guideline provided by NIST.
The key recommendations presented in the NIST document for handling incidents are summarized below.
89 Comments
Comments are closed.