Peter A Clarke

The National Institute of Standards and Technology have released an especially valuable document, the Incident Response Recommendations and Considerations for Cybersecurity Risk Management.

The abstract provides:

This publication seeks to assist organizations with incorporating cybersecurity incident response recommendations and considerations throughout their cybersecurity risk management activities as described by the NIST Cybersecurity Framework (CSF) 2.0. Doing so can help organizations prepare for incident responses, reduce the number and impact of incidents that occur, and improve the efficiency and effectiveness of their incident detection, response, and recovery activities. Readers are encouraged to utilize online resources in conjunction with this document to access additional information on implementing these recommendations and considerations.

The Report provides a useful glossary for those reporting on or drafting protocols and procedures dealing with data breaches including:

• an event is any observable occurrence that involves computing assets, including physical and virtual platforms, networks, services, and cloud environments. Examples of events are user login attempts, the installation of software updates, and an application responding to a transaction request. Many events focus on security or have security implications.
• Adverse events are any events associated with a negative consequence regardless of cause, including natural disasters, power failures, or cybersecurity attacks. This guide addresses only adverse cybersecurity events. 
• A cybersecurity incident is “…an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” with such incidents including:
  • Employing a botnet to send high volumes of connection requests to an internet-facing service, making it unavailable to legitimate service users
  • Obtaining administrative credentials at a software-as-a-service provider, which puts sensitive tenant data entrusted to that provider at risk
  • Intruding upon an organization’s business network to steal credentials and use them to instruct industrial control systems to shut down or destroy critical physical components, causing a major service disruption
  • Deploying ransomware to prevent the use of computer systems and cause multiple data breaches by copying files from those systems
  • Using phishing emails to compromise user accounts and using those accounts to commit financial fraud
  • Identifying a new vulnerability in network management appliances and exploiting the vulnerability to gain unauthorized access to network communications
  • Compromising a vendor’s software, which is subsequently distributed to customers in its compromised state

Regarding incident response roles and responsibilities:

• the success of their incident response efforts depend on the participation of many internal and external parties who hold a wide variety of roles and responsibilities including:
  • Leadership. The leadership team oversees incident response, allocates funding, and may have decision-making authority on high-impact response actions, such as shutting down or rebuilding critical services
  • Incident handlers. Incident handlers verify that an incident has occurred, collect and analyze data and evidence, prioritize incident response activities, and act appropriately to limit damage, find root causes, and restore operations. Incident handlers also often provide input to others on mitigating cybersecurity issues and improving resiliency. They might be:
    • On staff (e.g., an incident response team)
    • On contract (e.g., outsourcing a security operations center [SOC] to a managed security services provider [MSSP] or leveraging a cloud service provider’s incident response team when an incident occurs within that provider’s cloud), and/or
    • Available when needed (e.g., from a cybersecurity services provider, a business partner, or a law enforcement agency)
  • Technology professionals. Cybersecurity, privacy, system, network, cloud, and other technology architects, engineers, and administrators, as well as software developers.
  • Legal. Legal experts review:
    • incident response plans, policies, and procedures to ensure compliance with applicable laws and regulations, including the right to privacy.
    • contracts with technology suppliers and other third parties when there are incident response implications.
    • a particular incident to see if it has legal ramifications, such as the prosecution of a suspect, lawsuits, or situations that require a memorandum of understanding (MOU) or other binding agreement
  • Public affairs and media relations. It may be necessary to inform the media and, by extension, the public. Sometimes, the media learns of incidents through alternate sources (i.e., not through public affairs personnel).
  • Human resources. Human resources should consider cybersecurity risk management, including pre-employment screening and employee onboarding, offboarding, and position changes.
  • Physical security and facilities management. Some computer security incidents occur through physical security breaches or involve coordinated logical and physical attacks. The incident response team may also need access to facilities during incident handling (e.g., to access a compromised workstation in a locked office)
  • Asset owners. Asset owners (e.g., system owners, data owners, and business process owners) may have valuable insights on response and recovery priorities for their affected assets. They also need to be kept up to date on the status of response and recovery efforts
• Third parties may be under contract to help perform incident response activities, with some third parties
  • filling a primary role (e.g., an MSSP performing incident detection, response, and recovery activities),
  • such as cloud service providers [CSPs] and internet service providers [ISPs]) may be involved in certain incident response activities for particular types of incidents.

This is a shared responsibility model in which the organisation transfers some of its responsibilities to a provider. These responsibilities should be clearly defined in a contract, and the incident response team should be aware of the division of responsibilities, including information flows, coordination, and authority to act on behalf of the organization. This also includes restrictions on what the service provider can do, such as sharing sanitized incident information with other customers or making and implementing operational decisions (e.g., immediately deactivating certain services to contain an incident)

• A service provider may:
  • detect malicious activity sooner than individual organisations would because it can correlate events across its customers.
  • be able to use knowledge of an incident with one customer to proactively prevent similar incidents with its other customers.
  • have privileged access to organisational systems and may also have access to sensitive organizational data. Accordingly, the risk of malicious insiders or the service provider being compromised should be considered and addressed.
• Organisations should have policies that govern their cybersecurity incident response including the key elements of:
  • Statement of management commitment
  • Purpose and objectives of the policy
  • Scope of the policy (i.e., to whom and what it applies and under what circumstances)
  • Definition of events, cybersecurity incidents, investigations, and related terms
  • Roles, responsibilities, and authorities, such as which roles have the authority to confiscate, disconnect, or shut down technology assets
  • Guidelines for prioritizing incidents, estimating their severity, initiating recovery processes, maintaining or restoring operations, and other key actions
  • Performance measures
• Processes and procedures should be based on the incident response policy and plan. They should:
  • explain how technical processes and other operating procedures should be performed.
  • be tested or exercised periodically to verify their accuracy and can be used to help train new personnel.
  • include detailed procedures for every possible situation,
  • document procedures for responding to the most common types of incidents and threats.
  • include procedures for particularly important processes that may be urgently needed during emergency situations, such as redeploying the organization’s primary authentication platform.