System details are addressed in which section of the initial response check list

We recommend reading the purpose statement, introduction, overview, and suggestions for how to use the checklist before downloading a copy.

Purpose

To provide a toolkit that includes resources, procedures, and guidelines for the management of incidents involving the exposure of sensitive and/or personal information. Complementary to the Data Incident Notification Toolkit, this information can be referred to during the process of responding to incidents that create the need for such notification.

Introduction

The following information is intended to provide a general checklist of the steps that an institution might take when an incident involving sensitive data is discovered. Although each item is recommended as an effective practice, we recognize that state/local legal requirements, institutional policy, or campus culture might cause each institution to approach this process differently. State legislation regarding incident breach varies broadly and institutions should check with legal counsel in advance to ensure this checklist meets statutory need. Institutions will also be at varying stages of progress in their incident response management capabilities. Some will start with the need to establish actions in the areas of policies, processes, or tools, some will be ready to implement, and others will be able to revise and fine-tune their processes. This checklist can be helpful for all, as a review of readiness or as a roadmap for development.

Checklist Overview

The checklist consists of the five major steps described below, with sub-steps included for each.

Verify that an incident has actually occurred. This activity typically involves the Unit systems administrator and end user, but may also result from proactive incident detection work of the Security Office or central IT operations. If it is determined that an incident has occurred, inform appropriate authorities.

Identify an Incident Response Lead and assemble an incident response team charged with limiting further damage from the incident. Conduct a thorough assessment of the type and scope of data exposed following applicable laws, regulation and policy.

Take steps to remove the cause of the exposure, reduce the impact of the exposure of the sensitive data, restore operations if the incident compromised or otherwise put out of service a system or network, and ensure that future risk of exposure is mitigated.

Determine the need to give notice to individuals whose data may have been exposed by the incident. Swiftness in notifying those affected by a breach of personally identifiable information (PII), as well as informing certain government entities, is legally mandated in many states and, depending on the nature of the data, also federal law. Speed is also important from a public relations standpoint. To this end, many of the sub-steps can and should be undertaken in parallel to accommodate these needs.

Identify lessons learned from the incident, implement any remediation needs, and securely store a complete record of the incident.

How To Use

Depending upon the nature of the incident and size of the response team, it may be advisable and practical to address some of the checklist steps and sub-steps in parallel. For example, as soon as the cause of an incident is determined (Step 2.6), eradication of that cause and recovery of the function it put out of service (Step 3) could commence while documentation activities of Step 2.7 are being addressed. The potential for multitasking incident steps and sub-steps is depicted in thisworkflow.

In ways similar to emergency preparedness planning, it is wise to periodically practice the institution's security incident response readiness in advance of actual events. Lessons learned should be incorporated as needed into the checklist, response procedures, and/or resource allocations.

The checklist includes actions needed to address the most serious of security incidents, i.e. the exposure of personally identifiable information (PII) protected by laws, industry standards, and/or contracts with parties external to the institution. It can also be used effectively to address other security incident types, e.g., defacement of public websites, unauthorized access to confidential but not legally protected data, or the loss of confidential paper records.

As helpful as we hope this checklist will be, it is important to consider that:

• Breach notification requirements are dictated by laws and industry standards that have and will continue to change over time. Contracts with third parties, such as, research fund granting organizations, may also bound institutions to additional notification requirements. This checklist includes requirements for the most broadly applicable regulations, e.g. Payment Card Industry Data Security Standards, the Health Insurance Portability and Accountability Act, and the Family Educational Rights and Privacy Act. For the stated reasons, however, there may be other requirements institutions will need to incorporate.
• Given the trend toward increased use of external third parties, including cloud computing vendors, for providing services that use, collect, store, and/or process institutional data, institutions must take into account the shared responsibilities for incident response often necessitated by such arrangements. This checklist provides steps that must occur regardless of the location of a potential data breach. Who should assume responsibility for each of those step when a third party is involved will vary depending upon the nature of the external service provided, as well as the security-related terms of the contract between the institution and that party.
  

Training and Tools

In addition to establishing a coordinated, repeatable process for incident response (which this checklist facilitates), access to trained technical professionals and tools are also needed for effective incident response. While there is an abundance of security consulting firms available to supply these needs, institutions may find it more cost-effective to train and equip their own staffs to address incidents on an ongoing basis.

Training – There are many good sources of both management and technical training in computer incident handling techniques. The SANS Institute, for example, provides a number of courses (at this writing, six on the specialty of computer forensics alone). Training is also offered by some academic institutions and, of course, by many technical training vendors.

Tools – Likewise, there is a wide range of incident response tools from both commercial and open source origins. Categories include but are not limited to:

• Scanning tools – These identify incident artifacts and/or characteristics of vulnerabilities that help gauge the scope of a given incident. Examples are: OS fingerprinting, TCP/UDP port scanning, and software vulnerability scanning.
• Acquisition tools – These copy data in pristine condition for later analysis. The scope of acquisition sits on a broad range: from a single file, to random access memory, to entire hard drive, and so on.
• Analysis tools – These help determine the behavior of unwanted activity, e.g., malicious insider activity and malware, so that conclusions can be reached regarding impact and needed remediation actions. A few examples are security event log analysis tools, network traffic analysis tools, and specialized tools that detect certain image characteristics(like pornographic material), or text format characteristics( like Social Security or credit card numbers).
• Reporting tools – These facilitate tagging and reporting of evidence in various formats suitable for the incident response team, management, law enforcement, and others.
• Workflow and documentation tools – These track every step in the incident response process, from initial report through resolution. Some also facilitate collection and storage of documentation at each step, as well as provide historical data needed to generate incident-related metrics.

Incident response tools in these and other categories are generally available as single products, although they might also be included in integrated product suites that seek to provide incident responders with a common "workbench" of tools from multiple categories. Additionally, these tools might be featured in products having much broader purposes than simply incident response. For example, products that facilitate governance, risk, and compliance process, i.e., GRC systems, typically include an incident/issue workflow and documentation component.

Additional Resources

Download the Checklist

The Sensitive Data Exposure Incident Checklist is available to download and print in Word or PDF format. The 12-page checklist includes all five steps and sub-steps.

Questions or comments? Contact us.

Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0).

What are the 5 stages of the incident management process?

What are the sections of an incident response plan?

What are the 4 phases of incident response in chronological order?

What are the 7 steps in incident response?