Chapter 11

Cybersecurity Incident Response

Incidents happen. Security-related incidents have become not only more numerous and diverse but also more damaging and disruptive. A single incident can cause the demise of an entire organization. In general terms, incident management is defined as a predicable response to damaging situations. It is vital that organizations have the practiced capability to respond quickly, minimize harm, comply with breach-related state laws and federal regulations, and maintain their composure in the face of an unsettling and unpleasant experience.

Incident preparedness includes having policies, strategies, plans, and procedures. Organizations should create written guidelines, have supporting documentation prepared, train personnel, and engage in mock exercises. An actual incident is not the time to learn. Incident handlers must act quickly and make far-reaching decisions—often while dealing with uncertainty and incomplete information. They are under a great deal of stress. The more prepared they are, the better the chance that sound decisions will be made.

Computer security incident response is a critical component of information technology (IT) programs. The incident response process and incident handling activities can be very complex. To establish a successful incident response program, you must dedicate substantial planning and resources. Several industry resources were created to help organizations establish a computer security incident response program and learn how to handle cybersecurity incidents efficiently and effectively. One of the best resources available is NIST Special Publication 800-61, which can be obtained from the following URL:

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

NIST developed Special Publication 800-61 due to statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

The benefits of having a practiced incident response capability include the following:

• Calm and systematic response

• Minimization of loss or damage

• Protection of affected parties

• Compliance with laws and regulations

• Preservation of evidence

• Integration of lessons learned

• Lower future risk and exposure

Not all security incidents are the same. For example, a breach of personally identifiable information (PII) typically requires strict disclosure under many circumstances. The OMB Memorandum M-07-16, “Safeguarding Against and Responding to the Breach of Personally Identifiable Information,” requires Federal agencies to develop and implement a breach notification policy for PII. Another example is Article 33 of the GDPR, “Notification of a personal data breach to the supervisory authority,” which specifies that any organization under regulation must report a data breach within 72 hours. NIST defines a privacy breach as follows: “when sensitive PII of taxpayers, employees, beneficiaries, etc. was accessed or exfiltrated.” NIST also defines a proprietary breach as when “unclassified proprietary information, such as protected critical infrastructure information (PCII), was accessed or exfiltrated.” An integrity breach is when sensitive or proprietary information was changed or deleted.

Before you learn the details about how to create a good incident response program within your organization, you must understand the difference between security events and security incidents. The following is from NIST Special Publication 800-61:

“An event is any observable occurrence in a system or network. Events include 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. 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.”

According to the same document, “a computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.”

The definition and criteria should be codified in policy. Incident management extends to third-party environments. As we discussed in Chapter 8, “Communications and Operations Security,” business partners and vendors should be contractually obligated to notify the organization if an actual or suspected incident occurs.

Table 11-1 lists a few examples of cybersecurity incidents.

Although any number of events could result in an incident, a core group of attacks or situations are most common. Every organization should understand and be prepared to respond to intentional unauthorized access, distributed denial of service (DDoS) attacks, malicious code (malware), and inappropriate usage.

People frequently fail to report potential incidents because they are afraid of being wrong and looking foolish, they do not want to be seen as a complainer or whistleblower, or they simply don’t care enough and would prefer not to get involved. These objections must be countered by encouragement from management. Employees must be assured that even if they were to report a perceived incident that ended up being a false positive, they would not be ridiculed or met with annoyance. On the contrary, their willingness to get involved for the greater good of the company is exactly the type of behavior the company needs! They should be supported for their efforts and made to feel valued and appreciated for doing the right thing.

Digital forensic evidence is information in digital form found on a wide range of endpoint, server, and network devices—basically, any information that can be processed by a computing device or stored on other media. Evidence tendered in legal cases, such as criminal trials, is classified as witness testimony or direct evidence, or as indirect evidence in the form of an object, such as a physical document, the property owned by a person, and so forth.

Cybersecurity forensic evidence can take many forms, depending on the conditions of each case and the devices from which the evidence was collected. To prevent or minimize contamination of the suspect’s source device, you can use different tools, such as a piece of hardware called a write blocker, on the specific device so you can copy all the data (or an image of the system).

The imaging process is intended to copy all blocks of data from the computing device to the forensics professional evidentiary system. This is sometimes referred to as a “physical copy” of all data, as distinct from a “logical copy,” which copies only what a user would normally see. Logical copies do not capture all the data, and the process will alter some file metadata to the extent that its forensic value is greatly diminished, resulting in a possible legal challenge by the opposing legal team. Therefore, a full bit-for-bit copy is the preferred forensic process. The file created on the target device is called a forensic image file.

Chain of custody is the way you document and preserve evidence from the time that you started the cyber forensics investigation to the time the evidence is presented in court. It is extremely important to be able to show clear documentation of the following:

• How the evidence was collected

• When it was collected

• How it was transported

• How is was tracked

• How it was stored

• Who had access to the evidence and how it was accessed

A method often used for evidence preservation is to work only with a copy of the evidence—in other words, you do not want to work directly with the evidence itself. This involves creating an image of any hard drive or any storage device. Additionally, you must prevent electronic static or other discharge from damaging or erasing evidentiary data. Special evidence bags that are antistatic should be used to store digital devices. It is very important that you prevent electrostatic discharge (ESD) and other electrical discharges from damaging your evidence. Some organizations even have cyber forensic labs that control access to only authorized users and investigators. One method often used involves constructing what is called a Faraday cage. This cage is often built out of a mesh of conducting material that prevents electromagnetic energy from entering into or escaping from the cage. Also, this prevents devices from communicating via Wi-Fi or cellular signals.

What’s more, transporting the evidence to the forensics lab or any other place, including the courthouse, has to be done very carefully. It is critical that the chain of custody be maintained during this transport. When you transport the evidence, you should strive to secure it in a lockable container. It is also recommended that the responsible person stay with the evidence at all times during transportation.

Section 2.3 of NIST Special Publication 800-61 Revision 2 goes over the incident response policies, plans, and procedures, including information on how to coordinate incidents and interact with outside parties. The policy elements described in NIST Special Publication 800-61 Revision 2 include the following:

• Statement of management commitment

• Purpose and objectives of the incident response policy

• The scope of the incident response policy

• Definition of computer security incidents and related terms

• Organizational structure and definition of roles, responsibilities, and levels of authority

• Prioritization or severity ratings of incidents

• Performance measures

• Reporting and contact forms

NIST’s incident response plan elements include the following:

• Incident response plan’s mission

• Strategies and goals of the incident response plan

• Senior management approval of the incident response plan

• Organizational approach to incident response

• How the incident response team will communicate with the rest of the organization and with other organizations

• Metrics for measuring the incident response capability and its effectiveness

• Roadmap for maturing the incident response capability

• How the program fits into the overall organization

NIST also defines standard operating procedures (SOPs) as “a delineation of the specific technical processes, techniques, checklists, and forms used by the incident response team. SOPs should be reasonably comprehensive and detailed to ensure that the priorities of the organization are reflected in response operations.” You learned details about SOP in Chapter 8, “Communications and Operations Security.”

NIST defines the major phases of the incident response process as illustrated in Figure 11-1.

• Creating processes for incident handler communications and the facilities that will host the security operation center (SOC) and incident response team

• Making sure that the organization has appropriate incident analysis hardware and software as well as incident mitigation software

• Creating risk assessment capabilities within the organization

• Making sure the organization has appropriately deployed host security, network security, and malware prevention solutions

• Developing user awareness training

• Profile networks and systems

• Understand normal behaviors

• Create a log retention policy

• Perform event correlation

• Maintain and use a knowledge base of information

• Use Internet search engines for research

• Run packet sniffers to collect additional data

• Filter the data

• Seek assistance from others

• Keep all host clocks synchronized

• Know the different types of attacks and attack vectors

• Develop processes and procedures to recognize the signs of an incident

• Understand the sources of precursors and indicators

• Create appropriate incident documentation capabilities and processes

• Create processes to effectively prioritize security incidents

• Create processes to effectively communicate incident information (internal and external communications)

• Evidence gathering and handling

• Identifying the attacking hosts

• Choosing a containment strategy to effectively contain and eradicate the attack, as well as to successfully recover from it

NIST Special Publication 800-61 Revision 2 also defines the following criteria for determining the appropriate containment, eradication, and recovery strategy:

• The potential damage to and theft of resources

• The need for evidence preservation

• Service availability (for example, network connectivity as well as services provided to external parties)

• Time and resources needed to implement the strategy

• Effectiveness of the strategy (for example, partial containment or full containment)

• Duration of the solution (for example, emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, or permanent solution)

• Exactly what happened, and at what times?

• How well did the staff and management perform while 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 be improved?

• What corrective actions can prevent similar incidents in the future?

• 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?

• Report identification

• Objective statement

• Result analysis

• Data query/code

• Analyst comments/notes

There are significant long-term advantages for having relevant and effective playbooks. When developing playbooks, focus on organization and clarity within your own framework. Having a playbook and detection logic is not enough. The playbook is only a proactive plan. Your plays must actually run to generate results, those results must be analyzed, and remedial actions must be taken for malicious events. This is why tabletop exercises are very important.

Table-top exercises could be technical and also at the executive level. You can create technical simulations for your incident response team and also risk-based exercises for your executive and management staff. A simple methodology for an incident response tabletop exercise includes the following steps:

1. Preparation: Identify the audience, what you want to simulate, and how the exercise will take place.

2. Execution: Execute the simulation and record all findings to identify all areas for improvement in your program.

3. Report: Create a report and distribute it to all the respective stakeholders. Narrow your assessment to specific facets of incident response. You can compare the results with the existing incident response plans. You should also measure the coordination among different teams within the organization and/or external to the organization. Provide a good technical analysis and identify gaps.

Your incident response plan should account for these types of interactions with outside entities. It should also include information about how to interact with your organization’s public relations (PR) department, legal department, and upper management. You should also get their buy-in when sharing information with outside parties to minimize the risk of information leakage. In other words, avoid leaking sensitive information regarding security incidents with unauthorized parties. These actions could potentially lead to additional disruption and financial loss. You should also maintain a list of all the contacts at those external entities, including a detailed list of all external communications for liability and evidentiary purposes.

• Product Security Incident Response Team (PSIRT)

• National CSIRT and Computer Emergency Response Team (CERT)

• Coordination center

• The incident response team of a security vendor and Managed Security Service Provider (MSSP)

In this section, you learn about CSIRTs. The rest of the incident response team types are covered in the subsequent sections in this chapter.

The CSIRT is typically the team that works hand in hand with the information security teams (often called InfoSec). In smaller organizations, InfoSec and CSIRT functions may be combined and provided by the same team. In large organizations, the CSIRT focuses on the investigation of computer security incidents, whereas the InfoSec team is tasked with the implementation of security configurations, monitoring, and policies within the organization.

Establishing a CSIRT involves the following steps:

STEP 1. Defining the CSIRT constituency.

STEP 2. Ensuring management and executive support.

STEP 3. Making sure that the proper budget is allocated.

STEP 4. Deciding where the CSIRT will reside within the organization’s hierarchy.

STEP 5. Determining whether the team will be central, distributed, or virtual.

STEP 6. Developing the process and policies for the CSIRT.

It is important to recognize that every organization is different, and these steps can be accomplished in parallel or in sequence. However, defining the constituency of a CSIRT is certainly one of the first steps in the process. When defining the constituency of a CSIRT, one should answer the following questions:

• Who will be the “customer” of the CSIRT?

• What is the scope? Will the CSIRT cover only the organization or also entities external to the organization? For example, at Cisco, all internal infrastructure and Cisco’s websites and tools (that is, cisco.com) are a responsibility of the Cisco CSIRT, and any incident or vulnerability concerning a Cisco product or service is the responsibility of the Cisco PSIRT.

• Will the CSIRT provide support for the complete organization or only for a specific area or segment? For example, an organization may have a CSIRT for traditional infrastructure and IT capabilities and a separate one dedicated to cloud security.

• Will the CSIRT be responsible for part of the organization or all of it? If external entities will be included, how will they be selected?

Determining the value of a CSIRT can be challenging. One of the main questions that executives will ask is, what is the return on investment for having a CSIRT? The main goals of the CSIRT are to minimize risk, contain cyber damage, and save money by preventing incidents from happening—and when they do occur, to mitigate them efficiently. For example, the smaller the scope of the damage, the less money you need to spend to recover from a compromise (including brand reputation). Many studies in the past have covered the cost of security incidents and the cost of breaches. Also, the Ponemon Institute periodically publishes reports covering these costs. It is a good practice to review and calculate the “value add” of the CSIRT. This calculation can be used to determine when to invest more, not only in a CSIRT, but also in operational best practices. In some cases, an organization might even outsource some of the cybersecurity functions to a managed service provider, if the organization cannot afford or retain security talent.

An incident response team must have several basic policies and procedures in place to operate satisfactorily, including the following:

• Incident classification and handling

• Information classification and protection

• Information dissemination

• Record retention and destruction

• Acceptable usage of encryption

• Engaging and cooperating with external groups (other IRTs, law enforcement, and so on)

Also, some additional policies or procedures can be defined, such as the following:

• Hiring policy

• Using an outsourcing organization to handle incidents

• Working across multiple legal jurisdictions

Even more policies can be defined depending on the team’s circumstances. The important thing to remember is that not all policies need to be defined on the first day.

The following are great sources of information from the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) that you can leverage when you are constructing your policy and procedure documents:

• ISO/IEC 27001:2005: “Information Technology—Security Techniques—Information Security Management Systems—Requirements”

• ISO/IEC 27002:2005: “Information Technology—Security Techniques—Code of Practice for Information Security Management”

• ISO/IEC 27005:2008: “Information Technology—Security techniques—Information Security Risk Management”

• ISO/PAS 22399:2007: “Societal Security—Guidelines for Incident Preparedness and Operational Continuity Management”

• ISO/IEC 27033: “Information Technology—Security Techniques—Information Security Incident Management”

CERT provides a good overview of the goals and responsibilities of a CSIRT at the following site: https://www.cert.org/incident-management/csirt-development/csirt-faq.cfm.

The U.S. National Institute of Standards and Technology (NIST) defines a security vulnerability as follows:

“A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.”

There are many more definitions, but they tend to be variations on the one from the NIST.

CVSS is an industry standard maintained by FIRST that is used by many PSIRTs to convey information about the severity of vulnerabilities they disclose to their customers.

In CVSS, a vulnerability is evaluated under three aspects and a score is assigned to each of them:

• The base group represents the intrinsic characteristics of a vulnerability that are constant over time and do not depend on a user-specific environment. This is the most important information and the only one that’s mandatory to obtain a vulnerability score.

• The temporal group assesses the vulnerability as it changes over time.

• The environmental group represents the characteristics of a vulnerability, taking into account the organizational environment.

The score for the base group is between 0 and 10, where 0 is the least severe and 10 is assigned to highly critical vulnerabilities. For example, a highly critical vulnerability could allow an attacker to remotely compromise a system and get full control. Additionally, the score comes in the form of a vector string that identifies each of the components used to make up the score.

The formula used to obtain the score takes into account various characteristics of the vulnerability and how the attacker is able to leverage these characteristics.

CVSSv3 defines several characteristics for the base, temporal, and environmental groups.

The base group defines Exploitability metrics that measure how the vulnerability can be exploited, as well as Impact metrics that measure the impact on confidentiality, integrity, and availability. In addition to these two metrics, a metric called Scope Change (S) is used to convey impact on systems that are impacted by the vulnerability but do not contain vulnerable code.

The Exploitability metrics include the following:

• Attack Vector (AV) represents the level of access an attacker needs to have to exploit a vulnerability. It can assume four values:

  • Network (N)

  • Adjacent (A)

  • Local (L)

  • Physical (P)

• Attack Complexity (AC) represents the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. The values can be the following:

  • Low (L)

  • High (H)

• Privileges Required (PR) represents the level of privileges an attacker must have to exploit the vulnerability. The values are as follows:

  • None (N)

  • Low (L)

  • High (H)

• User Interaction (UI) captures whether a user interaction is needed to perform an attack. The values are as follows:

  • None (N)

  • Required (R)

• Scope (S) captures the impact on systems other than the system being scored. The values are as follows:

  • Unchanged (U)

  • Changed (C)

The Impact metrics include the following:

• Confidentiality (C) measures the degree of impact to the confidentiality of the system. It can assume the following values:

  • Low (L)

  • Medium (M)

  • High (H)

• Integrity (I) measures the degree of impact to the integrity of the system. It can assume the following values:

  • Low (L)

  • Medium (M)

  • High (H)

• Availability (A) measures the degree of impact to the availability of the system. It can assume the following values:

  • Low (L)

  • Medium (M)

  • High (H)

The temporal group includes three metrics:

• Exploit Code Maturity (E), which measures whether or not public exploit is available

• Remediation Level (RL), which indicates whether a fix or workaround is available

• Report Confidence (RC), which indicates the degree of confidence in the existence of the vulnerability

The environmental group includes two main metrics:

• Security Requirements (CR, IR, AR), which indicate the importance of confidentiality, integrity, and availability requirements for the system

• Modified Base Metrics (MAV, MAC, MAPR, MUI, MS, MC, MI, MA), which allow the organization to tweak the base metrics based on specific characteristics of the environment

For example, a vulnerability that might allow a remote attacker to crash the system by sending crafted IP packets would have the following values for the base metrics:

• Access Vector (AV) would be Network because the attacker can be anywhere and can send packets remotely.

• Attack Complexity (AC) would be Low because it is trivial to generate malformed IP packets (for example, via the Scapy Python tool).

• Privilege Required (PR) would be None because there are no privileges required by the attacker on the target system.

• User Interaction (UI) would also be None because the attacker does not need to interact with any user of the system to carry out the attack.

• Scope (S) would be Unchanged if the attack does not cause other systems to fail.

• Confidentiality Impact (C) would be None because the primary impact is on the availability of the system.

• Integrity Impact (I) would be None because the primary impact is on the availability of the system.

• Availability Impact (A) would be High because the device could become completely unavailable while crashing and reloading.

Additional examples of CVSSv3 scoring are available at the FIRST website (https://www.first.org/cvss).

Performing vulnerability chaining analysis is not a trivial task. Although several commercial companies claim that they can easily perform chaining analysis, in reality the methods and procedures that can be included as part of a chain vulnerability analysis are pretty much endless. PSIRT teams should utilize an approach that works for them to achieve the best end result.

In some cases, users call vulnerabilities without exploits “theoretical vulnerabilities.” One of the biggest challenges with “theoretical vulnerabilities” is that there are many smart people out there capable of exploiting them. If you do not know how to exploit a vulnerability today, it does not mean that someone else will not find a way in the future. In fact, someone else may already have found a way to exploit the vulnerability and perhaps is even selling the exploit of the vulnerability in underground markets without public knowledge.

PSIRT personnel should understand there is no such thing as an “entirely theoretical” vulnerability. Sure, having a working exploit can ease the reproducible steps and help to verify whether that same vulnerability is present in different systems. However, because an exploit may not come as part of a vulnerability, you should not completely deprioritize it.

The dream of any vendor is to be able to find and patch all security vulnerabilities during the design and development phases. However, that is close to impossible. On the other hand, that is why a secure development life cycle (SDL) is extremely important for any organization that produces software and hardware. Cisco has an SDL program that is documented at the following URL: www.cisco.com/c/en/us/about/security-center/security-programs/secure-development-lifecycle.html.

Cisco defines its SDL as “a repeatable and measurable process we’ve designed to increase the resiliency and trustworthiness of our products.” Cisco’s SDL is part of Cisco Product Development Methodology (PDM) and ISO 9000 compliance requirements. It includes, but is not limited to, the following:

• Base product security requirements

• Third-party software (TPS) security

• Secure design

• Secure coding

• Secure analysis

• Vulnerability testing

The goal of the SDL is to provide tools and processes that are designed to accelerate the product development methodology, by developing secure, resilient, and trustworthy systems. TPS security is one of the most important tasks for any organization. Most of today’s organizations use open source and third-party libraries. This approach creates two requirements for the product security team. The first is to know what TPS libraries are used, reused, and where. The second is to patch any vulnerabilities that affect such library or TPS components. For example, if a new vulnerability in OpenSSL is disclosed, what do you have to do? Can you quickly assess the impact of such a vulnerability in all your products?

If you include commercial TPS, is the vendor of such software transparently disclosing all the security vulnerabilities, including in their software? Nowadays, many organizations are including security vulnerability disclosure SLAs in their contracts with third-party vendors. This is very important because many TPS vulnerabilities (both commercial and open source) go unpatched for many months—or even years.

TPS software security is a monumental task for any company of any size. To get a feeling of the scale of TPS code usage, visit the third-party security bulletins published by Cisco at https://tools.cisco.com/security/center/publicationListing.x?product=NonCisco#~Vulnerabilities. Another good resource is CVE Details (www.cvedetails.com).

Many tools are available on the market today to enumerate all open source components used in a product. These tools either interrogate the product source code or scan binaries for the presence of TPS. The following are a few examples:

• BlackDuck by Synopsys Software: https://www.blackducksoftware.com

• Synopsys Protecode (formerly known as AppCheck): https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html

• Palamida: www.palamida.com

• SRC:CLR: https://www.sourceclear.com

These national CERTS and CSIRTs aim to protect their citizens by providing security vulnerability information, security awareness training, best practices, and other information. For example, the following is the US-CERT mission posted at https://www.us-cert.gov/about-us:

“US-CERT’s critical mission activities include:

• Providing cybersecurity protection to Federal civilian executive branch agencies through intrusion detection and prevention capabilities.

• Developing timely and actionable information for distribution to federal departments and agencies; state, local, tribal and territorial (SLTT) governments; critical infrastructure owners and operators; private industry; and international organizations.

• Responding to incidents and analyzing data about emerging cyber threats.

• Collaborating with foreign governments and international entities to enhance the nation’s cybersecurity posture.”

One of the best examples is the CERT Division of the Software Engineering Institute (SEI). CERT provides security vulnerability coordination and research. It is an important stakeholder of multi-vendor security vulnerability disclosures and coordination. Additional information about CERT can be obtained at their website at https://www.sei.cmu.edu/about/divisions/cert/index.cfm#cert-division-what-we-do.

The following are examples of these teams and their services:

• The Cisco Incident Response Service: Provides Cisco customers with readiness or proactive services and post-breach support. The proactive services include infrastructure breach preparedness assessments, security operations readiness assessments, breach communications assessment, and security operations and incident response training. The post-breach (or reactive) services include the evaluation and investigation of the attack, countermeasure development and deployment, as well as the validation of the countermeasure effectiveness.

• FireEye Incident Response Services.

• Crowdstrike Incident Response Services.

• SecureWorks Managed Security Services.

• Cisco’s Active Threat Analytics (ATA) managed security service.

Managed services, such as the SecureWorks Managed Security Services, Cisco ATA, and others, offer customers 24-hour continuous monitoring and advanced-analytics capabilities, combined with threat intelligence as well as security analysts and investigators to detect security threats in customer networks. Outsourcing has long been a practice for many companies, but the onset of the complexity of cybersecurity has allowed it to bloom and become bigger as the years go by in the world of incident response.

The incident response coordinator (IRC) is the central point of contact for all incidents. Incident reports are directed to the IRC. The IRC verifies and logs the incident. Based on predefined criteria, the IRC notifies appropriate personnel, including the designated incident handler (DIH). The IRC is a member of the incident response team (IRT) and is responsible for maintaining all non-evidence-based incident-related documentation.

Designated incident handlers (DIHs) are senior-level personnel who have the crisis management and communication skills, experience, knowledge, and stamina to manage an incident. DIHs are responsible for three critical tasks: incident declaration, liaison with executive management, and managing the incident response team (IRT).

The incident response team (IRT) is a carefully selected and well-trained team of professionals that provides services throughout the incident life cycle. Depending on the size of the organization, there may be a single team or multiple teams, each with its own specialty. The IRT members generally represent a cross-section of functional areas, including senior management, information security, information technology (IT), operations, legal, compliance, HR, public affairs and media relations, customer service, and physical security. Some members may be expected to participate in every response effort, whereas others (such as compliance) may restrict involvement to relevant events. The team as directed by the DIH is responsible for further analysis, evidence handling and documentation, containment, eradication and recovery, notification (as required), and post-incident activities.

Tasks assigned to the IRT include but are not limited to the following:

• Overall management of the incident

• Triage and impact analysis to determine the extent of the situation

• Development and implementation of containment and eradication strategies

• Compliance with government and/or other regulations

• Communication and follow-up with affected parties and/or individuals

• Communication and follow-up with other external parties, including the Board of Directors, business partners, government regulators (including federal, state, and other administrators), law enforcement, representatives of the media, and so on, as needed

• Root cause analysis and lessons learned

• Revision of policies/procedures necessary to prevent any recurrence of the incident

Figure 11-2 illustrates the incident response roles and responsibilities.

• How was the incident detected?

• What is the scenario for the incident?

• What time did the incident occur?

• Who or what reported the incident?

• Who are the contacts for involved personnel?

• A brief description of the incident.

• Snapshots of all on-scene conditions.

All ongoing incident response–related activity should be logged and time-stamped. In addition to actions taken, the log should include decisions, record of contact (internal and external resources), and recommendations.

Documentation specific to computer-related activity should be kept separate from general documentation because of the confidential nature of what is being performed and/or found. All documentation should be sequential and time/date stamped, and should include exact commands entered into systems, results of commands, actions taken (for example, logging on, disabling accounts, applying router filters) as well as observations about the system and/or incident. Documentation should occur as the incident is being handled, not after.

Incident documentation should not be shared with anyone outside the team without the express permission of the DIH or executive management. If there is any expectation that the network has been compromised, documentation should not be saved on a network-connected device.

If the decision is made to contact law enforcement, it is important to do so as early in the response life cycle as possible while the trail is still hot. On a federal level, both the Secret Service and the Federal Bureau of Investigation (FBI) investigate cyber incidents. The Secret Service’s investigative responsibilities extend to crimes that involve financial institution fraud, computer and telecommunications fraud, identity theft, access device fraud (for example, ATM or point of sale systems), electronic funds transfers, money laundering, corporate espionage, computer system intrusion, and Internet-related child pornography and exploitation. The FBI’s investigation responsibilities include cyber-based terrorism, espionage, computer intrusions, and major cyber fraud. If the missions appear to overlap, it is because they do. Generally, it is best to reach out to the local Secret Service or FBI office and let them determine jurisdiction.

As described in NIST Special Publication 800-87, the process for performing digital forensics includes collection, examination, analysis, and reporting:

• Collection: The first phase in the process is to identify, label, record, and acquire data from the possible sources of relevant data, while following guidelines and procedures that preserve the integrity of the data. Collection is typically performed in a timely manner because of the likelihood of losing dynamic data, such as current network connections, as well as losing data from battery-powered devices.

• Examination: Examinations involve forensically processing large amounts of collected data using a combination of automated and manual methods to assess and extract data of particular interest, while preserving the integrity of the data.

• Analysis: The next phase of the process is to analyze the results of the examination, using legally justifiable methods and techniques, to derive useful information that addresses the questions that were the impetus for performing the collection and examination.

• Reporting: The final phase is reporting the results of the analysis, which may include describing the actions used, explaining how tools and procedures were selected, determining what other actions need to be performed, and providing recommendations for improvement to policies, guidelines, procedures, tools, and other aspects of the forensic process. The formality of the reporting step varies greatly depending on the situation.

Incident handlers performing forensic tasks need to have a reasonably comprehensive knowledge of forensic principles, guidelines, procedures, tools, and techniques, as well as antiforensic tools and techniques that could conceal or destroy data. It is also beneficial for incident handlers to have expertise in information security and specific technical subjects, such as the most commonly used operating systems, file systems, applications, and network protocols within the organization. Having this type of knowledge facilitates faster and more effective responses to incidents. Incident handlers also need a general, broad understanding of systems and networks so that they can determine quickly which teams and individuals are well suited to providing technical expertise for particular forensic efforts, such as examining and analyzing data for an uncommon application.

To maintain an evidentiary chain, a detailed log should be maintained that includes the following information:

• Where and when (date and time) evidence was discovered.

• Identifying information such as the location, serial number, model number, host name, media access control (MAC) address, and/or IP address.

• Name, title, and phone number of each person who discovered, collected, handled, or examined the evidence.

• Where evidence was stored/secured and during what time period.

• If the evidence has changed custody, how and when the transfer occurred (include shipping numbers, and so on).

The relevant person should sign and date each entry in the record.

Evidence needs to be retained until all legal actions have been completed. Legal action could be civil, criminal, regulatory, or personnel-related. Evidence-retention parameters should be documented in policy. Retention schedules should include the following categories: internal only, civil, criminal, regulatory, personnel-related incident, and to-be-determined (TBD). When categorization is in doubt, legal counsel should be consulted. If there is an organizational retention policy, a notation should be included that evidence-retention schedules (if longer) supersede operational or regulatory retention requirements.

A data breach is widely defined as an incident that results in compromise, unauthorized disclosure, unauthorized acquisition, unauthorized access, or unauthorized use or loss of control of legally protected PII, including the following:

• Any information that can be used to distinguish or trace an individual’s identity, such as name, SSN, date and place of birth, mother’s maiden name, or biometric records.

• Any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.

• Information that is standing alone is not generally considered personally identifiable, because many people share the same trait, such as first or last name, country, state, ZIP code, age (without birth date), gender, race, or job position. However, multiple pieces of information, none of which alone may be considered personally identifiable, may uniquely identify a person when brought together.

Incidents resulting in unauthorized access to PII are taken seriously because the information can be used by criminals to make false identification documents (including drivers’ licenses, passports, and insurance certificates), make fraudulent purchases and insurance claims, obtain loans or establish lines of credit, and apply for government and military benefits.

As we will discuss, the laws vary and sometimes even conflict in their requirements regarding the right of the individual to be notified, the manner in which they must be notified, and the information to be provided. What is consistent, however, is that notification requirements apply regardless of whether an organization stores and manages its data directly or through a third party, such as a cloud service provider.

The VERIS Community Database (VCDB) is an initiative that was launched to catalog security incidents in the public domain. VCDB contains raw data for thousands of security incidents shared under a creative commons license. You can download the latest release, follow the latest changes, and even help catalog and code incidents to grow the database at GitHub at: https://github.com/vz-risk/VCDB.

Customer notice should be given in a clear and conspicuous manner. The notice should include the following items:

• Description of the incident

• Type of information subject to unauthorized access

• Measures taken by the institution to protect customers from further unauthorized access

• Telephone number that customers can call for information and assistance

• A reminder to customers to remain vigilant over the next 12 to 24 months and to report suspected identity theft incidents to the institution

The guidance encourages financial institutions to notify the nationwide consumer reporting agencies prior to sending notices to a large number of customers that include contact information for the reporting agencies.

Customer notices are required to be delivered in a manner designed to ensure that a customer can reasonably be expected to receive them. For example, the institution may choose to contact all customers affected by telephone, by mail, or by electronic mail (for those customers for whom it has a valid email address and who have agreed to receive communications electronically).

Financial institutions must notify their primary federal regulator as soon as possible when the institution becomes aware of an incident involving unauthorized access to or use of nonpublic customer information. Consistent with the agencies’ Suspicious Activity Report (SAR) regulations, institutions must file a timely SAR. In situations involving federal criminal violations requiring immediate attention, such as when a reportable violation is ongoing, institutions must promptly notify appropriate law enforcement authorities. Reference Chapter 12, “Business Continuity Management,” for further discussion of financial institution–related security incidents.

The notification must be made without unreasonable delay and no later than 60 days after the discovery of the breach. The covered entity must also provide notice to “prominent media outlets” if the breach affects more than 500 individuals in a state or jurisdiction. The notice must include the following information:

• A description of the breach, including the date of the breach and date of discovery

• The type of PHI involved (such as full name, SSN, date of birth, home address, or account number)

• Steps individuals should take to protect themselves from potential harm resulting from the breach

• Steps the covered entity is taking to investigate the breach, mitigate losses, and protect against future breaches

• Contact procedures for individuals to ask questions or receive additional information, including a toll-free telephone number, email address, website, or postal address

Covered entities must notify the Department of Health and Human Services (HHS) of all breaches. Notice to HHS must be provided immediately for breaches involving more than 500 individuals and annually for all other breaches. Covered entities have the burden of demonstrating that they satisfied the specific notice obligations following a breach, or, if notice is not made following an unauthorized use or disclosure, that the unauthorized use or disclosure did not constitute a breach. See Chapter 13, “Regulatory Compliance for Financial Institutions,” for further discussion of health-care–related security incidents.

Section 13407 of the HITECH Act directed the Federal Trade Commission (FTC) to issue breach notification rules pertaining to the exposure or compromise of personal health records (PHRs). A personal health record is defined by the FTC as an electronic record of “identifiable health information on an individual that can be drawn from multiple sources and that is managed, shared, and controlled by or primarily for the individual.” Don’t confuse PHR with PHI. PHI is information that is maintained by a covered entity as defined by HIPAA/HITECH. PHR is information provided by the consumer for the consumer’s own benefit. For example, if a consumer uploads and stores medical information from many sources in one online location, the aggregated data would be considered a PHR. The online service would be considered a PHR vendor.

The FTC rule applies to both vendors of PHRs (which provide online repositories that people can use to keep track of their health information) and entities that offer third-party applications for PHRs. The requirements regarding the scope, timing, and content mirror the requirements imposed on covered entities. The enforcement is the responsibility of the FTC. By law, noncompliance is considered “unfair and deceptive trade practices.”

Title IX of P.L. 109-461, the Veterans Affairs Information Security Act, requires the VA to implement agency-wide information security procedures to protect the VA’s “sensitive personal information” (SPI) and VA information systems. P.L. 109-461 also requires that in the event of a “data breach” of SPI processed or maintained by the VA, the Secretary must ensure that as soon as possible after discovery, either a non-VA entity or the VA’s Inspector General conduct an independent risk analysis of the data breach to determine the level of risk associated with the data breach for the potential misuse of any SPI. Based on the risk analysis, if the Secretary determines that a reasonable risk exists of the potential misuse of SPI, the Secretary must provide credit protection services.

P.L. 109-461 also requires the VA to include data security requirements in all contracts with private-sector service providers that require access to SPI. All contracts involving access to SPI must include a prohibition of the disclosure of such information, unless the disclosure is lawful and expressly authorized under the contract, as well as the condition that the contractor or subcontractor notify the Secretary of any data breach of such information. In addition, each contract must provide for liquidated damages to be paid by the contractor to the Secretary in the event of a data breach with respect to any SPI, and that money should be made available exclusively for the purpose of providing credit protection services.

• California was the first to adopt a security breach notification law. The California Security Breach Information Act (California Civil Code Section 1798.82), effective July 1, 2003, required companies based in California or with customers in California to notify them whenever their personal information may have been compromised. This groundbreaking legislation provided the model for states around the country.

• MA Chapter 93H Massachusetts Security Breach Notification Law, enacted in 2007, and the subsequent 201 CMR 17 Standards for the Protection of Personal Information of Residents of the Commonwealth, is widely regarded as the most comprehensive state information security legislation.

• The Texas Breach Notification Law was amended in 2011 to require entities doing business within the state to provide notification of data breaches to residents of states that have not enacted their own breach notification law. In 2013, this provision was removed. Additionally, in 2013, an amendment was added that notice provided to consumers in states that require notification can comply with either the Texas law or the law of the state in which the individual resides.

The basic premise of the state security breach laws is that consumers have a right to know if unencrypted personal information such as SSN, driver’s license number, state identification card number, credit or debit card number, account password, PINs, or access codes have either been or are suspected to be compromised. The concern is that the listed information could be used fraudulently to assume or attempt to assume a person’s identity. Exempt from legislation is publicly available information that is lawfully made available to the general public from federal, state, or local government records or by widely distributed media.

State security breach notification laws generally follow the same framework, which includes who must comply, a definition of personal information and breach, the elements of harm that must occur, triggers for notification, exceptions, and the relationship to federal law and penalties and enforcement authorities. Although the framework is standard, the laws are anything but. The divergence begins with the differences in how personal information is defined and who is covered by the law, and ends in aggregate penalties that range from $50,000 to $500,000. The variations are so numerous that compliance is confusing and onerous.

It is strongly recommended that any organization that experiences a breach or suspected breach of PII consult with legal counsel for interpretation and application of the myriad of sector-based, federal, and state incident response and notification laws.

Experian commissioned the Ponemon Institute to conduct a consumer study on data breach notification. The findings are instructive. When asked “What personal data if lost or stolen would you worry most about?”, they overwhelmingly responded “password/PIN” and “social security number.”

• Eighty-five percent believe notification about data breach and the loss or theft of their personal information is relevant to them.

• Fifty-nine percent believe a data breach notification means there is a high probability they will become an identity theft victim.

• Fifty-eight percent say the organization has an obligation to provide identity protection services, and 55% say they should provide credit-monitoring services.

• Seventy-two percent were disappointed in the way the notification was handled. A key reason for the disappointment is respondents’ belief that the notification did not increase their understanding about the data breach.

• Get it over with.

• Be humble.

• Don’t lie.

• Say only what needs to be said.

Don’t wait until a breach happens to develop a PR preparedness plan. Communications should be part of any incident preparedness strategy. Security specialists should work with PR people to identify the worst possible breach scenario so they can message against it and determine audience targets, including customers, partners, employees, and the media. Following a breach, messaging should be bulletproof and consistent.

Training users to use strong passwords, not click on email embedded links, not open unsolicited email attachments, properly identify anyone requesting information, and report suspicious activity can significantly reduce small business exposure and harm.

The objective of incident management is a consistent and effective approach to the identification of and response to information security–related incidents. Meeting that objective requires situational awareness, incident reporting mechanisms, a documented IRP, and an understanding of legal obligations. Incident preparation includes developing strategies and instructions for documentation and evidence handling, detection and investigation (including forensic analysis), containment, eradication and recovery, notification, and closure. The roles and responsibilities of key personnel, including executive management, legal counsel, incident response coordinators (IRCs), designated incident handlers (DIHs), the incident response team (IRT), and ancillary personnel as well as external entities such as law enforcement and regulatory agencies, should be clearly defined and communicated. Incident response capabilities should be practiced and evaluated on an ongoing basis.

Consumers have a right to know if their personal data has been compromised. In most situations, data breaches of PII must be reported to the appropriate authority and affected parties notified. A data breach is generally defined as actual or suspected compromise, unauthorized disclosure, unauthorized acquisition, unauthorized access, or unauthorized use or loss of control of legally protected PII. All 50 states, the District of Columbia, Guam, Puerto Rico and the Virgin Islands have enacted legislation requiring private or governmental entities to notify individuals of security breaches of information involving personally identifiable information. In addition to state laws, there are sector- and agency-specific federal regulations that pertain to reporting and notification. Organizations that experience a breach or suspected breach of PII should consult with legal counsel for interpretation and application of often overlapping and contradictory rules and expectations.

Incident management policies include Incident Definition Policy, Incident Classification Policy, Information Response Program Policy, Incident Response Authority Policy, Evidence Handling and Use Policy, and Data Breach Reporting and Notification Policy. NIST Special Publication 800-61 goes over the major phases of the incident response process in detail. You should become familiar with that publication because it provides additional information that will help you succeed in your security operations center (SOC).

Many organizations take advantage of tabletop (simulated) exercises to further test their capabilities. These tabletop exercises are an opportunity to practice and also perform gap analysis. In addition, these exercises may also allow them to create playbooks for incident response. Developing a playbook framework makes future analysis modular and extensible.

During the investigation and resolution of a security incident, you may also need to communicate with outside parties regarding the incident. Examples include, but are not limited to, contacting law enforcement, fielding media inquiries, seeking external expertise, and working with Internet service providers (ISPs), the vendor of your hardware and software products, threat intelligence vendor feeds, coordination centers, and members of other incident response teams. You can also share relevant incident indicator of compromise (IoC) information and other observables with industry peers. A good example of information-sharing communities includes the Financial Services Information Sharing and Analysis Center (FS-ISAC).

A. Incident management is risk minimization.

B. Incident management is a consistent approach to responding to and resolving issues.

C. Incident management is problem resolution.

D. Incident management is forensic containment.

2. Which of the following statements is true of security-related incidents?

A. Over time, security-related incidents have become less prevalent and less damaging.

B. Over time, security-related incidents have become more prevalent and more disruptive.

C. Over time, security-related incidents have become less prevalent and more damaging.

D. Over time, security-related incidents have become more numerous and less disruptive.

3. Which of the following CVSS score groups represents the intrinsic characteristics of a vulnerability that are constant over time and do not depend on a user-specific environment?

A. Temporal

B. Base

C. Environmental

D. Access vector

4. Which of the following aim to protect their citizens by providing security vulnerability information, security awareness training, best practices, and other information?

A. National CERTs

B. PSIRT

C. ATA

D. Global CERTs

5. Which of the following is the team that handles the investigation, resolution, and disclosure of security vulnerabilities in vendor products and services?

A. CSIRT

B. ICASI

C. USIRP

D. PSIRT

6. Which of the following is an example of a coordination center?

A. PSIRT

B. FIRST

C. The CERT/CC division of the Software Engineering Institute (SEI)

D. USIRP from ICASI

7. Which of the following is the most widely adopted standard to calculate the severity of a given security vulnerability?

A. VSS

B. CVSS

C. VCSS

D. CVSC

8. The CVSS base score defines Exploitability metrics that measure how a vulnerability can be exploited as well as Impact metrics that measure the impact on which of the following? (Choose three.)

A. Repudiation

B. Nonrepudiation

C. Confidentiality

D. Integrity

E. Availability

9. Which of the following is true about cybersecurity incidents?

A. Compromise business security

B. Disrupt operations

C. Impact customer trust

D. All of the above

10. Which of the following statements is true when a cybersecurity-related incident occurs at a business partner or vendor that hosts or processes legally protected data on behalf of an organization?

A. The organization does not need to do anything.

B. The organization must be notified and respond accordingly.

C. The organization is not responsible.

D. The organization must report the incident to local law enforcement.

11. Which of the following can be beneficial to further test incident response capabilities?

A. Phishing

B. Legal exercises

C. Tabletop exercises

D. Capture the flag

12. A celebrity is admitted to the hospital. If an employee accesses the celebrity’s patient record just out of curiosity, the action is referred to as __________.

A. inappropriate usage

B. unauthorized access

C. unacceptable behavior

D. undue care

13. Which of the following is true when employees report cybersecurity incidents?

A. Prepared to respond to the incident

B. Praised for their actions

C. Provided compensation

D. None of the above

14. Which of the following statements is true of an incident response plan?

A. An incident response plan should be updated and authorized annually.

B. An incident response plan should be documented.

C. An incident response plan should be stress-tested.

D. All of the above.

15. Which of the following terms best describes a signal or warning that an incident may occur in the future?

A. A sign

B. A precursor

C. An indicator

D. Forensic evidence

16. Which of the following terms best describes the process of taking steps to prevent the incident from spreading?

A. Detection

B. Containment

C. Eradication

D. Recovery

17. Which of the following terms best describes the addressing of the vulnerabilities related to the exploit or compromise and restoring normal operations?

A. Detection

B. Containment

C. Testing

D. Recovery

18. Which of the following terms best describes the eliminating of the components of the incident?

A. Investigation

B. Containment

C. Eradication

D. Recovery

19. Which of the following terms best describes the substantive or corroborating evidence that an incident may have occurred or may be occurring now?

A. Indicator of compromise

B. Forensic proof

C. Heresy

D. Diligence

20. Which of the following is not generally an incident response team responsibility?

A. Incident impact analysis

B. Incident communications

C. Incident plan auditing

D. Incident management

21. Documentation of the transfer of evidence is known as a ____________.

A. chain of evidence

B. chain of custody

C. chain of command

D. chain of investigation

22. Data breach notification laws pertain to which of the following?

A. Intellectual property

B. Patents

C. PII

D. Products

23. HIPAA/HITECH requires ______________ within 60 days of the discovery of a breach.

A. notification be sent to affected parties

B. notification be sent to law enforcement

C. notification be sent to Department of Health and Human Services

D. notification be sent to all employees

1. Read three recent notification letters to the Attorney General as well as the corresponding notice that will be sent to the consumer (be sure to scroll through the document). Write a summary and timeline (as presented) of each event.

2. Choose one incident to research. Find corresponding news articles, press releases, and so on.

3. Compare the customer notification summary and timeline to your research. In your opinion, was the notification adequate? Did it include all pertinent details? What controls should the company put in place to prevent this from happening again?

1. Create a grid that includes state, statute, definition of personal information, definition of a breach, time frame to report a breach, reporting agency, notification requirements, exemptions, and penalties for nonconformance. Fill in the grid using information from five states.

2. If a company that did business in all five states experienced a data breach, would it be able to use the same notification letter for consumers in all five states? Why or why not?

3. Create a single notification law using what you believe are the best elements of the five laws included in the grid. Be prepared to defend your choices.

“Appendix B to Part 364—Interagency Guidelines Establishing Information Security Standards,” accessed 04/2018, https://www.fdic.gov/regulations/laws/rules/2000-8660.html.

“201 CMR 17.00: Standards for the Protection of Personal Information of Residents of the Commonwealth,” official website of the Office of Consumer Affairs & Business Regulation (OCABR), accessed 04/2018, www.mass.gov/ocabr/docs/idtheft/201cmr1700reg.pdf.

“Family Educational Rights and Privacy Act (FERPA),” official website of the U.S. Department of Education, accessed 04/2018, https://www2.ed.gov/policy/gen/guid/fpco/ferpa/index.html.

“Financial Institution Letter (FIL-27-2005), Final Guidance on Response Programs for Unauthorized Access to Customer Information and Customer Notice,” accessed 04/2018, https://www.fdic.gov/news/news/financial/2005/fil2705.html.

“HIPAA Security Rule,” official website of the Department of Health and Human Services, accessed 04/2018, https://www.hhs.gov/hipaa/for-professionals/security/index.html.

“Office of Management and Budget Memorandum M-07-16 Safeguarding Against and Responding to the Breach of Personally Identifiable Information,” accessed 04/2018, https://www.whitehouse.gov/OMB/memoranda/fy2007/m07-16.pdf.

“Chain of Custody and Evidentiary Issues,” eLaw Exchange, accessed 04/2018, www.elawexchange.com.

“Complying with the FTC’s Health Breach Notification Rule,” FTC Bureau of Consumer Protection, accessed 04/2018, https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule.

“Student Privacy,” U.S. Department of Education, accessed 04/2018, https://studentprivacy.ed.gov/.

“Forensic Examination of Digital Evidence: A Guide for Law Enforcement,” U.S. Department of Justice, National Institute of Justice, accessed 04/2018, https://www.nij.gov/publications/pages/publication-detail.aspx?ncjnumber=199408.

“VERIS Community Database, accessed 04/2018, http://veriscommunity.net/vcdb.html.

Mandia, Kevin, and Chris Prosise, Incident Response: Investigating Computer Crime, Berkeley, California: Osborne/McGraw-Hill, 2001.

Nolan, Richard, “First Responders Guide to Computer Forensics,” 2005, Carnegie Mellon University Software Engineering Institute.

“United States Computer Emergency Readiness Team,” US-CERT, accessed 04/2018, https://www.us-cert.gov.

“CERT Division of the Software Engineering Institute (SEI),” accessed 04/2018, https://cert.org.

Forum of Incident Response and Security Teams (FIRST), accessed 04/2018, https://first.org.

“The Common Vulnerability Scoring System: Specification Document,” accessed 04/2018, https://first.org/cvss/specification-document.