[Your Company Name]

COMPREHENSIVE VERSION - TEMPLATE

This version is more applicable to Medium-Large Organizations>

INSTRUCTIONS: Make modifications (additions, deletions or edits) to the template to fit your industry sector and to meet your specific business needs. Businesses are advised to consult with their legal counsel (and possibly Human Resources) when completing the information and before issuing a policy/plan. This template is not considered legal advice and should not be intrepreted as such. Within the template, cyan-color highlighting indicates instructions; yellow-color highlighting indicates content that needs to be supplied by your company, in some places optional language/content is supplied and may need to be modified, in other places there is a ‘placeholder’ label. Delete any brackets where company content is added to replace the optional text or placeholders. Be sure to delete all the highlighted instructions before finalizing the document.

Computer Security

Incident Response Plan

Version #___

[Current Revision Date]

[Your Company Name]

Computer Security Incident ResponsePlan

Version #___ ● [Current Version Date]

Document Revision History

Date / Version / Revision Comments / By
07/07/2016 / 0.8 / Created Comprehensive Template for Medium & Large Businesses / Author
mm/dd/yyyy / 0.9 / [Your Company Name] Issued Draft for Review
mm/dd/yyyy / 1.0 / Approved Version Issued

Preface

While this document can be used as a stand-alone policy for [Your Company Name], for business alignment purposes it is intended to be part of a larger Information Security Program. As such, this policy falls within a structure or hierarchy of business and information technology documents, as indicated below.



Table of Contents

Preface

1.Statement of Management Commitment

1.1.Mission, Strategy, & Goals for Incident Response

1.2.Senior Management Approval of Plan

2.Policy

3.Purpose & Objectives of the Plan

3.1.How Incident Response Plan Fits into Overall Organization

4.Scope of the Plan

5.Definitions – Computer Security Incidents and Related Items

5.1.Category Definitions for Priority and Severity Ratings of Incidents

5.1.1.Business Risk Assessment of Information Assets

5.1.2.Information Security Risk Levels

5.1.3.Incident Response Levels

6.Organizational Approach to Incident Response

6.1.Considerations for Creating an Incident Response Team

6.2.Creation of Computer Security Incident Response Team

7.Roles & Responsibilities

7.1.Levels of Authority

7.2.Dependencies Within the Organization

8.CSIRT Communications

8.1.Reporting requirements

8.2.Guidelines for External Information Sharing

9.Standard Operating Procedures for Incident Response

9.1.Incident Management Lifecycle Overview

9.1.1.Preparation Phase

9.1.2.Detection and Analysis Phase

9.1.3.Containment and Recovery Phase

9.1.4.Post-Incident Phase

9.2.Information Sharing

9.2.1.Ad Hoc

9.2.2.Partially Automated

9.2.3.Security Considerations

9.2.4.Granular Information Sharing

10.Incident Response Performance Measures

11.Metrics for Measuring Incident Management Capabilities

12.Roadmap/Plan for Improving Incident Response Capabilities

13.References

Appendix A...... A-

NIST Incident Handling Checklist...... A-

Appendix B...... B-

Sample - Detailed Incident Handling Form...... B-

Appendix C...... C-

Excerpts from SEI’s Incident Management Capability Metrics...... C-

Appendix D...... D-

CSIRT Points of Contact List...... D-

Page 1

[Your Company Name]

Computer Security Incident ResponsePlan

Version #___ ● [Current Version Date]

Computer Security Incident Response Plan

  1. Statement of Management Commitment

By the approval and adoption of this Computer Security Incident Response Plan (the“Plan”), the [Your Company Name] management team have declared their commitment to this critical component of an overall Information Security Program and its importance in the protection of company Information Assets. This Plan is considered a critical component of the company’s overall Business Risk Management Program, to help mitigate risks where possible, and to quickly recover business operations after a computer security incident.

1.1.Mission, Strategy, & Goals for Incident Response

The mission of this Plan is to minimize business impacts caused by computer security incidents, by optimizing the incident response actions to be both effective and efficient.

The strategy of this Plan is to {{Example: utilize a cross-functional pool of staff resources with various skill sets, who have been trained to function as part of the Computer Security Incident Response Team (CSIRT), so that both technical and business operations issues can be quickly addressed during an incident.}}

The goals for this Plan are {{Examples: (1) to identify and train an adequate number of staff from different functional areas to allow for overlapping coverage (a primary and a backup) as members of the CSIRT, (2) to effectively utilize the procedures and processes in this Plan to mitigate business impacts during actual computer security incidents, (3) to assist with conducting drills or assessments to test company incident response capabilities, and (4) to provide valuable feedback into updating Information Security policies, procedures or mechanisms, as a result of the lessons learned after an incident.}}

1.2.Senior Management Approval of Plan

Through the standard process for approval of company operational policies, the [Chief Executive Officer / Company Management Team] has approved this Plan, effective on __{Date}__, including the creation of a Computer Security Incident Response Team with its defined responsibilities.

Signed: ______

Name (Printed): ______

Title: ______

[Remainder of Page Intentionally Left Blank]

  1. Policy

It is the policy of [Your Company Name], that all computer security incidents be promptly addressed using consistent methods to minimize business impacts and other damages to company Information Assets. As part of this policy, [Your Company Name] shall implement an organization-wide Computer Security Incident Response Program which mitigates the risks from computer security incidents by definingstandard operating procedures for responding to incidents effectively and efficiently.

  1. Purpose & Objectives of the Plan

This Plannot only establishes an incident response program, but a primary purpose of the document is detecting, analyzing, prioritizing, and handling incidents to minimize business impacts.

ThisPlan is based on national standards issued by the National Institute of Standards & Technology (NIST), along with national best practices from the Software Engineering Institute (CERT Coordination Center) at Carnegie Mellon University, using the following published documents for guidance:

  • NIST Information Technology Laboratory (ITL) Bulletin, September 2012, Handling Security-Related Incidents (overview of NIST Special Publication 800-61, Rev. 2)
  • NIST Special Publication SP80037, Rev. 1, Guide for Applying the Risk Management Framework to Federal Information Systems
  • NIST Special Publication SP-800-61, Rev. 2, Computer Security Incident Handling Guide
  • NIST Special Publication SP-800-83, Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops
  • NIST Special Publication SP-800-86, Guide to Integrating Forensic Techniques into Incident Response
  • NIST Special Publication SP-800-92, Guide to Computer Security Log Management
  • NIST Special Publication SP-800-94, Guide to Intrusion Detection and Prevention Systems (IDS/IPS)
  • NIST Special Publication SP-800-128, Guide for Security-Focused Configuration Management of Information Systems
  • NIST Special Publication SP-800-137, Information Security Continuous Monitoring (ISCM)
  • NIST Special Publication SP800150 (Draft), Guide to Cyber Threat Information Sharing (Draft)
  • Software Engineering Institute, CERT Program, Carnegie-Mellon University, “Incident Management Capability Metrics Version 0.1”, April 2007

While the NIST standards are mandatory for federal departments and agencies, they should be considered as relevant and will enhance the security posture of those organizations which implement them. In addition, these documents provide valuable resources for CSIRT team members to learn about different aspects of security protective measures and responsive measures.

  1. How Incident Response Plan Fits into Overall Organization

As roles and responsibilities are further defined below, Individuals who are part of the CSIRT are expected to perform not only their normal job functions on a daily basis, but also, during an active response to a Computer Security Incident, to perform the functions defined in this Plan until such incident is resolved. It is likely that not all members of the CSIRT will be actively performing these functions continuously throughout an incident response or all at the same time (at least for certain portions of an incident response); however, all CSIRT members are expected to be adequately trained in incident response activities and available when necessary, excluding valid absences or other extenuating circumstances.

  1. Scope of the Plan

As part of an overall Information Security Program, this Plan applies to:

  • All company IT Resources and Information Assets, regardless of whether they are located within company facilities or in third party service provider facilities, and whether they are managed by company staff or by third party service providers on behalf of [Your Company Name];
  • All Individuals or Users who are authorized to access company IT Resources and Network Services; and
  • All Computer Security Incidents (also referred to as “Cyber Security Incidents”) which may occur, involving company IT Resources or Information Assets.
  1. Definitions – Computer Security Incidents and Related Items

Terms, phrases, abbreviations, and acronyms used in this document are intended to be interpreted as defined below; otherwise, the definition provided in the [Company Information Security Plan] should be used.

“Breach” – means unauthorized access to company’s Computer Equipment, Computer Systems, Email, or Network Services was, or is reasonably believed to have been, acquired or attained by an unauthorized person.

“CND” – Computer Network Defense, including the devices, systems, and processes to protect an organization’s network, using a defense-in-depth approach with layers of security measures and mechanisms. [SEI CERT/CC, “Incident Management Capability Metrics Version 0.1”, April 2007, pp. 135 & 215]

“CSIRT” – Computer Security Incident Response Team, as further defined below in this Plan.

“CSM”[“Continuous Security Monitoring”] – also called “information security continuous monitoring” (previously known as “security continuous monitoring”), is maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. ‘Continuous,’ used in this context, means regular and routine monitoring, sometimes on an hourly basis, as necessary to promptly analyze alerts or alarms from computer security devices to determine their validity, and ‘Ongoing,’ used in this context, means that security controls and organizational risks are assessed and analyzed at a frequency sufficient to support risk-based security decisions to adequately protect organizational information. [NIST SP800137, Sept. 2011, p. 1]

“Event” [“Information Security Event”] – a single occurrence identified in a computer or network system that indicates an attempted or actual breach of information security policies or failure of security mechanisms.

  • An event is any observable occurrence in a system or network. Events include, but are not necessarily limited to, a user connecting to a file share, a server receiving a request for a web page, a user sending email, and a firewall blocking a connection attempt. [NIST SP80061, Rev2, p. 6]
  • Adverse events are events with a negative consequence, such as system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malware that destroys data. This Computer Security IncidentResponse Plan addresses only adverse events that are computer security-related, not those caused by natural disasters, power failures, acts of terrorism (e.g., bombings), etc. [NIST SP80061, Rev2, p. 6]

“IDS” and “IPS” – Intrusion Detection Systems and Intrusion Prevention Systems include hardware devices and software products designed to monitor network and host activity based on either a database of known malware signatures or by using anomaly detection methods to evaluate real-time activity against a baseline of expected, normal activity. An IDS will log suspicious activity, send alerts or notifications to security staff, and has the ability to integrate with firewalls and routers to block potential malware or intrusions. An IPS performs the same functions as an IDS; however, it can also take its own protective actions to block potential attacks. IDS and IPS can be either host-based (monitoring a particular server or network device) or network-based (monitoring traffic on a particular network segment).

“ISCM” [“Information Security Continuous Monitoring”] - is defined as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. This necessitates: (1)Maintaining situational awareness of all systems across the organization; (2)Maintaining an understanding of threats and threat activities; (3)Assessing all security controls; (4)Collecting, correlating, and analyzing security-related information; (5)Providing actionable communication of security status across all tiers of the organization; and (6)Active management of risk by organizational officials. [NIST SP800137, Sept. 2011, p.1]

“Incident” [“Computer Security Incident”] – the occurrence of a single or series of information security events having a high probability of threatening the information security infrastructure and compromising business operations. Further, acomputer security incident is considered a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. Examples of incidents are:

  • An attacker commands a botnet to send high volumes of connection requests to a web server, causing it to crash;
  • Users are tricked into opening a “quarterly report” sent via email that is actually malware; running the tool has infected their computers and established connections with an external host; and
  • A user provides or exposes sensitive information to others through peer-to-peer file sharing services. [NIST SP80061, Rev2, p. 6]

“Individual” – includes any person who is a [Your Company Name] employee, volunteer or agent (i.e., contractor, vendor, etc.), granted access and using some or all of company’s IT Resources.

“Information Assets” – includes information or data relating to the conduct of the public’s business which is prepared, owned, used or retained by [Your Company Name] regardless of physical form or characteristics, including, but not limited to paper, microfilm, microfiche, or any analog or digital format, whether located on internal company Computer Systems or on external systems owned or managed by third party service providers under contract and on behalf of [Your Company Name].

“IT Resources”– means all IT resources owned or leased by [Your Company Name] and any company-paid IT accounts, subscriptions or other technology services. This includes office telephones, wireless/cellular telephones, smart phones, desktop and portable computer systems, printers, facsimile (fax) machines, Internet and World Wide Web (Web) access, internal and external Email, electronic bulletin boards or newsgroups, file transfer protocol (FTP), other wireless systems, and emerging communications systems or devices when implemented by [Your Company Name].

“NIST” – National Institute of Standards & Technology; the organization within the U.S. Department of Commerce responsible for developing and issuing national standards in the area of computer technologies, among other fields; specifically those from their Computer Security Resource Center (

“Security mechanisms” – layers of business processes and roles within [Your Company Name] that have input into the best security practices, procedures and controls, including the use of security technologies, to ensure the desired security of company’s assets.

“SIEM” – Security Information & Event Management [system] includes hardware or software products used for security monitoring, alerting, and notifications. A SIEM usually gathers and aggregates data from all security sensors across network segments or an entire network, including host devices (e.g., servers), to give security staff a broad view (enterprise-wide) of any potential security incidents.

“User” – any Individual who has been granted privileges and access to [Your Company Name] Computer Equipment, Network Services, applications, resources, or information. User is also any person who is identified in the company Information Security Plan.

  1. Category Definitions for Priority and Severity Ratings of Incidents
  2. Business Risk Assessment of Information Assets

In preparation for determining what types and levels of security are needed to protect each Information Asset, as well as setting priority levels for responding to security events involving those assets, there must be a business risk analysis to categorize each Information Asset by its business risk rating. As an example, risk ratings can be assigned after an assessment of each Information Asset against two criteria – (1) how likely or frequently is a security event going to take place, and (2) what is the level or severity of business impact if one does. Both criteria use a scale of “1” being very unlikely or low impact, up to “10” being extremely likely or very high impact, which could be displayed in a matrix format. Examples of high business impacts include loss of revenue, customers’ inability to transact business, damage to company reputation or image, physical damage to property, and loss/theft of confidential or proprietary information.

Using the two-criteria risk analysis, there are three basic categories for setting the incident response priority. All Information Assets with ratings of 5-10 in likelihood combined with 5-10 in business impact, should be considered high risk and require higher levels of security protection, as well as needing a high priority for incident response. Information Assets with a moderate-to-high level of impact (rating 5-10) combined with a low-to-moderate likelihood (1-5), and those Assets with a moderate-to-high likelihood (5-10) combined with a low-to-moderate business impact (1-5) should be considered moderate risk and have adequate security protection, as well as an appropriate priority for incident response. All remaining Information Assets having a low likelihood (1-5) combined with a low business impact (1-5) should be considered as low risk; however, they should still have an adequate level of security protection, even though they will have a lower priority for incident response.

5.1.2.Information Security Risk Levels

Information Security risk levels are different than the business risk levels shownabove. For the purpose of this Incident Response Plan, there are two (2) levels of information security risks: “High” and “Medium.”

  • High risk is defined as a weakness, vulnerability or breach (attempted or actual) discovered in an Internet-facing device or wireless network infrastructure, or unauthorized activity is discovered within the internal network or systems where device compromise, unauthorized access or degraded system performance is likely to occur in a short period of time. A risk will be considered “High” if the potential business impact falls into Priority 1 (Emergency/Urgent) or Priority 2 (High) as defined below.
  • Medium risk is defined as a weakness, vulnerability or breach (attempted or actual) discovered in critical system infrastructure or on systems containing sensitive or confidential information, where the infrastructure is highly susceptible to device compromise or unauthorized access. A risk will be considered “Medium” if the potential business impact falls into Priority 3 (Medium) as defined below.
  • Information security risks which do not fall into one of these two levels are considered low risk and will fall into Priority 4 (Low) as defined below.

5.1.3.Incident Response Levels