How to draft an incident response policy

September 18, 2017 by

Daniel Dimov

Simultaneously with their growing online presence, companies and individuals become increasingly susceptible to cyber-security attacks. Most organizations prefer to avoid and mitigate the damage caused by such attacks by establishing and implementing information security policies and plans.

When drafting information security policies, one of the crucial elements to consider is an incident response policy. It serves the following purposes: (i) documenting the procedures to be taken by the organization in case of an incident; (ii) ensuring that the incident is systematically handled and communicated; (iii) allowing the quick recovery of the affected core systems; (iv) finding out the cause of the incident; and (v) adopting preventive measures aiming to address future incidents.

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Get Started

To put it simply, the incident response policy deals with the aftermath of an information security incident. It outlines who, where, and how should respond to the incident. In case an organization lacks an incident response policy, a response to an incident may be delayed, and the evidence indicating the cause of the incident can be permanently deleted. This, in turn, will increase the impact of the incident and prevent the organization from addressing similar incidents in the future.

Drafting an effective incident response policy requires substantial planning and resources. In this article, we provide a general description of an incident response policy (Section 2), discuss the incident phases which it must address (Section 3), its main elements (Section 4), and give some tips on how to make it more efficient (Section 5). We conclude by providing a brief summary of this article (Section 6).

What is an incident response policy?

An incident response policy is a plan outlying organization's response to an information security incident. Such a policy usually contains information about: (i) the composition of the incident response team within the organization; (ii) the role of each of the team members; (iii) the persons responsible for testing the policy; (iv) how to put the policy into action; and (v) the technological means, tools, and resources that will be used to identify and recover compromised data.

Incidents phases which an incident response policy must address

Organizations willing to draft effective incident response policies need to address the following incident phases:

1. Preparation phase: how the users of a system and the IT professionals responsible for it are trained and prepared to respond to security incidents. This phase should include not only identifying tools and resources that can be of significant value during an incident, but also the adoption of preventive measures, such as conducting periodic risk assessments and increasing user awareness.
2. Identification phase: recognizing and detecting a security incident and determining the severity and the priority level of the detected incident. This phase includes: (i) recognizing incidents that use common attack vectors (e.g., attacks through removable media, the Web, and e-mail); (ii) recognizing signs of incidents; (iii) finding detectable precursors; (iv) performing initial analysis and validation through file integrity checking; (v) running packet sniffers; (vi) filtering data; and (vii) evidence preservation.
3. Containment phase: guidance on how to isolate systems that have been affected by the attack to prevent damaging other systems.
4. Eradication phase: searching for the cause of the incident and eliminating the affected systems.
5. Recovery phase: returning affected systems to their normal operational environment.
6. Post-incident phase: documenting the entire incident, conducting a thorough investigation, detecting the cause of the incident, calculating associated costs, and drafting a strategy aiming to prevent similar incidents.

Elements of an incident response policy

An incident response policy should be drafted carefully and include the following main components:

1. Identification of an incident response team

Irrespective of their type, incident response teams may comprise either organization's employees only or be outsourced partially or fully. The team description should include names, contact information, roles, and responsibilities of team members. For the sake of clarity, it is important to define and describe in detail the roles which each of the members will play in a case of an incident. Furthermore, it is essential for the organization to ensure that the members are not only mentioned in the document but also properly trained to perform their roles and responsibilities effectively. Therefore, the incident response policy should also indicate the number of trainings undertaken by each member of the response team.

The responsibilities of an incident handler (i.e., a person who serves as a security contact, has admin credentials and technical knowledge about information security incidents) and a resource manager (i.e., an individual who serves as a local authority and assesses the business impact of system's unavailability) should be distinguished separately.

2. Information about the system

The policy should include system details, such as network and data flow diagrams, hardware inventory, and logging data.

3. Incident handling and reporting procedures

The chapter governing incident handling and reporting procedures should include requirements for completing an incident intake report. The intake report needs to contain information about a contact person, the IP address and the physical location of the breached system, types of affected data, and a detailed description of compromised files containing personal or sensitive information. The actions being taken on the breached system should be documented in the intake report to serve for forensic analysis. Such documentation needs to take into consideration the following factors: the status of the incident, the summary of the incident, actions taken, chain of custody, impact assessments, contact information of the involved parties, a list of gathered evidence, and next steps to be taken.

4. "Lessons Learned"

An important aspect that is often omitted in an incident response policy is the "Lessons Learned" section. Using a meeting and a discussion among all parties involved, such "Lessons Learned" initiative may serve as a helpful tool in improving security measures in the organization and the incident handling process itself. Questions, such as "How well and adequately did staff and management perform when dealing with the incident?" "What information was needed sooner?", moreover, "What corrective actions can prevent similar incidents in the future?", may be a starting point to such a discussion.

5. Reporting to outside parties

An incident response policy may include timeframes and guidelines for reporting to third parties, e.g., reporting to IT personnel, security analysts, data protection or law enforcement authorities, media, affected external parties, and software, vendors. Depending on a jurisdiction, incident reporting may be required by law.

Tips on drafting an incident response policy

The below-mentioned tips can be useful when drafting an incident response policy.

1. Make it flexible

An incident response policy should be revised regularly to ensure that the document is up to date, includes relevant employees and outside parties, and responds to the newest trends in cybersecurity. Also, the definitions in the document should be broad enough to encompass all incident situations. Thus, if the document needs to be revised to address new security challenges, it will not be necessary to revise the definitions.

2. Ensure cooperation between organization's departments and staff

Successful drafting and implementation of an incident response policy requires close inter-organizational collaboration, especially in larger organizations. For example, handling a breach that has resulted in a loss of credit card data may require involvement not only of security experts for addressing software issues, but also PR specialists for drafting a public disclosure of the incident and customer support staff for discussing the breach with customers. Such an involvement should be initiated during the phase of policy planning, and not only during its implementation. Stakeholders that should be engaged in the planning process may include internal and external IT, management, legal, and public relations teams.

3. Assess performance

The effectiveness of incident response procedures can be evaluated by using both quantitative and qualitative performance indicators. The time required for detecting, handling, investigating, and reporting an incident can be used as a quantitative indicator. The feedback provided by the members of the response team can serve as a qualitative indicator.

4. Do not forget testing

Simulating a breach may not only test the efficiency of an incident response policy but also contribute to identifying parts of the policy which need to be updated.

Conclusion

An incident response policy, especially if drafted comprehensively and tested in advance, is an organization's most important shield against cyber-attacks. Organizations that rely a great extent on the Internet, computer networks, and deal with a vast amount of personal data can benefit a lot from investing in well-drafted incident response policies. This article discussed the key recommendations for drafting such policies.

To summarize, incident response policies should address the following aspects of detecting an incident and responding to it: (1) appointing an incident response team comprised of internal and external stakeholders and their precise roles in handling of an incident; (2) technical information about the pre-incident status of organization's informational infrastructure; (3) definition and classification (ranking) of information security incidents within the organization; (4) detailed incident handling and responding procedures; (6) organizing a "Lessons learned" session; and (7) reporting to outside parties.

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Get Started

Irrespective of how well-written an incident response policy is, organizations should remain aware that, in the field of cyber-security, the strongest weapon remains prevention, which includes initial risk assessment, host and network security, malware prevention, and user awareness training.

Sources

• Crafting the InfoSec Playbook: Security Monitoring and Incident Response Master Plan', O'Reilly Media, Inc., 2015.
• Computer Security Incident Handling Guide'-NIST
• Doherty, E., 'Digital Forensics for Handheld Devices', CRC Press, 2016.
• Drinkwater, D., '10 steps for a successful incident response plan', 26 June 2017, CSO Online. 
• Fowler, K., 'Data Breach Preparation and Response: Breaches are Certain, Impact is Not', Syngress, 2016.
• Greene, S., 'Security Program and Policies: Principles and Practices', Pearson IT Certification, 2014.
• US National Cyber Security Strategy and Programs Handbook Volume 1 Strategic Information and Developments
• Johnson, L., 'Computer Incident Response and Forensics Team Management: Conducting a Successful Incident Response
• 'Incident Response Planning Guideline', Berkeley. 
• Landoll, D., 'Information Security Policies, Procedures, and Standards: A Practitioner's Reference', 2016.
• Nayak, U., Rao, U., 'The InfoSec Handbook: An Introduction to Information Security', Apress, 2014.
• Shultz, E., Shumway, R., 'Incident Response: A Strategic Guide to Handling System and Network Security Breaches
• Whitman, M., 'Principles of Incident Response and Disaster Recovery', Cengage Learning, 2013.
• Whitman, M., Mattord, H., 'Roadmap to Information Security: For IT and Infosec Managers', Cengage Learning, 2012.
• Williams, B., 'Information Security Policy Development for Compliance: ISO/IEC 27001, NIST SP 800-53, HIPAA Standard, PCI DSS V2.0, and AUP V5.0', CRC Press, 2013.

Co-Author

  Rasa Juzenaite works as a project manager at Dimov Internet Law Consulting   (www.dimov.pro), a legal consultancy based in Belgium. She has a background in digital  culture with a focus on digital humanities, social media, and digitization. Currently, she is pursuing an advanced Master's degree in IP & ICT Law.