res.cloudinary.com · Web viewIt is the policy of [Your Company Name], that all computer security...

[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 SECURITYINCIDENT RESPONSE PLAN

Version #___[Current Revision Date]

[Your Company Name]Computer Security Incident Response Plan

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

Page i

NOTE: This Computer Security Incident Response Policy & Plan template was created for the purpose of assisting Small/Medium Businesses (SMBs) in being better prepared for handling a cybersecurity incident,

using current best practices. There are two templates – one comprehensive version for medium and larger businesses, and one short version for smaller businesses. The templates are a work-in-progress, and as

changes are made, new versions of the templates will be released. The templates are not copyrighted and are to be made available free of charge to anyone who wants to use them, in their entirety or using any

section or subsection, and without the need for any attribution as to the source. The templates are provided AS-IS, without any warranty of fitness for any particular purpose, business or industry, or of their

applicability to any specific business circumstances. Organizations are advised and strongly encouraged to consult and work with their legal counsel (and Human Resources) on the

completion of any policy or plan using the templates. This template should not be taken or interpreted as providing any legal advice, and is no substitute for contacting appropriate legal

counsel.



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.

Page ii



Table of Contents

Preface........................................................................................................................ ii1. Statement of Management Commitment............................................................1

1.1. Mission, Strategy, & Goals for Incident Response..........................................11.2. Senior Management Approval of Plan............................................................2

2. Policy...................................................................................................................33. Purpose & Objectives of the Plan.........................................................................3

3.1. How Incident Response Plan Fits into Overall Organization...........................44. Scope of the Plan.................................................................................................45. Definitions – Computer Security Incidents and Related Items.............................5

5.1. Category Definitions for Priority and Severity Ratings of Incidents................75.1.1. Business Risk Assessment of Information Assets....................................75.1.2. Information Security Risk Levels..............................................................85.1.3. Incident Response Levels........................................................................9

6. Organizational Approach to Incident Response...................................................96.1. Considerations for Creating an Incident Response Team...............................96.2. Creation of Computer Security Incident Response Team.............................12

7. Roles & Responsibilities.....................................................................................137.1. Levels of Authority.......................................................................................137.2. Dependencies Within the Organization........................................................14

8. CSIRT Communications......................................................................................158.1. Reporting requirements...............................................................................158.2. Guidelines for External Information Sharing................................................16

9. Standard Operating Procedures for Incident Response.....................................199.1. Incident Management Lifecycle Overview....................................................19

9.1.1. Preparation Phase..................................................................................199.1.2. Detection and Analysis Phase................................................................209.1.3. Containment and Recovery Phase.........................................................229.1.4. Post-Incident Phase...............................................................................24

9.2. Information Sharing.....................................................................................279.2.1. Ad Hoc...................................................................................................289.2.2. Partially Automated...............................................................................289.2.3. Security Considerations.........................................................................299.2.4. Granular Information Sharing................................................................29

Page iii



10. Incident Response Performance Measures......................................................3111. Metrics for Measuring Incident Management Capabilities...............................3212. Roadmap/Plan for Improving Incident Response Capabilities.........................3513. References......................................................................................................35Appendix A..............................................................................................................A-1

NIST Incident Handling Checklist.........................................................................A-1Appendix B..............................................................................................................B-1

Sample - Detailed Incident Handling Form..........................................................B-1Appendix C..............................................................................................................C-1

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

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

Page iv



COMPUTER SECURITY INCIDENT RESPONSE PLAN

1. Statement of Management CommitmentBy 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 ResponseThe 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.}}

Page 1



1.2. Senior Management Approval of PlanThrough 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]

Page 2



2. PolicyIt 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 defining standard operating procedures for responding to incidents effectively and efficiently.

3. Purpose & Objectives of the PlanThis Plan not only establishes an incident response program, but a primary purpose of the document is detecting, analyzing, prioritizing, and handling incidents to minimize business impacts.

This Plan 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)

o http://csrc.nist.gov/publications/nistbul/itlbul2012_09.pdf NIST Special Publication SP-800-37, Rev. 1, Guide for Applying the

Risk Management Framework to Federal Information Systemso http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-

Final.pdf NIST Special Publication SP-800-61, Rev. 2, Computer Security

Incident Handling Guideo http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-

61r2.pdf NIST Special Publication SP-800-83, Rev. 1, Guide to Malware

Incident Prevention and Handling for Desktops and Laptopso http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-

83r1.pdf NIST Special Publication SP-800-86, Guide to Integrating Forensic

Techniques into Incident Responseo http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf

NIST Special Publication SP-800-92, Guide to Computer Security Log Management

o http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf

Page 3

http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf


http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-83r1.pdf




http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf


http://csrc.nist.gov/publications/nistbul/itlbul2012_09.pdf



NIST Special Publication SP-800-94, Guide to Intrusion Detection and Prevention Systems (IDS/IPS)

o http://csrc.nist.gov/publications/nistpubs/800-94/SP800-94.pdf NIST Special Publication SP-800-128, Guide for Security-Focused

Configuration Management of Information Systemso http://csrc.nist.gov/publications/nistpubs/800-128/sp800-128.pdf

NIST Special Publication SP-800-137, Information Security Continuous Monitoring (ISCM)

o http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137- Final.pdf

NIST Special Publication SP-800-150 (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

o http://resources.sei.cmu.edu/library/asset-view.cfm? assetid=8379

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.

3.1. How Incident Response Plan Fits into Overall OrganizationAs 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.

4. Scope of the PlanAs 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

Page 4

http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8379

http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8379



http://csrc.nist.gov/publications/nistpubs/800-128/sp800-128.pdf




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.

5. 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 SP-800-137, 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.

Page 5



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 SP-800-61, Rev-2, 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 Incident Response 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 SP-800-61, Rev-2, 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 SP-800-137, 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, a computer 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:

Page 6



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 SP-800-61, Rev-2, 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 (http://csrc.nist.gov/).

“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

Page 7

http://csrc.nist.gov/



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.

5.1. Category Definitions for Priority and Severity Ratings of Incidents

5.1.1.Business Risk Assessment of Information AssetsIn 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.

Page 8



5.1.2. Information Security Risk LevelsInformation Security risk levels are different than the business risk levels shown above. 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 LevelsThere are four (4) priority levels for security incidents, which are based on the degree of business criticality and importance to [Your Company Name] for the related information or communications systems. These priority levels roughly coincide with the business risk ratings indicated above; although, even an attack against an Information Asset with a Level 1 (low) business risk rating should be addressed through these Incident Response procedures to eliminate or mitigate future threats. These Incident Priority Levels are defined as follows:

Priority #1 - Emergency/Urgent: An Incident has caused a complete and immediate work stoppage affecting at least one primary business process or a broad group of End Users (such as an entire department, building, floor, branch, line of business or external customer). No workaround is available.

Page 9



Priority #2 - High: An Incident has affected a business process in such a way that business functions (operations) are severely degraded, multiple End Users are impacted or key external customer is affected. A workaround may be available, but it is not easily sustainable.

Priority #3 - Medium: An Incident has affected a business process in such a way that certain business functions are not available to End Users or external customers, or a system or service is degraded. A workaround may be available.

Priority #4 - Low: An Incident has little or no effect on business processes or operations and can be handled on a scheduled basis (e.g., preventive maintenance). A workaround is available.

6. Organizational Approach to Incident Response6.1. Considerations for Creating an Incident Response Team

NIST defines several possible structures for an incident response team, including the following: [NIST SP-800-61, Rev-2, pp. 13-15]

Central Incident Response Team – A single incident response team handles incidents throughout the organization. This model is generally effective for small organizations and those with minimal geographic diversity in terms of computing resources.

Distributed Incident Response Teams – The organization has multiple incident response teams, each responsible for a particular logical or physical segment of the organization. This model is effective for large organizations (e.g., one team per division) and for organizations with major computing resources at distant locations (e.g., one team per geographic region, one team per major facility). However, the distributed teams should be part of a single centrally coordinated entity, so that the incident response process is consistent across the organization and information is shared among teams. This is particularly important because multiple teams may see different components of the same incident or may handle similar incidents.

Coordinating Team – A primary incident response team provides advice to other teams without having authority over those teams; for example, a core, centralized team may assist smaller, decentralized division/unit teams.

Page 10



NIST further provides three staffing models for Incident Response Teams:

Internal Employees - The organization performs all of its incident response work, with limited technical and administrative support from contractors.

Partially Outsourced – The organization maintains some internal incident response capabilities and outsources portions of its incident response work. NIST provides detailed options for this type of response model; however, two of the most common practices are:

o The most prevalent arrangement is for the organization to outsource continuous (24/7/365) monitoring of intrusion detection sensors, firewalls, and other security devices to an offsite managed security services provider (MSSP). The MSSP identifies and analyzes suspicious activity and reports each detected incident to the organization’s incident response team.

o Some organizations perform basic incident response work in-house and call on contractors to assist with handling some incidents, particularly those that are more serious or widespread, or require specialties such as digital forensics.

Fully Outsourced – The organization completely outsources its incident response work, typically to an onsite contractor. This model is most likely to be used when the organization needs a full-time, onsite incident response team but does not have sufficient qualified employees to meet requirements. It is assumed that the organization will have employees supervising and overseeing the outsourcer’s work.

Finally, NIST provides these additional factors which should be considered when creating a CSIRT:

The Need for 24/7 Availability – Most organizations need incident response staff to be available 24/7. This typically means that incident handlers can be contacted by phone, but it can also mean that an onsite presence is required. Real-time availability is the best for incident response because the longer an incident lasts, the more potential there is for damage and loss. Real-time contact is often needed when working with other organizations—for example, tracing an attack back to its source.

Full-Time Versus Part-Time Team Members – Organizations with limited funding, staffing, or incident response needs may have only part-time incident response team members, serving as more of a virtual incident response team. In this case, the incident response

Page 11



team can be thought of as a volunteer fire department. When an emergency occurs, the team members are contacted rapidly, and those who can assist do so. An existing group such as the IT help desk can act as a first Point of Contact (POC) for incident reporting. The help desk members can be trained to perform the initial investigation and data gathering and then alert the incident response team if it appears that a serious incident has occurred.

Employee Morale – Incident response work is very stressful, as are the on-call responsibilities of most team members. This combination makes it easy for incident response team members to become overly stressed. Many organizations will also struggle to find willing, available, experienced, and properly skilled people to participate, particularly in 24-hour support. Segregating roles, particularly reducing the amount of administrative work that team members are responsible for performing, can be a significant boost to morale.

Cost – Cost is a major factor, especially if employees are required to be onsite 24/7. Organizations may fail to include incident response-specific costs in budgets, such as sufficient funding for training and maintaining skills. Because the incident response team works with so many facets of IT, its members need much broader knowledge than most IT staff members. They must also understand how to use the tools of incident response, such as digital forensics software. Other costs that may be overlooked are physical security for the team’s work areas and communications mechanisms.

Staff Expertise – Incident handling requires specialized knowledge and experience in several technical areas; the breadth and depth of knowledge required varies based on the severity of the organization’s risks. Outsourcers may possess deeper knowledge of intrusion detection, forensics, vulnerabilities, exploits, and other aspects of security than employees of the organization. Also, MSSPs may be able to correlate events among customers so that they can identify new threats more quickly than any individual customer could. However, technical staff members within the organization usually have much better knowledge of the organization’s environment than an outsourcer would, which can be beneficial in identifying false positives associated with organization-specific behavior and the criticality of targets.

6.2. Creation of Computer Security Incident Response TeamIt is the intent of [Your Company Name] executive leadership to take best advantage of skilled internal resources in the creation of a company Computer Security Incident Response Team (CSIRT). {{Optional, if

Page 12



applicable: Leadership also took into account the company’s dependence on external IT contractors for several critical services which are integral parts of the company’s overall IT environment. As such, the CSIRT necessarily includes key members from external service providers to work alongside company staff, to create a hybrid CSIRT.}} To meet one of the goals of this Plan, the intent is to designate one primary member and one alternate member from each identified functional area, to allow for backup coverage on the CSIRT in case one of the members is not available. Both the primary and alternate CSIRT members should receive the same level of training in Incident Response procedures. Because CSIRT members will potentially have access to system-level data and information, which may include Sensitive or Confidential Information (such as, handling a breach where personal information has been exposed), each CSIRT member must be cleared through a background check process that would permit them that level of access.

The CSIRT will consist of the following individuals or named representatives from the functional areas (which may include an external IT service provider):

Chief Information Security Officer (CISO) [or equivalent manager over information security functions] & designated alternate

Information Security Team – primary & alternate Network Operations – primary & alternate Data Center Operations – primary & alternate {{If applicable: Company’s Privacy Officer – primary & alternate}} {{If applicable: Company’s Risk Management Unit – primary &

alternate}} {{If applicable: Website Management – primary & alternate}} {{If applicable: Applications Management (Development/Support) –

primary & alternate}} {{If applicable: Database Administration – primary & alternate}} Internet Services Provider (ISP) – primary & alternate (points of

contact) {{If applicable: Managed Security Services Provider (MSSP) –

primary & alternate (points of contact)}} {{If applicable: Cloud Services Provider – primary & alternate (points

of contact)}} Business Operations [division, department or functional workgroup] –

primary & alternate {{repeat for each functional work area/group}}

Page 13



While not being direct members of the CSIRT, the following company functions should be consulted in advance of any incidents to determine and document necessary procedures, and must provide points of contact in case of an incident occurring. {{NOTE: Company may determine that any of these functions should actually be part of the CSIRT.}} These contacts should be able to address issues or concerns related to employees or potential liability matters resulting from a security incident, and to facilitate proper legal processes if matters need to be referred to law enforcement.

Executive Management Human Resources Legal Counsel (company attorneys) Cybersecurity Insurance Carrier/Provider

In addition, the CISO {{or equivalent position}} should also develop a liaison contacts with local law enforcement agencies, such as the Law Enforcement Coordination Center (aka Fusion Center), especially their computer crime units, and/or with the nearest FBI field office’s Cyber Squad.

7. Roles & ResponsibilitiesThe CISO or designated alternate shall have the lead role in Computer Security Incident Management and Response for [Your Company Name], and shall manage the CSIRT. The CISO will develop the CSIRT operating procedures and inter-organization procedures with the company’s third party IT service providers {{, including the cybersecurity insurance provider}}, using the assistance of the CSIRT members {{Optional, if applicable: and company Information Security Committee}}.

7.1. Levels of AuthorityThrough the approval and adoption of this Plan, the CISO is granted the authority to take any necessary actions in regards to security incident response and recovery, to minimize impacts and damage to company IT Resources or Information Assets. Such actions of the CISO may occur through the CSIRT performing necessary functions as outlined in this Plan and detailed in the CSIRT operating procedures.

7.2. Dependencies Within the OrganizationIt is important for company leadership and the CISO to identify other work units within [Your Company Name] which need to participate in incident management, so their cooperation can be solicited before it is needed.

Page 14



The CSIRT will rely on the expertise, judgment, and abilities of the following departments and/or groups. [Some content below is taken from NIST SP-800-61, Rev-2, Aug. 2012, pp. 17-18]

Management – Company Management establishes policies, budget, and staffing. Ultimately, management (through the CIO) is held responsible for coordinating incident response among various stakeholders, minimizing damage, and reporting to the Chief Executive Officer and [Executive Committee]. This area of dependency also includes the functional areas of Risk Management and Privacy Management.

[IT Support (Help Desk and Field Technicians)] {{This group may not apply to small businesses, only medium and large ones.}} – IT technical experts (e.g., system and network administrators, and field support technicians) not only have the needed skills to assist but also usually have the best understanding of the technology they manage on a daily basis. This understanding can ensure that the appropriate actions are taken for the affected system, such as whether to disconnect an attacked system.

Legal Services – Company attorneys and/or external counsel should review incident response plans, policies, and procedures to ensure their compliance with state and federal laws, including the right to privacy, as applicable. In addition, the guidance of Legal Services should be sought if there is reason to believe that an incident may have legal ramifications, including evidence collection, prosecution of a suspect, or a lawsuit, or if there may be a need for a memorandum of understanding (MOU) or other binding agreements involving liability limitations for information sharing with other organizations.

Human Resources – If an employee is suspected of causing an incident, the HR Department must be involved as soon as practicable.

[Physical Security Services] – Some computer security incidents occur through breaches of physical security or involve coordinated logical/digital and physical attacks. The CSIRT may also need access to company facilities during incident handling and need assistance in gaining access to a particular room or office where a compromised system might be deployed or located.

Business Continuity Planning – The CISO should ensure that incident response policies and procedures are in sync with business continuity processes derived from national best practices. Computer security incidents undermine the business resilience of an organization. Company management who might oversee business continuity planning, should be

Page 15



made aware of incidents and their impacts so they can fine-tune business impact assessments, risk assessments, and continuity of operations plans, as applicable.

8. CSIRT Communications Communications to and from the CSIRT, both during and after an incident, is one of the keys to successfully resolving and recovering from the incident. Methods and frequency of communications will vary, depending on the nature and scope of an incident, type of information (i.e., public versus confidential), as well as the target audience. Incident communications among and between CSIRT members and other security staff and IT service providers will likely be verbal (in person or via telephone), and CSIRT members must ensure such communications are properly documented for future reference as part of the incident tracking documentation. CSIRT members should keep in mind that email and certain technology-based communications (e.g. VoIP phone systems) may be disabled or otherwise unavailable during an incident, and CSIRT operational procedures need to define other methods of communications. Other general communications may include such methods as direct email messages, web site postings, broadcast voicemail messages to employees, news media press releases, and written notifications via US Mail.

8.1. Reporting requirements[Your Company Name] must comply with all reporting and notification requirements pursuant to applicable state and federal laws, particularly involving breaches with the potential loss or exposure of confidential, personal information. The CISO or designee is responsible for ensuring proper reporting and notifications are accomplished. Examples of applicable regulations include California Civil Code §1798-§1798.78 (Information Practices Act of 1977), as amended (for example, by SB 1836 or the Security Breach Information Act of 2003), or the federal Health Insurance Portability and Accountability Act of 1996 (HIPAA), as amended. The company shall maintain a list of all applicable state and federal regulations regarding the reporting (to a regulatory agency) and notification (to consumers or customers/clients) for discovered data breaches.

In addition to mandated reporting or notification requirements, the CSIRT (either through the CISO or another designated CSIRT member) should be providing information regarding an active incident to appropriate internal stakeholders, including third party IT service providers who support and maintain company’s IT infrastructure and systems, as applicable and appropriate. At a minimum, the CISO should provide regular status

Page 16



updates to company management during the incident handling phases, as well as providing a final incident report after the lessons learned session.

8.2. Guidelines for External Information Sharing[Your Company Name] may decide to proactively share relevant incident indicator information with peers to improve detection and analysis of incidents. This may occur through the IT-ISAC or some other security group, such as the FBI-sponsored InfraGard Members Alliance or an industry-specific professional association. Before an incident occurs, the CSIRT should discuss information sharing parameters with company’s Legal Department, {{if applicable: cybersecurity insurance provider,}} and management to establish clear procedures and priorities regarding information sharing. CSIRT members, or anyone else sharing incident information must ensure that only authorized information is released and that anyone receiving confidential or sensitive incident information has been appropriately authorized to have it (as evidenced by a non-disclosure agreement (NDA)). The CSIRT should document all contacts and communications with external parties for liability and evidentiary purposes.

Certain incident information may be shared with external parties, as necessary and appropriate, such as law enforcement agencies, US-CERT, IT-ISAC, other CSIRTs, and systems vendors (i.e., Cisco or SourceFire). {{If company’s direct IT service providers have representatives on the CSIRT, they should be considered as part of the internal communications process, rather than external.}}

Cybersecurity Insurance Provider – If applicable, the CISO or other designated company representative should contact the designated point of contact in the claims office for the company’s cybersecurity insurance provider, as soon as possible after the CSIRT has been activated for an Incident; completing any necessary forms and providing as much preliminary information as available.

The Media – All incident information released to the media must be done through the company’s [designated media contact]; CSIRT members are not authorized to provide incident information directly to the media. In preparing incident information for release to the media, CSIRT members should consider the following points to address, as they are known and not sensitive or confidential:

Who attacked you? Why? When did it happen? How did it happen? Did this happen because

you have poor security practices? [The answer to this last question

Page 17



may be confidential – consult with legal counsel before releasing any information.]

How widespread is this incident? What steps are you taking to determine what happened and to prevent future occurrences?

What is the impact of this incident? Was any personally identifiable information (PII) exposed? What is the estimated cost of this incident? (Estimated costs include direct costs, such as lost revenue or theft of funds or intellectual capital, and also the costs to respond to and recover from the incident.)[NIST SP-800-61, Rev-2, Aug. 2012, p. 11]

Law Enforcement – One reason that many security-related incidents do not result in convictions is that some organizations do not properly contact law enforcement. Local, state, and federal law enforcement agencies [Your Company Name] should consider contacting are municipal police, county Sheriff, county District Attorney, state Attorney General, state Office of Information Security, Federal Bureau of Investigation (FBI) local field office, and U.S. Attorney General. Some jurisdictions have integrated, joint law enforcement teams to help combat cybercrime in their region; for example, the San Diego Law Enforcement Coordination Center (LECC). The CSIRT members should become acquainted with these groups, before an incident occurs, to discuss conditions under which incidents should be reported to them, how the reporting should be performed, what evidence should be collected, how it should be collected, and when and how it should be transferred.

The CISO or designee will be the primary contact with law enforcement, consistent with the requirements of the law and the company’s procedures. The CSIRT should understand what the potential jurisdictional issues are (e.g., physical location – [Your Company Name] headquarters being located in [State (e.g., California)] may have IT Resources located in another state, attacked from a system in a third state, being used remotely by an attacker in some other location). [Some content in this section taken from NIST SP-800-61, Rev-2, Aug. 2012, p. 11]

Other Outside Parties – [Your Company Name] may want to discuss incidents with other groups, including those listed below. When reaching out to these external parties, [Your Company Name] may want to work through US-CERT or InfraGard, as a “trusted introducer” to broker the relationship. It is likely that other organizations are experiencing similar issues, and the trusted introducer can ensure that any such patterns are identified and taken into consideration.

Owners of Attacking Addresses – If attacks are originating from an external organization’s IP address space, CSIRT incident handlers may want to talk to the designated security contacts for the

Page 18



organization to alert them to the activity or to ask them to collect evidence. It is highly recommended to coordinate such communications with US-CERT or the FBI, due to potential jurisdictional issues.

Software Vendors – There are two main types of contacts in this area; first for security system software vendors and, second, for system or application vendors whose product was the target of an attack. CSIRT Incident handlers may want to speak to either type of software vendor about suspicious activity on their system or within an application. For security vendors, this contact could include questions regarding the significance of certain log entries or known false positives for certain intrusion detection signatures, where minimal information regarding the incident may need to be revealed. For application software vendors, questions may be related to unusual software behaviors and any known or new vulnerabilities that may be exploited. In some cases, software vendors may want to execute a Non-Disclosure Agreement (NDA) with [Your Company Name] before they release any information.

Other Incident Response Teams – [Your Company Name] may experience an incident that is similar to ones handled by other CSIRTs. Proactively sharing information can facilitate more effective and efficient incident handling (e.g., providing advance warning, increasing preparedness, developing situational awareness). Groups such as the Forum of Incident Response and Security Teams (FIRST) and the Anti-Phishing Working Group (APWG) are not incident response teams, but they promote information sharing among incident response teams.

Page 19



Affected External Parties – An incident may affect external parties directly or indirectly. For example, an outside organization may contact [Your Company Name] and claim that one of the company’s users is attacking it. Another way in which external parties may be affected is if an attacker gains access to sensitive information regarding them, such as business financial information. [Your Company Name] must comply with applicable state and federal notification requirements for specified types of breaches. Regardless of the circumstances, it is preferable for [Your Company Name] to notify affected external parties of an incident before the media or other external organizations do so. CSIRT incident handlers should work through the [Public Affairs Office] and be careful to only provide appropriate information; information about internal investigations should not be released.[Major portions of the above section taken from NIST SP-800-61, Rev-2, Aug. 2012, pp. 12-13]

9. Standard Operating Procedures for Incident Response

NIST standards outline four major phases of an Incident Management Lifecycle which are explained below (see Figure 1). This Plan incorporates these phases into the incident response processes, as described below, and should also be part of [Your Company Name]’s specific CSIRT operating procedures. To assist the CSIRT in documenting an incident, a detailed Incident Handling Response Form is included in Appendix B.

Page 20

Figure 1 - Incident Response Lifecycle[NIST SP-800-61 Rev-2, Aug. 2012, p. 21]



9.9.1. Incident Management Lifecycle Overview

9.1.1.Preparation PhaseIncident response methodologies typically emphasize preparation—not only establishing an incident response capability so that the organization is ready to respond to incidents, but also preventing incidents by ensuring that systems, networks, and applications are sufficiently secure. Although the CSIRT is not typically responsible for incident prevention, it is fundamental to the success of incident response programs. [NIST SP-800-61, Rev-2, Aug. 2012, p.21]

Under the subheading of “Preparing to Handle Incidents,” NIST provides lists of tools and resources that the CSIRT should have available to help make the response process easier. These include team communications and facilities, as well as incident analysis hardware and software or other resources (e.g., current network architecture diagrams), and incident mitigation software (e.g., clean system images to restore impacted devices).

Under the subheading of “Preventing Incidents,” NIST recommends implementation of best practices for network and application security, using standard security controls. Basic actions include regular risk assessments, host security, network security, malware prevention, and user security awareness and training.

9.1.2.Detection and Analysis PhaseIn this phase, NIST defines different “attack vectors” to include external or removable media, attrition (e.g., brute force attacks), web-based, email (e.g., phishing or spear phishing), impersonation (e.g., spoofing an IP address), improper usage (e.g., violating the acceptable use policy), and loss or theft of equipment (especially laptops and smart phones). In addition, an increasingly common vector is service disruption (e.g., Denial of Service (DoS) attack). This is not an exhaustive list of attack vectors, just the most common.

NIST describes the next detection task, “signs of an incident,” as one of the most challenging for organizations, largely due to three factors: (1) detection through various means (i.e., firewalls, IDS, IPS, etc.) with different levels of accuracy and detail, (2) the volume of events that could indicate a possible security incident (tens or hundreds of thousands, or millions per day), and (3) extensive technical and organizational knowledge and experience to analyze event or incident data. The signs of an incident (also called Indicators

Page 21



of Compromise or IOC) fall into one of two categories – precursors and indicators. A precursor is a sign that an incident may occur in the future. An indicator is a sign that an incident may have occurred or may be occurring now. [NIST SP-800-61, Rev-2, Aug. 2012, p. 26] While precursors are rare, indicators are very common and include SIEM alerts, anti-malware alerts, audit records of unplanned configuration changes, etc. NIST provides several sources of indicators, including system alerts, log files, publicly available information (e.g., news announcements of new vulnerabilities or exploits), and people (e.g., internal system administrators or security staff, or external security forums).

After detection, the next part of this phase involves “incident analysis” to validate whether an actual security incident has occurred or not. This task is usually one of the most challenging and needs to be performed as quickly as possible to determine if the CSIRT should be activated to handle the situation. In some organizations, the CSIRT is performing the incident analysis and then taking any necessary actions based on the results. NIST recommends actions, some of which are part of Preparation, to make the analysis easier, including profiling of networks and systems, understanding normal behaviors (of networks, systems, and applications), having a log retention policy (for audits and evidence), performing event correlation (a SIEM may assist with this), synchronizing all host clocks, maintaining and using a knowledge base, using Internet search engines for research, using packet-sniffers to collect additional data, filtering the data, and seeking assistance from others (e.g., US-CERT or other CSIRTs).

Concurrent with other actions, this phase includes “incident documentation” where all incident data (e.g., alerts and log files) and CSIRT actions are recorded and maintained securely, since such data may contain sensitive or confidential information. The methods and manner of recording information about an incident will vary widely, depending on the circumstances and an organization’s capabilities. NIST does recommend using an automated tracking system, which is only accessible by CSIRT members and other authorized people (e.g., the CIO or other stakeholders), and used to enter important, basic information about an incident, as well as providing incident reports. Incident-related communications, especially email, should be encrypted or otherwise protected from unauthorized viewing.

The next step in this phase is “incident prioritization.” While the definitions for different information security risks and priority categories of security incidents was provided in Section 5.1 above, further clarification is provided here to assist the CSIRT with triage and

Page 22



prioritization of incidents, especially when there are more than one incident occurring simultaneously. According to NIST, prioritizing the handling of the incident is perhaps the most critical decision point in the incident handling process. Incidents should not be handled on a first-come, first-served basis as a result of resource limitations. Instead, handling should be prioritized based on the relevant factors, such as (1) functional impact of the incident, (2) information impact of the incident (e.g., impacting confidentiality, integrity or the availability of information),, and (3) recoverability from the incident. Combining the functional impact to the organization’s systems and the impact to the organization’s information determines the business impact of the incident. Further, the recoverability from the incident determines the possible responses that the team may take when handling the incident. An incident with a high functional impact and low effort to recover from is an ideal candidate for immediate action from the team. However, some incidents may not have smooth recovery paths and may need to be queued for a more strategic-level response. [NIST SP-800-61, Rev-2, Aug. 2012, p. 32]

NIST divides the functional impacts into four, mutually exclusive categories: none, low, medium, and high. Information impacts are divided into four categories, which are not mutually exclusive (except “none”): none, privacy breach, proprietary breach, and integrity loss; meaning a single incident may entail more than one information impact. Recoverability is also divided into four categories, which are used to help determine the level and types of resources required to handle the incident: regular, supplemental, extended, and not recoverable.

Organizations should have an escalation process for individuals reporting a potential security incident, so that if there is no response within a designated amount of time, the reporting party should call the next higher level (e.g., supervisor or CSIRT leader).

In the final step of this phase, “incident notification,” the organization lists who needs to be notified, when they need to be notified (including updates), and what information is to be included in the notifications. Methods of notification will vary, depending on the type of information, its urgency and sensitivity, and the intended audience. Details of the notification process are included in [Your Company Name]’s CSIRT operating procedures.

9.1.3.Containment and Recovery PhaseThe third phase of the Incident Management Lifecycle includes activities and functions aimed at stopping the incident, containing and

Page 23



minimizing impacts to systems, data, and business operations, removing any malware, and beginning the recovery to normal operations. NIST defines four primary functions within this phase:

(#1) Choosing a Containment Strategy – An essential part of containment is decision-making (e.g., shut down a system, disconnect it from a network, disable certain functions). Such decisions are much easier to make if there are predetermined strategies and procedures for containing the incident. Organizations should define acceptable risks in dealing with incidents and develop strategies accordingly. Containment strategies vary based on the type of incident. For example, the strategy for containing an email-borne malware infection is quite different from that of a network-based DDoS attack. Organizations should create separate containment strategies for each major incident type, with criteria documented clearly to facilitate decision-making. [NIST SP-800-61, Rev-2, Aug. 2012, p. 35] Criteria for the types of containment strategies may include the type or nature of incident, intended target(s) (e.g., narrow focus on a single system versus broad-based intrusion or malware infection), operational impacts, and other factors. NIST provides guidance on how to determine an appropriate strategy for a particular incident.

(#2) Evidence Gathering and Handling – Although the primary reason for gathering evidence during an incident is to resolve the incident, it may also be needed for legal proceedings. In such cases, it is important to clearly document how all evidence, including compromised systems, has been preserved. Evidence should be collected according to procedures that meet all applicable laws and regulations that have been developed from previous discussions with legal staff and appropriate law enforcement agencies so that any evidence can be admissible in court. Once Law Enforcement has been contacted, or if their procedures have been made known in advance, then all evidence gathering should comply with the law enforcement agency’s requirements. Procedurally, this may require that affected computer systems are not immediately turned off or disconnected from the network. In addition, evidence should be accounted for at all times; whenever evidence is transferred from person to person (which should be kept to an absolute minimum), “Chain of Custody” forms should detail each transfer and include each party’s signature. A detailed log should be kept for all evidence, including the following:

Identifying information (e.g., the location, serial number, model number, hostname, media access control (MAC) addresses, and IP addresses of a computer)

Page 24



Name, title, and phone number of each individual who collected or handled the evidence during the investigation

Time and date (including time zone) of each occurrence of evidence handling

Locations where the evidence was stored[NIST SP-800-61, Rev-2, Aug. 2012, p. 36]

Since not every security incident requires evidence collection, the [Your Company Name] CSIRT operating procedures must include the necessary criteria for determining if and when an incident involves the need to preserve evidence, and the proper steps for doing so, to ensure it is forensically sound (by legal standards). The operating procedures must also detail how long evidence needs to be retained before it can be either destroyed or properly returned into service, based on the legal requirements related to the incident and also any regulations governing its retention.

(#3) Identifying the Attacking Hosts – Information about the source of an attack or attempted intrusion is not required to resolve an incident, and it may require an extended, time-consuming level of effort. The CSIRT should stay focused primarily on containment, eradication, and recovery functions. However, as time permits, NIST gives the following activities as being common for trying to identify the attacker [NIST SP-800-61, Rev-2, Aug. 2012, p. 37]:

Validating the Attacking Host’s IP Address Researching the Attacking Host through Search Engines Using Incident Databases Monitoring Possible Attacker Communications Channels

(#4) Eradication and Recovery – After an incident has been contained, eradication may be necessary to eliminate components of the incident, such as deleting malware and disabling breached user accounts, as well as identifying and mitigating all vulnerabilities that were exploited. During eradication, it is important to identify all affected hosts within the organization so that they can be remediated. In recovery, administrators restore systems to normal operation, confirm that the systems are functioning normally, and (if applicable) remediate vulnerabilities to prevent similar incidents. Eradication and recovery should be done in a phased approach so that remediation steps are prioritized. For large-scale incidents, recovery may take months; the intent of the early phases should be to increase the overall security with relatively quick (days to weeks) high value changes to prevent future incidents. [NIST SP-800-61, Rev-2, Aug. 2012, p. 37]

Page 25



9.1.4.Post-Incident PhaseThis fourth and final phase of the Incident Management Lifecycle, includes three main activities – Lessons Learned, Using Collected Incident Data, and Evidence Retention. As part of the overall lifecycle, NIST provides an Incident Handling Checklist (refer to Appendix A) to help the CSIRT follow through the steps in each phase and to document their completion.

Lessons Learned[Section below taken from: NIST SP-800-61. Rev-2, Aug. 2012, pp. 38-39]One of the most important parts of incident response is also the most often omitted: learning and improving. Each incident response team should evolve to reflect new threats, improved technology, and lessons learned. Multiple incidents can be covered in a single lessons learned meeting. This meeting provides a chance to achieve closure with respect to an incident by reviewing what occurred, what was done to intervene, and how well intervention worked. The meeting should be held within several days of the end of the incident. Questions to be answered in the meeting include:

Exactly what happened and at what times? How well did staff and management perform in dealing with the

incident? Were the documented procedures followed? Were they adequate?

What information was needed sooner? Were any steps or actions taken that might have inhibited the

recovery? What would the staff and management do differently the next

time a similar incident occurs? How could information sharing with other organizations have

been improved? What corrective actions can prevent similar incidents in the

future? What detective controls were ineffective and why? What were the indicators of compromise (IOCs) that were

missed? What precursors or indicators should be watched for in the future

to detect similar incidents? What additional tools or resources are needed to detect, analyze,

and mitigate future incidents?

Page 26



After serious attacks have occurred, it is usually worthwhile to hold post-mortem meetings that cross team and organizational boundaries to provide a mechanism for information sharing. The primary consideration in holding such meetings is ensuring that the right people are involved. Not only is it important to invite people who have been involved in the incident that is being analyzed, but also it is wise to consider who should be invited for the purpose of facilitating future cooperation. It is also important to document the major points of agreement and action items and to communicate them to parties who could not attend the meeting.

Reports from these meetings are good material for training new team members by showing them how more experienced team members respond to incidents. Updating incident response policies and procedures is another important part of the lessons learned process. Post-mortem analysis of the way an incident was handled will often reveal a missing step or an inaccuracy in a procedure, providing impetus for change.

Another important post-incident activity is creating a follow-up report for each incident, which can be quite valuable for future use. The report provides a reference that can be used to assist in handling similar incidents. Creating a formal chronology of events (including time-stamped information such as log data from systems) is important for legal reasons, as is creating a monetary estimate of the amount of damage the incident caused. This estimate may become the basis for subsequent prosecution activity.

Using Collected Incident Data (Post-Incident Analysis & Statistics)[Section below taken from: NIST SP-800-61. Rev-2, Aug. 2012, pp. 39-41]Lessons learned activities should produce a set of objective and subjective data regarding each incident. Over time, the collected incident data should be useful in several capacities. A study of incident characteristics may indicate systemic security weaknesses and threats, as well as changes in incident trends. This data can be put back into the risk assessment process, ultimately leading to the selection and implementation of additional controls. Another good use of the data is measuring the success of the incident response team. If incident data is collected and stored properly, it should provide several measures of the success (or at least the activities) of the incident response team. Incident data can also be collected to determine if a change to incident response capabilities causes a corresponding change in the team’s performance (e.g., improvements in efficiency, reductions in costs).

Page 27



Organizations should focus on collecting data that is actionable, rather than collecting data simply because it is available. Absolute numbers are not informative—understanding how they represent threats to the business processes of the organization is what matters. Organizations should decide what incident data to collect based on reporting requirements and on the expected return on investment from the data (e.g., identifying a new threat and mitigating the related vulnerabilities before they can be exploited). Possible metrics for incident-related data include:

Number of Incidents Handled – The number of incidents handled is best taken as a measure of the relative amount of work that the incident response team had to perform, not as a measure of the quality of the team, unless it is considered in the context of other measures that collectively give an indication of work quality. It is more effective to produce separate incident counts for each incident category.

Time Per Incident – For each incident, time can be measured in several ways:

o Total amount of labor spent working on the incidento Elapsed time from the beginning of the incident to incident

discovery, to the initial impact assessment, and to each stage of the incident handling process (e.g., containment, recovery)

o How long it took the incident response team to respond to the initial report of the incident

o How long it took to report the incident to management and, if necessary, appropriate external entities (e.g., FBI, US-CERT, etc.)

Objective Assessment of Each Incident – The response to an incident that has been resolved can be analyzed to determine how effective it was. The following are examples of performing an objective assessment of an incident:

o Reviewing logs, forms, reports, and other incident documentation for adherence to established incident response policies and procedures

o Identifying which precursors and indicators of the incident were recorded to determine how effectively the incident was logged and identified

o Determining if the incident caused damage before it was detected

Page 28



o Determining if the actual cause of the incident was identified, and identifying the attack vector, the vulnerabilities exploited, and the characteristics of the targeted or victimized systems, networks, and applications

o Determining if the incident is a recurrence of a previous incident

o Calculating the estimated monetary damage from the incident (e.g., information and critical business processes negatively affected by the incident)

o Measuring the difference between the initial impact assessment and the final impact assessment

o Identifying which measures, if any, could have prevented the incident

Subjective Assessment of Each Incident – Incident response team members may be asked to assess their own performance, as well as that of other team members and of the entire team. Another valuable source of input is the owner of a resource that was attacked, in order to determine if the owner thinks the incident was handled efficiently and if the outcome was satisfactory.

Evidence RetentionThe CISO and CSIRT should follow established [Your Company Name] policies and procedures for the collection and retention of evidence, as applicable to computer security incidents, based on requirements defined by [company legal counsel] or pursuant to state or federal law. Retention may last for several months to years. Factors that need to be considered when determining the retention period for particular computer incident evidence include criminal prosecution efforts, civil case actions, general data or records retention requirements, and costs for hardware (e.g., computer devices, hard drives, or removable media) and storage facilities.

9.2. Information Sharing[Section 9.2 taken from NIST SP-800-61, Rev-2, Aug. 2012, pp. 48-50]Information sharing is a key element of enabling coordination across organizations. Even the smallest organizations need to be able to share incident information with peers and partners in order to deal with many incidents effectively. Organizations should perform such information sharing throughout the incident response life cycle and not wait until an incident has been fully resolved before sharing details of it with others.

Before trying to share information or initiating any coordination efforts with external organizations, the CISO or CIO should consult with the [company legal counsel]. There may be contracts or other agreements

Page 29



that need to be put into place before discussions occur, which may (and likely should) include a nondisclosure agreement (NDA) to protect the confidentiality of the organization’s most sensitive information. [Your Company Name] should also consider any existing requirements for reporting, such as sharing incident information with a regulatory agency, industry peers or business partners, or reporting incidents to other agencies, such as an industry-specific Information Sharing and Analysis Center (ISAC) or the FBI’s local InfraGard Chapter.

While Section 8.2 above discussed external information sharing with particular agencies or organizations, this section will provide different techniques used for information sharing.

9.2.1.Ad Hoc Most incident information sharing has traditionally occurred through ad hoc methods, such as email, instant messaging clients, and telephone. Ad hoc information sharing mechanisms normally rely on an individual employee’s connections with employees in incident response teams of partner organizations. The employee uses these connections to manually share information with peers and coordinate with them to construct strategies for responding to an incident. Depending on the size of the organization, these ad hoc techniques may be the most cost-effective way of sharing information with partner organizations. However, due to the informal nature of ad hoc information sharing, it is not possible to guarantee that the information sharing processes will always operate. For example, if a particularly well-connected employee resigns from an incident response team, that team may temporarily lose the majority of information sharing channels it relies on to effectively coordinate with outside organizations.

Ad hoc information sharing methods are also largely unstandardized in terms of what information is communicated and how that communication occurs. Because of the lack of standardization, they tend to require manual intervention and to be more resource-intensive to process than the alternative, partially automated methods. Whenever possible an organization should attempt to formalize its information sharing strategies through formal agreements with partner organizations and technical mechanisms that will help to partially automate the sharing of information.

9.2.2.Partially Automated Organizations should attempt to automate as much of the information sharing process as possible to make cross-organizational coordination efficient and cost effective. In reality, it will not be possible to fully

Page 30



automate the sharing of all incident information, nor will it be desirable due to security and trust considerations. Organizations should attempt to achieve a balance of automated information sharing overlaid with human-centric processes for managing the information flow.

When engineering automated information sharing solutions, organizations should first consider what types of information they will communicate with partners. The organization may want to construct a formal data dictionary, enumerating all entities and relationships between entities that they will wish to share. Once the organization understands the types of information they will share, it is necessary to construct formal, machine-processable models to capture this information. Wherever possible, an organization should use existing data exchange standards for representing the information they need to share. The organization should work with its partner organizations when deciding on the data exchange models to ensure that the standards selected are compatible with the partner organization’s incident response systems. When selecting existing data exchange models, organizations may prefer to select multiple approaches that model different aspects of the incident response domain and then leverage these models in a modular fashion, communicating only the information needed at a specific decision point in the life cycle.

In addition to selecting the data exchange models for sharing incident information, an organization must also work with its partner organizations to agree on the technical transport mechanisms for enabling the information exchange to occur in an automated fashion. These transport mechanisms include, at a minimum, the transport protocol for exchanging the information, the architectural model for communicating with an information resource, and the applicable ports and domain names for accessing an information resource in a particular organization. For example, a group of partner organizations may decide to exchange incident information using a Representational State Transfer (REST) architecture to exchange IODEF/Real-Time Inter-Network Defense (RID) data over Hypertext Transfer Protocol Secure (HTTPS) on port 4590 of a specific domain name within each organization’s DMZ.

9.2.3.Security Considerations There are several security considerations that incident response teams should consider when planning their information sharing. One is being able to designate who can see which pieces of incident information (e.g., on-going protection of sensitive information). It may also be necessary to perform data sanitization or scrubbing to remove sensitive pieces of data from the incident information without

Page 31



disturbing the information on precursors, indicators, and other technical information. See below for more information on granular information sharing. The incident response team should also ensure that the necessary measures are taken to protect information shared with the team by other organizations.

9.2.4.Granular Information Sharing Organizations need to balance the benefits of information sharing with the drawbacks of sharing sensitive information, ideally sharing the necessary information and only the necessary information with the appropriate parties. Organizations can think of their incident information as being comprised of two types of information: business impact and technical. Business impact information is often shared in the context of a team-to-coordinating-team relationship, while technical information is often shared within all three types of coordination relationships [team-to-team, team-to-coordinating team, and coordinating team-to-coordinating team]. This section discusses both types of information and provides recommendations for performing granular information sharing.

Business Impact Information – Business impact information involves how the incident is affecting the organization in terms of mission impact, financial impact, etc. Such information, at least at a summary level, is often reported to higher-level coordinating incident response teams to communicate an estimate of the damage caused by the incident. Coordinating response teams may need this impact information to make decisions regarding the degree of assistance to provide to the reporting organization. A coordinating team may also use this information to make decisions relative to how a specific incident will affect other organizations in the community they represent.

Coordinating teams may require member organizations to report on some degree of business impact information. For example, a coordinating team may require a member organization to report impact information. In this case, for a hypothetical incident an organization would report that it has a functional impact of medium, an information impact of none, and will require extended recoverability time. This high-level information would alert the coordinating team that the member organization requires some level of additional resources to recover from the incident. The coordinating team could then pursue additional communication with the member organization to determine how many resources are required as well as the type of resources based on the technical information provided about the incident.

Page 32



Business impact information is only useful for reporting to organizations that have some interest in ensuring the mission of the organization experiencing the incident. In many cases, incident response teams should avoid sharing business impact information with outside organizations unless there is a clear value proposition or formal reporting requirements and ideally protected under NDA. When sharing information with peer and partner organizations, incident response teams should focus on exchanging technical information as outlined below.

Technical Information – There are many different types of technical indicators signifying the occurrence of an incident within an organization. These indicators originate from the variety of technical information associated with incidents, such as the hostnames and IP addresses of attacking hosts, samples of malware, precursors and indicators of similar incidents, and types of vulnerabilities exploited in an incident.

While organizations gain value from collecting their own internal indicators, they may gain additional value from analyzing indicators received from partner organizations and sharing internal indicators for external analysis and use. If the organization receives external indicator data pertaining to an incident they have not seen, they can use that indicator data to identify the incident as it begins to occur. Similarly, an organization may use external indicator data to detect an ongoing incident that it was not aware of due to the lack of internal resources to capture the specific indicator data. Organizations may also benefit from sharing their internal indicator data with external organizations. For example, if they share technical information pertaining to an incident they are experiencing, a partner organization may respond with a suggested remediation strategy for handling that incident.

Organizations should share as much of this information as possible; however, there may be both security and liability reasons why an organization would not want to reveal the details of an exploited vulnerability. External indicators, such as the general characteristics of attacks and the identity of attacking hosts, are usually safe to share with others. Organizations should consider which types of technical information should or should not be shared with various parties, and then endeavor to share as much of the appropriate information as possible with other organizations.

Page 33



Technical indicator data is useful when it allows an organization to identify an actual incident. However, not all indicator data received from external sources will pertain to the organization receiving it. In some cases, this external data will generate false positives within the receiving organization's network and may cause resources to be spent on nonexistent problems.

Organizations participating in incident information sharing should have staff skilled in taking technical indicator information from sharing communities and disseminating that information throughout the enterprise, preferably in an automated way. Organizations should also attempt to ensure that they only share an indicator for which they have a relatively high level of confidence that it signifies an actual incident.

10. Incident Response Performance Measures [TBD > organization-specific] {{The purpose of this section is to create and capture relevant performance measures of the CSIRT during each incident where it is activated, and cumulatively over time (annually) to evaluate improvement or decline in performance.}}

11. Metrics for Measuring Incident Management Capabilities

A series of Incident Management Capability Metrics was developed by the Software Engineering Institute (SEI) of Carnegie Mellon University, based on direction and funding from the U.S. Department of Defense (DoD). Using four functional categories similar to the phases of the Incident Management Lifecycle defined by NIST, SEI developed a draft set of questions for each phase to help an organization assess its current capability in performing Incident Management functions. The following information provides an overview of each functional category from SEI’s Incident Management Capability Metrics Version 0.1. The “Copyright Legal Notice” at the end of Appendix C applies to the SEI information below. Excerpts of selected questions (metrics) identified in the SEI document are included in Appendix C. The CISO, CIO or other company management wanting to assess their Incident Management capabilities, should decide on the focus of the assessment and select appropriate questions from the SEI document to address the capabilities in that focus area or the full spectrum of functions.

PHASE 1: PROTECTThe mission of the Protect process is to adequately protect and secure critical organization data and assets including the computing infrastructure

Page 34



of the groups performing incident management functions and their constituency, in response to current risk, threats, and attacks while handling information in a timely, secure fashion.

The Protect process focuses on efforts to:

evaluate the security posture of the computing infrastructure by performing such tasks as proactive scanning and network monitoring, and by performing security and risk evaluations after setting appropriate management approvals

implement changes to the computing infrastructure to stop or mitigate an ongoing incident or to stop or mitigate the potential exploitation of a vulnerability in the hardware or software infrastructure

pass off to the Detect process any information about ongoing events or incidents, discovered vulnerabilities, or other security-related events

implement infrastructure protection improvements resulting from incident postmortem reviews or other process improvement mechanisms

PHASE 2: DETECTIn the Detect process, information about potential incidents, vulnerabilities, and other computer security or incident management information is gathered both proactively and reactively. In reactive detection, information is received from internal or external sources in the form of reports or notifications, as shown in the examples below:

Those using the organization’s computing resources may notice some unusual or malicious activity and report it to the appropriate contact. The reporting may involve submitting an incident reporting form or calling the appropriate POC, such as a help desk or a CSIRT hotline.

Other computer security experts may send an alert or notification that must be assessed to see if there is a potential threat to the receiver’s infrastructure. For example, some other external team might receive reports of a new worm propagating in its area, create an advisory or alert, and send it out to a subscriber mailing list. The organization’s incident management personnel see this advisory or alert and evaluate whether it might have a similar effect in their constituency, then take action based upon their analysis.

An external team might send a report to an organization alerting personnel to activity appearing to originate from within the organization. The organization then needs to review or evaluate its own systems to determine if there is a problem.

Page 35



Proactive detection requires actions by the designated staff to identify suspicious activity.

Personnel monitor a variety of data (such as host logs, firewall logs, and netflows) and use intrusion detection and prevention software to monitor network behavior, looking for indications of suspicious activity. The data are analyzed, and any unusual or suspicious event information is “triaged” to the appropriate individuals for handling.

PHASE 3: RESPONDIn the Respond process, information that has been received by incident management personnel concerning potential incidents, vulnerabilities, or other computer security events or incidents is acted upon. This includes actions that may be performed by technical staff, management, or other entities within an organization. For example, technical actions can include:

analyzing the event or incident information, data, and supplemental material such as log files, malicious code, or other artifacts

researching corresponding mitigation strategies and recovery options developing advisories, alerts, and other publications that provide

guidance and advice for resolving or mitigating the event or incident containing any ongoing malicious activity by making technical changes

to the infrastructure, such as disconnecting affected systems from the network, changing security configurations, or filtering ports, services, IP addresses, or packet content via firewalls, mail servers, routers, or other devices

eradicating or cleaning up any malicious processes and files repairing or recovering affected systems providing assistance to constituents regarding response actions

PHASE 4: SUSTAINThis process focuses on the ability of the organization to identify and implement what needs to be in place for incident management to occur in a timely and effective manner. For this to occur, there must be a defined incident management mission with supporting goals and objectives, well-defined policies and procedures, skilled staff, service definitions, technological resources, and other processes and equipment to promote the function. Also required are the supporting infrastructure, controls, supporting mechanisms, artifacts, and quality measures that enable incident management to perform its functions. In this regard, it has appropriate contracts, MOUs, and SLAs established that define roles and responsibilities, financial planning and budgeting processes to sustain operations over time,

Page 36



training and educational opportunities for staff, program management plans, and more.

Part of any sustainment function includes improving the overall effectiveness of the operations. This is also true in the case of a CSIRT or incident management capability. As events and incidents are handled and response is provided, any lessons learned should be captured and fed into process improvements. Additionally, any results from risk assessments or vulnerability scanning activities can also be reviewed to determine any changes needed in processes, technology, personnel skills, or other areas.

The Sustain metrics include subcategories in the following areas:

MOU (Memorandum of Understanding), MOA (Memorandum of Agreement), LOA (Letter of Agreement), SLA (Service Level Agreement), and Contracts – to formalize activities and define services provided by the CSIRT and to establish correct expectations for operations

Project/Program Management – to provide guidance and oversight for continued incident management operations, financial planning, business resumption, and other relevant activities

CND (Computer Network Defense) Technology Development, Evaluation and Implementation – looks at the ability of the organization to test software and analyze impacts prior to implementing in production networks; examines new technologies that are incorporated into the infrastructure

Personnel – focuses on ensuring there is a cadre of personnel with the required knowledge, skills, and abilities to perform the work and to continue to develop professionally in order to meet the changing needs of the constituency that it serves

Security Administration – covering physical security measures and operations security

CND (Computer Network Defense) Information Systems – ensures the organization utilizes a defense-in-depth approach for hardening systems and networks (data protection, monitoring, risk assessments, vulnerability scanning, patch management strategies, communications methods, etc.) used for incident management functions

Threat Level Implementation – focuses on the organization’s ability to maintain and adhere to threat levels and to assist consistently with threat level issues

Page 37



12. Roadmap/Plan for Improving Incident Response Capabilities

The CIO and CISO should direct a review this Plan annually with the CSIRT [and Information Security Committee], including relevant documentation from all incidents that were handled by the CSIRT for the year, especially the Lessons Learned. The goal of this annual review is to determine what updates or changes need to be made to this Plan or the CSIRT operating procedures, to make improvements in preventing, detecting, mitigating, responding to, resolving, and recovering from security incidents. Recommended changes should be presented to the CEO or Owner for management approval.

In addition to reviewing Lessons Learned from each incident and the annual policy review, [Your Company Name] will conduct periodic drills or exercises to help improve the performance of incident management and response, and the performance of the CSIRT. These drills and exercises should incorporate current vulnerabilities and exploits, as well as trends in emerging threats and implementation of new technologies (planned for [Your Company Name]). The drills and exercises should include company staff and management beyond the CSIRT [and IT Department], both for awareness purposes and to gain understanding by and cooperation from those stakeholders.

13. ReferencesThe following organization web sites and resource document links are provided as reference information, in addition to the NIST & SEI/CERT documents listed in Section 3 above, on the topic of computer security-related Incident Management and its components. These sources may benefit CSIRT members in learning more about their roles and responsibilities, and provide managers and executives a better understanding of the interconnected relationships between business risk, information security, and incident management.

Organizations: U.S. Department of Homeland Security, National Cyber Security

Division, U.S. Computer Emergency Readiness Team (US-CERT)o https://www.us-cert.gov/

CERT Coordination Center, Carnegie Mellon Universityo http://www.cert.org/incident-management/

National Institute of Standards & Technology (NIST), Computer Security Resource Center

o http://csrc.nist.gov/ Information Systems Audit and Control Association (ISACA)

Page 38

http://csrc.nist.gov/

http://www.cert.org/incident-management/

https://www.us-cert.gov/



o https://www.isaca.org/ ISACA – San Diego Chapter

o http://isaca-sd.org/ Center for Internet Security, Multi-State Information Sharing & Analysis

Center (MS-ISAC)o http://msisac.cisecurity.org/

InfraGard San Diego Members Allianceo http://www.infragardsd.org/

InfraGard National Members Allianceo http://infragardmembers.org/

Securing Our eCity Foundationo http://infragardmembers.org/

Information Systems Security Association (ISSA)o https://www.issa.org/

ISSA – San Diego Chaptero http://www.sdissa.org/

San Diego County Office of Emergency Services (OES)o http://www.sandiegocounty.gov/content/sdc/oes.html

San Diego County Emergency Siteo http://sdcountyemergency.com/

Incident Management Documents: Action List for Developing a Computer Security Incident Response

Team, August 2014, CERT/CCo http://www.cert.org/incident-management/csirt-development/

action-list.cfm Combating the Insider Threat, May 2014, US-CERT

o https://www.us-cert.gov/sites/default/files/publications/ Combating%20the%20Insider%20Threat_0.pdf

Creating a Computer Security Incident Response Team: A Process for Getting Started, August 2014, CERT/CC

o http://www.cert.org/incident-management/products-services/ creating-a-csirt.cfm

Defining Incident Management Processes for CSIRTs: A Work in Progress, October 2004, SEI

o http://resources.sei.cmu.edu/asset_files/TechnicalReport/ 2004_005_001_14405.pdf

Handbook for Computer Security Incident Response Teams (CSIRTs), 2nd Edition, April 2003, SEI

o http://resources.sei.cmu.edu/asset_files/Handbook/ 2003_002_001_14102.pdf

Incident Management (Whitepaper), December 2005, CERT/CCo http://resources.sei.cmu.edu/asset_files/WhitePaper/

2005_019_001_295923.pdf

Page 39

http://resources.sei.cmu.edu/asset_files/WhitePaper/2005_019_001_295923.pdf

http://resources.sei.cmu.edu/asset_files/WhitePaper/2005_019_001_295923.pdf

http://resources.sei.cmu.edu/asset_files/Handbook/2003_002_001_14102.pdf

http://resources.sei.cmu.edu/asset_files/Handbook/2003_002_001_14102.pdf

http://resources.sei.cmu.edu/asset_files/TechnicalReport/2004_005_001_14405.pdf

http://resources.sei.cmu.edu/asset_files/TechnicalReport/2004_005_001_14405.pdf

http://www.cert.org/incident-management/products-services/creating-a-csirt.cfm

http://www.cert.org/incident-management/products-services/creating-a-csirt.cfm

https://www.us-cert.gov/sites/default/files/publications/Combating%20the%20Insider%20Threat_0.pdf

https://www.us-cert.gov/sites/default/files/publications/Combating%20the%20Insider%20Threat_0.pdf

http://www.cert.org/incident-management/csirt-development/action-list.cfm

http://www.cert.org/incident-management/csirt-development/action-list.cfm

http://sdcountyemergency.com/

http://www.sandiegocounty.gov/content/sdc/oes.html

http://www.sdissa.org/

https://www.issa.org/

http://infragardmembers.org/

http://infragardmembers.org/

http://www.infragardsd.org/

http://msisac.cisecurity.org/

http://isaca-sd.org/

https://www.isaca.org/



Malware Threats and Mitigation Strategies, May 2005, US-CERT & MS-ISAC

o https://www.us-cert.gov/sites/default/files/publications/malware- threats-mitigation.pdf

Staffing Your Computer Security Incident Response Team – What Basic Skills are Needed?, August 2014, CERT/CC

o http://www.cert.org/incident-management/csirt-development/ csirt-staffing.cfm

[Remainder of Page Intentionally Left Blank]

Page 40

http://www.cert.org/incident-management/csirt-development/csirt-staffing.cfm

http://www.cert.org/incident-management/csirt-development/csirt-staffing.cfm

https://www.us-cert.gov/sites/default/files/publications/malware-threats-mitigation.pdf

https://www.us-cert.gov/sites/default/files/publications/malware-threats-mitigation.pdf



APPENDIX ANIST INCIDENT HANDLING CHECKLIST

Ref # Actions DateCompleted

ResponsibleParty

Detection & Analysis1. Determine whether an incident has

occurred1.1 Analyze the precursors and

indicators1.2 Look for correlating information1.3 Perform research (e.g., search

engines, knowledge base)1.4 As soon as the handler believes an

incident has occurred, begin documenting the investigation and gathering evidence

2. Prioritize handling the incident based on the relevant factors (functional impact, information impact, recoverability effort, etc.)

3. Report the incident to the appropriate internal personnel and external organizations

Containment, Eradication, & Recovery4. Acquire, preserve, secure, and document

evidence5. Contain the incident6. Eradicate the incident

6.1 Identify and mitigate all vulnerabilities that were exploited

6.2 Remove malware, inappropriate materials, and other components

6.3 If more affected hosts are discovered (e.g., new malware infections), repeat the Detection and Analysis steps (1.1, 1.2) to identify all other affected hosts, then contain (5) and eradicate (6) the incident for them

7. Recover from the incident

Page A-1



Ref # Actions DateCompleted

ResponsibleParty

7.1 Return affected systems to an operationally ready state

7.2 Confirm that the affected systems are functioning normally

7.3 If necessary, implement additional monitoring to look for future related activity

Post-Incident Activity8. Create a follow-up report9. Hold a lessons learned meeting

(mandatory for major incidents, optional otherwise)

[Derived from NIST SP-800-61, Rev-2, Aug. 2012, p. 42]

Page A-2



APPENDIX BSAMPLE - DETAILED INCIDENT HANDLING FORM

The following report form contains the types of information and incident details that will be used to track and report security incidents for [Your Company Name]. The format of this report is subject to change as reporting standards and capabilities are further developed.

Date/Time of Report: _________________________ Page ___ of ___

Incident Contact InformationLast Name First Name

Job TitlePrimary Phone Alternate

PhoneMobile Phone FAXPrimary Email

Alternate Email

Incident DescriptionIncident Date, Time, & Recovery InformationDate/Time of First Event Date TimeDate/Time Incident Detected Date Time

Has Incident Ended? Yes NoDuration of Incident, as of this Report (in

hours)Estimated Severity of

Incident Low Medium High

Estimated Recovery Time, as of this Report (in clock

hours)

Estimated Recovery Time, as of this Report (in staff

hours)Estimated Damages ($$$

Loss), as of this ReportNumber of Host Systems

AffectedNumber of Endpoint Systems

AffectedNumber of User Accounts

AffectedType of Incident Detected Exposing Confidential/Classified/Sensitive Information Theft of IT Resources / Other Assets Creating User/System Accounts Altering Data (DNS / Website / Logs Destroying Data Anonymous FTP Abuse Denial of Service / Distributed Denial of Service Attack Credit/Debit Card Fraud

Page B-1



Incident Description Unauthorized Use/Access Other Fraud Using Company Computer Illegally Attacking the Internet Attacking Attackers / Other Sites Password Cracking Impersonation Network/System Sniffer Increasing Notoriety of Attacker Installing Malware (Virus / Trojan / etc.) Life-Threatening Activity Unknown

Other (Specify): ___________________________________________________________________

SB1386 – Is Email Notification Required? Yes NoSB1386 – Email Notification Sent Out? Yes No

Law Enforcement Notified? Yes NoComments

(Specify Incident Details and any additional, relevant

information)

General Incident InformationHow did You Initially Become Aware of the Incident? Automated Software Notification Automated Review of Log Files Manual Review of Log Files System Anomaly (i.e., crashes, slowness) Third Party Notification Unknown

Other (Specify): ___________________________________________________________________Attack Technique (Vulnerability Exploited / Exploit Used) Malware (Virus, Worm, Trojan Horse) Denial of Service / Distributed Denial of Service Scanning / Probing CVE / CERT-VU / BugTraq # _______________________________ Unauthorized Access to Affected Computer System(s)

Privileged User Compromise (Root/Admin Access) / User Account Compromise / Web Server Compromise Other (Specify): ___________________________________________________________________Suspected Perpetrator(s) or Possible Motivation(s) of Attack Current Employee / Contractor Former Employee / Contractor Third Party Vendor/Supplier External Party (within U.S.) External Party (outside of U.S.) Unknown

Other (Specify): ___________________________________________________________________

Page B-2



Malicious Software (Malware)Virus, Worm or Trojan HorseType of Malware: Virus Worm Trojan Horse

Name or DescriptionIs Anti-Malware Software Installed on

Affected Computer(s)? Yes

Specify: No

Did the Anti-Malware Software Detect the Infection?

Yes No

When was Anti-Malware Software Last Updated?

Network Activity SummaryName or Description of Exploit (if known)

Protocol(s) Targeted or Used TCP UDP FTP Telnet IPSec IPv6 ICMP SMTP IP Multicast SSL SSH RDP Other (Specify): _________________________________

Identify Source IP Addresses in the Incident

Identify Source Ports in the Incident

Identify Destination IP Subnet in the Incident

Identify Destination Ports in the Incident

Impact of Incident/AttackHosts Compromised (for more than 2 Hosts, use the “Bulk Hosts” section to list Host Names below and provide details on additional pages)Individual Host #1 Host Name

Does this Host Represent an Attacking or Victim Host?

Victim Attacker Both

Operating System Affected Patch LevelApplications Affected

Databases AffectedWeb Sites AffectedOther Host Impacts

Page B-3



Impact of Incident/AttackPrimary Purpose of This Host Application Server Database Server

Web Server Email Server FTP Server NFS/File Server Time Server Other Server Domain Name Server Domain Controller End User Laptop End User Desktop Infrastructure Device (i.e., router or firewall) Other (Specify) _____________________________

Individual Host #2 Host NameDoes this Host Represent an

Attacking or Victim Host? Victim Attacker Both

Operating System Affected Patch LevelApplications Affected

Databases AffectedWeb Sites AffectedOther Host Impacts

Primary Purpose of This Host Application Server Database Server Web Server Email Server FTP Server NFS/File Server Time Server Other Server Domain Name Server Domain Controller End User Laptop End User Desktop Infrastructure Device (i.e., router or firewall) Other (Specify) _____________________________

Bulk Hosts (more than 2) – List Host Names below and include above details on additional pages

Page B-4



Impact of Incident/AttackHost Names

Comments (provide any additional details about the Incident, not already captured)

Data CompromisedDid Incident Result in

Loss/Compromise of Sensitive or Personal Information?

Yes No Unknown

Comments

Did the Incident Result in Damage to System(s) or Data?

Yes (Specify) _______________________________ No Unknown

Comments

RemediationPlease detail/specify what corrective

actions have been taken for this Incident

Lesson Learned Information (Optional)Did your Detection & Response process and procedures work as intended? [Enter Comments Below]

Page B-5



Lesson Learned Information (Optional)

Provide any Discovery Methods, Indicators of Compromise, and/or Monitoring Procedures that would have improved your ability to detect an Intrusion. [Enter Comments Below]

Are there improvements to Procedures and Tools that would have aided you in the Response Process? [Enter Comments Below]

Are there improvements that would have enhanced your ability to contain an Intrusion? [Enter Comments Below]

Are there Corrective Procedures that would have improved your effectiveness in Recovering your systems? [Enter Comments Below]

Page B-6



APPENDIX CEXCERPTS FROM SEI’S INCIDENT MANAGEMENT CAPABILITY METRICS

© 2007. Carnegie Mellon University. (Refer to copyright statement at end of Appendix)

The following questions, within the four phases or categories of Incident Management and Response, were taken from the Software Engineering Institute’s Technical Report, Incident Management Capability Metrics, Version 0.1, issued in April 2007. SEI is a federally funded research and development center sponsored by the U.S. Department of Defense.

These questions are provided as general reference for the types of questions each organization should address when assessing the effectiveness and level of capability for their Incident Management Program or Computer Security Incident Response Plan.

Phase/Category: 0. General Metrics

0.1.1 - Have well-defined, formal interfaces for conducting agency incident management activities been established and maintained?

Phase/Category: 1. Protect

1.1.1 - Are Risk Assessments (RAs) performed on constituent systems?

1.1.2 - Are the constituents assisted with correcting problems identified by Risk Assessment (RA) activities?

1.1.3 - Is proactive vulnerability scanning (VS) performed on constituent networks and systems?

1.1.5 - Is trend analysis supported and conducted?

1.2.1 - Is there an institutionalized Malware/Anti-Virus (AV) Program?

1.3.1 - Are operational exercises conducted to assess the security posture of the organization?

1.4.1 - Is there a list of which systems, data, and information are mission critical?

1.4.3 - Are constituents provided with security education, training, and awareness (ETA)?

Page C-1



1.5.1 - Is there a patch alert and management program?

Phase/Category: 2. Detect

2.1.1 - Is there network security monitoring of constituent systems and networks?

2.2.1 - Are network and system configurations or rule sets reviewed and updated in response to changes in the threat environment, and are the constituents notified of the updates?

Phase/Category: 3. Respond

3.1.1 - Are incidents reported to and coordinated with appropriate external organizations or groups in accordance with organizational guidelines?

3.1.2 - Are incidents reported to appropriate organization management in accordance with organizational guidelines?

3.1.5 - Are incidents reported to law enforcement as required and/or the intelligence community as appropriate?

3.2.1 - Is there an event/incident handling capability?

3.2.2 - Is there an operations log or record of daily operational activity?

3.2.3 - Is information on all events/incidents collected and retained in support of future analytical efforts and situational awareness?

3.2.7 - Have trusted relationships been developed with other external experts (CERT/CC, FBI, vendors, other entities, etc.)?

3.3.1 - Is incident analysis conducted?

3.3.4 - Is incident correlation performed?

3.3.5 - Is forensics analysis performed on constituent systems and networks?

3.3.6 - Do the analytical processes incorporate methods to determine the risk or threat level of a confirmed incident?

Page C-2



Phase/Category: 4. Sustain

4.1.1 - Is there an incident management function or CSIRT designated by the organization head or CIO through an official appointment order?

4.2.1 - Is there a financial plan for incident management functions?

4.2.2 - Are there documented roles and responsibilities for key incident management activities throughout the organization?

4.2.3 - Is there a program management plan (workforce plan) for incident management personnel?

4.2.5 - Is there an established business resumption plan to support disaster recovery, reconstitution, and restoration efforts for incident management functions?

4.2.7 - Is the incident management IT infrastructure adequate to support incident management functions?

4.3.2 - Is there a process to monitor and review various forms of media to ensure that incident management personnel stay abreast of emerging technologies?

4.4.1 - Are there established ETA (education, training, & awareness) requirements and minimum competency levels incorporated into the training program for all personnel performing incident management activities?

4.5.1 - Are there physical protective measures in place to protect incident management IT systems, facilities, and personnel?

4.5.2 - Is there an operations security (OPSEC) program?

4.6.2 - Are there processes and technologies to support the confidentiality, integrity, and availability of incident management data and information?

4.6.4 - Are Risk Assessments (RAs) performed on incident management systems and networks?

4.6.5 - Are vulnerability scanning tools run on the incident management systems and networks?

4.6.6 - Is there a patch management program in place for the incident management systems?

Page C-3



4.6.7 - Is there an alternate communications system (other than email) for receiving and distributing notifications, information about incidents, and other kinds of warnings?

COPYRIGHT LEGAL NOTICES:

NO WARRANTY.

THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.

Page C-4



APPENDIX DCSIRT POINTS OF CONTACT LIST

The following list, when filled in, should be considered as “Confidential Information” and only available to CSIRT members and other authorized individuals as approved by [Your Company Name]’s executive team. When completing this list, the CISO or other responsible person must consider the inclusion of third party (external) IT service providers, as well as other trusted business partners, suppliers or vendors who have a valid “need to know” status. When including external CSIRT members, insert their company affiliation with the other information. The CISO should add CSIRT team members or others to the completed list, as necessary, depending on the company’s requirements. Company management, the CIO, CISO, and key IT managers should have a short list of critical contact numbers with job title/function (no names, to protect Personally Identifiable Information, “PII”) on a wallet-size card.

This list does not determine WHAT information (nature or extent) is shared with each person or entity, it merely provides the contact information. This list also does not determine WHEN the person or entity should be contacted or details of WHAT information can or should be shared – those requirements will be contained in contracts or operating agreements, security policies or procedures, non-disclosure agreements, etc.

[Note: Delete those positions or categories which do not apply to your organization and add or modify ones that do apply.]

Category or Position DescriptionCompany’s Primary Executive [Your Company Name] Owner or CEO

Full NamePrimary PhoneAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact

Chief Information Officer [Your Company Name] CIOFull NamePrimary PhoneAlternate PhonePager/Text Messaging

Page D-1



Category or Position DescriptionPrimary EmailSecondary EmailOther Method of Contact

Chief Financial Officer [Your Company Name] CFOFull NamePrimary PhoneAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact

Human Resources Director/Manager [Your Company Name] Head of Human Resources


Company Legal Counsel [Your Company Name] Legal Counsel (Attorney)


Cybersecurity Insurance Provider Cyber Insurance – Confidential Claims Representative

Insurance Company NameFull NamePosition/TitlePrimary Phone

Page D-2



Category or Position DescriptionAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact

Chief Information Security Officer [Your Company Name] CISO (CSIRT Leader)Full NamePrimary PhoneAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact

CSIRT Member – CISO’s Alternate Alternate CSIRT Leader – Alternate for CISOFull NamePosition/TitlePrimary PhoneAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact

CSIRT Member – Network Operations

Primary CSIRT Member

Full NamePosition/TitlePrimary PhoneAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact

CSIRT Member – Network Operations

Alternate CSIRT Member

Full Name

Page D-3



Category or Position DescriptionPosition/TitlePrimary PhoneAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact

CSIRT Member – Data Center Operations



CSIRT Member – Data Center Operations



CSIRT Member – Information Security


Full NamePosition/TitlePrimary PhoneAlternate PhonePager/Text MessagingPrimary Email

Page D-4



Category or Position DescriptionSecondary EmailOther Method of Contact

CSIRT Member – Information Security



CSIRT Member – Website Management



CSIRT Member – Website Management



CSIRT Member – Applications Management (Development/Support)


Full Name

Page D-5



Category or Position DescriptionPosition/TitlePrimary PhoneAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact

CSIRT Member – Applications Management (Development/Support)



CSIRT Member – Database Administration (DBA)



CSIRT Member – Database Administration (DBA)


Full NamePosition/TitlePrimary PhoneAlternate PhonePager/Text MessagingPrimary Email

Page D-6



Category or Position DescriptionSecondary EmailOther Method of Contact

CSIRT Member – Internet Services Provider(s) (ISPs)


Company NameFull NamePosition/TitlePrimary PhoneAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact

CSIRT Member – Internet Services Provider(s) (ISPs)



CSIRT Member – Cloud Services Provider(s) (CSPs)



Page D-7



Category or Position DescriptionCSIRT Member – Cloud Services Provider(s) (CSPs)



CSIRT Member – Managed Security Services Provider(s) (MSSPs)



CSIRT Member – Managed Security Services Provider(s) (MSSPs)



CSIRT Member – Company Operations (Functional Business Unit #1)

Primary CSIRT Member – [Operational Business Unit]

Page D-8



Category or Position DescriptionFull NamePosition/TitlePrimary PhoneAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact


Alternate CSIRT Member – [Operational Business Unit]







Full NamePosition/TitlePrimary Phone

Page D-9



Category or Position DescriptionAlternate PhonePager/Text MessagingPrimary EmailSecondary EmailOther Method of Contact







Page D-10

res.cloudinary.com · Web viewIt is the policy of [Your Company Name], that all computer security...

Documents

Transcript of res.cloudinary.com · Web viewIt is the policy of [Your Company Name], that all computer security...