Incident Handling and Response Plan

1- Introduction

Per NIST standards, incident response defines monitoring, response, and reporting requirements for incidents that involve security breaches or suspected breaches. Generally, this set of policies require a response to all incidents and suspected incidents within a defined time period, according to a reporting hierarchy that might depend on the severity of the incident.

Security awareness and training both play a role in incident response so that personnel whose primary roles fall outside of information and security know who and where to call, with a service desk or help desk being the first line in the reporting hierarchy. Without timely reporting to the right people, it would be much more difficult to mitigate the risk of a security breach causing harm to your enterprise.

2- Incident Handling and Response

The handling of incidents often needs preparation and must be conducted with professional members who are capable of such tasks. There are plans and procedures to be made and drills to be done to prepare the team. A successful response can prevent the loss of money for an organization in an incident event. When done correctly, it will turn out to be an investment rather than a cost.

An incident is identified by an event that threatens the availability, integrity, or confidentiality of data. Incidents can be cyber-attacks, Denial of Service or Distributed Denial of Service attacks, malicious code execution, etc. Incidents are not only digital events, but natural disasters such as floods and tornados also needed to be handled.

Man-made attacks such as terrorism should be accounted for as well. Handling events cannot be done efficiently without prior planning. Similar to disaster recovery, security incidents must be dealt with proficiently. Planning for incident handling consists of creating a team to take action, with policies and procedures to follow when an incident occurs.

In incident response planning, before an event occurs, the organization should plan and implement an incident handling capability that includes defining the team’s skills, roles, procedures, processes, and tools to respond to incidents.

Small companies may not be able to afford to pay an incident handling team, but they can still have the policies and procedures in place to be carried out by personnel from different departments. Preparing to face an event requires you to spend a good amount of time studying your infrastructure and writing up policies. This is a onetime procedure that requires updating on at least a yearly basis.

Incident responders should be required to regularly train in techniques, tools, and communications. Communications training, including presentation skills, should be maintained in order to keep other staff members and team members updated through internal training.

3- Purpose and Goals of Incident Handling and Response Planning

The purposes of incident response are:

• Restore normal service

• Minimize impact on business

• Ensure service quality and availability are maintained

Three goals of incident handling and response planning are to detect compromises, respond to incidents, and identify the causes as quickly and efficiently as possible.

4- Incident Procedures

The process of responding to an incident consists of several steps. These steps may vary from organization to organization, but a general process is as follows:

Plan for and identify the incident.
Initiate incident handling protocols.
Record the incident.
Evaluate and analyze the incident.
Contain the effects of the incident.
Mitigate and eradicate the negative effects of the incident.
Escalate issues to the proper team member, if applicable.
Recover from the incident.
Review and report the details of the incident.
Draft a lessons-learned report.

5- NIST SP.800-61

It’s important to realize that the handling of an incident cannot be successful without following certain mechanisms. Here are steps to the (IHRP) incident handling and response process on NIST 800-61:

Preparation
Identification/Investigation (determining whether a breach has actually occurred)
- Detection/analysis
- Collection
Containment (limit the damage)
Eradication (involves removing the threat)
Recovery (of repairing a system to its original or better condition, and returning it to production)
Post-incident/ Follow Up
- Lessons learned
- Root cause analysis
Reporting and documentation

The incident response process is not always linear—you can return to other steps if needed. The above mechanism can be applied to any incident, whether it is manmade or natural. It is very important to keep a chain of command during incidents response phases, i.e. how the incident response is escalated, so that operational decisions are reviewed and approved by managers and executives at upper levels when necessary.

6- Incident Response Team

Incident response team: A team that has been designated to receive the information about every incident that can be considered as a threat to assets/processes. The team should be well trained, with an already great technical background; they must be kept aware and trained on any technology that is implemented in the organization. It is important to have a policy that covers your organization’s technology. The incident handling policy should study all aspects and possible incidents that might occur.

The handling team should have a team leader or supervisor who should be there to monitor team member’s actions and to make sure they are following the right procedures. Some mistakes could put team members under liability if things went wrong; Your policy should be accurate enough to not leave any room for liability.

This policy involves making decisions that will have a great influence on the organization operations; Therefore, you must make sure that the management board supports your policy and approves it, and that any updates to the policy are communicated to management and senior directors to approve and support it.

Since incident handling requires your team to recover the business from an incident, it should cooperate heavily with your BC/DR plan. After all, a disaster is an incident by itself, so those two plans should reflect each other on some points. The analysis of all incidents provides input for updating the recovery plans. For cyber-security; organization need to have CSIRT (cybersecurity incident response team), which consists of specialized IT staff that identifies and manages security incidents.

7- Preparation

During preparation, the organization attempts to limit the number of incidents that will occur by selecting and implementing a set of controls based on the results of risk assessments. Preparation looks after measures that are in place to attempt to prevent this type of incident from occurring or to limit the incident impact. For example, searching for, downloading, and updating the software in the incident response toolkit corresponds to preparation, also up-to-date contact lists.

8- Identification

Within identification process, the incident is detected, investigated, and researched. Evaluation involves checking the system and verifying that an incident has occurred. Identifying an incident correctly isn’t an easy task. Taking the necessary time to identify the incident is important.

The time frame to do so is usually short, but rushing into the assumption with not give enough evidence that an incident has taken place or is happening. It might put the organization on the alarm for no good reason. If you suspect that there is an incident, you should notify the necessary people of a potential incident and then keep monitoring to make sure.

When confirming an incident, team members should be notified and accurate information should be given to identifying the type of the incident. Remember, each incident has a different procedure; Therefore, contact information should always be available and updated.

The policy should identify the exact person that needs to be contacted or alarmed during an incident. Learning to detect incidents is essential; Not only to the handling team but also to employees' organization, each in his area of expertise, this would improve employee engagement.

9- Containment

After identifying an incident correctly, the policy should list the actions to be taken, based on the type of incident. Containment deals with isolating the infected system.

For example, you have identified a malware on a system. After alerting the team, the next step should be isolating/disconnecting the system to prevent further infection to other systems and to prevent malware from sending data to an attacker. If an attacker has compromised a system, a shutdown might destroy valuable evidence that could be used for forensics discovery.

If you are using virtualization, another important step would be to clone the system for forensics. If you aren’t using virtualization the alternative is to make multiple copies for forensics and law enforcement as evidence of the attack. Some policies might require you to keep the system as is and monitor the attack to trace it back to the hacker.

10- Eradication

The eradication step may be necessary to restore operational levels for all affected system(s). The threat, infection, or damage must be removed in order to return the system(s) back to operational levels. Eradication is the removal of the problem.

11- Recovery

Recovery is the process of repairing a system to its original or better condition, and returning it to production by applying patches, rebuilding the system's key files, reinstalling applications, changing passwords, and restoring files from backups.

Before you recover the infected system and put it online, you must analyze the attack and identify the vulnerability that allowed the attack.

It would be insanity to rebuild the exact same system with the exact same patches and put it online, only to be hacked in the same way after a few hours. When infected, you should identify the root cause of the attack and patch it. More on that, you need to identify the date of infection; if the infection took place a week ago, you won’t be able to use backups within this time frame because the backups already have the infection in them. It is always preferable to run a security audit on the system after it’s been restored. At this point it is important to coordinate with the system owner to develop a plan for when the system should be back online and serving employees/users.

The handling team can give suggestions and be cooperative, but the decision is up to the system owner. The recovered system should provide the exact functionalities as the old one; You must also make sure that by updating the recovered system, it didn’t lose any functionality that is relied on by users.

When recovering from a backup, use caution. You need to make sure that the backup does not have the infection in it. This is not an easy task, but there are a few tools that can be used here to help. With an Integrity Checker, you can take a snapshot of the infected system and do the same to the recovered one and then compare them to note any changes.

12– Lessons learned

Lessons learned meetings and documents measure the effectiveness of the incident response plan. These are intended to measure how well the plan works and its overall effectiveness in helping to work through the incident handling process. In the root cause analysis meeting, the participants attempt to find the true reason behind the incident.

13- Reporting

After everything has been restored, you must keep monitoring the system to ensure the infection has been completely eradicated and that the attack vector is closed. Create a decent report to explain the incident and the steps taken from the beginning.

The report should be communicated to the Board of Directors or whoever needs to know. Any steps you took that were not in your policy should be added to it. The security policy should also be updated to reflect the changes taken on that system or any changes on the security controls to close the attack vector. The correct information source for the legal department is the incident review report.

14- Incident response contact list

The incident response contact list is an integral part of the incident response plan and requires regular revision. It must be kept up-to-date so that the appropriate members can be engaged as soon as an incident occurs. This contact list is essential because communication is the key when carrying out the plans your organization has developed for incident response. Although your data ownership policy may be useful as a reference in the incident response process, it does not necessarily need to be constantly updated. It only needs to be updated as evolving company policies require.

15- Evidence Integrity

When evidence is to be taken to court, it should remain untouched and unaltered. Any physical evidence should be sealed. It is professional to maintain a proper chain of custody (meaning the who, what, where, and when) of each piece of evidence. For example, which team member is examining the system, what he is doing, any logs or integrity checks, and so on. After these steps, you can start collecting the evidence. This way you make sure that the collected evidence is admissible in court.

Conclusion

Without a proper planning and preparation, a team will not be effective. Take the time to do drills every once in a while to prepare the team. Each team member should know exactly what his or her role and duties are. Finally, nothing will teach more than a real experience. That’s why real incidents are a great way to improve your policies and procedures.

Reference Documents:

Incident Handling and Response Plan

Comments (0)