Blog, Learning Center March 24, 2021

The Ultimate Data Breach Response Plan

In a hyper-connected world, data breaches continue to increase in size and scope. Cybersecurity threats come in various forms, from social engineering to database vulnerability exploitation. With that in mind, data breaches are more likely than ever, regardless of an organization’s size. To bolster your cybersecurity posture, you should put together a data breach response plan as a way to prepare your organization.

How to choose between NIST and SANS data breach response frameworks?

The short answer to this question is that you can use either framework, depending on how you want to organize your staff. The National Institute of Standards and Technology (NIST) “Computer Security Incident Handling Guide” and the SANS Institute “Incident Handler’s Handbook” both set out the same necessary steps for responding to a data security incident. The primary difference is how they organize the actions.

NIST takes a four-pillar approach that includes:

Preparation
Detection and Analysis
Containment, Eradication, & Recovery
Post-Incident Activity

Meanwhile, SANS consolidates the second NIST pillar while separating the third into three distinct categories:

Preparation
Identification
Containment
Eradication
Recovery
Lessons Learned

Although similarities exist between the two approaches, they offer different details and suggestions. Combining the best practices of the two, as done below, helps you create a data breach response plan that will guide you towards a more secure IT stack.

Pre-plan

The foundation of a robust data breach response plan lies in the pre-planning process. Although many of the steps you take at this point cross over to other areas of cybersecurity, each part of the pre-planning process needs to be aligned with how you respond to a data breach.

Categorize risk

Risk categorization and analysis may seem obvious first step since nearly everything in cybersecurity revolves around risk. Referring to the risk assessment you did when writing your information security policy gives you a head start.

DATA

Cybercriminals want to steal sensitive data such as personally identifiable information (PII), non-public personal information (NPI), cardholder data (CD), electronic Protected Health Information (PHI), and intellectual property (IP).

High-risk information includes:

Names
Birth dates
Home addresses
IP addresses
Usernames
Passwords
Social security numbers (SSNs)
Primary account numbers (PAN)
Credit card expiration dates
Lab results
Prescriptions
X-rays and MRIs

CRITICAL APPLICATIONS

Critical applications are the gears that keep the wheels of your business running. Sometimes referred to as the “crown jewels,” these applications store large amounts of data, spread globally, and interconnect deeply with other mission-critical applications.

Some examples of critical applications include:

Customer accounting systems
Enterprise resource planning (ERP) applications
Electronic health record (EHR) systems
General ledgers

DEVICES

Whether you’re worried about device theft or someone accidentally installing malware, you need an asset inventory to catalog all the devices that connect to your network. As part of your asset inventory, you want to include at least:

Workstations
Laptops
Printers
Servers
Internet of Things (IoT) devices
Smart devices
Tablets
Smartphones
Switches
Routers
Bridges
Gateways
Modems
Repeaters
Hubs

USERS

The list of users accessing your systems, software, and networks might seem logical at first since you know all your employees. However, digital transformation is changing the definition of “user.” You need to understand the different types of identities – human and machine – that access resources.

Some users to consider include:

Standard users
Privileged users, like admin accounts
Contractors
Service accounts
Robotic processing automation (RPAs/bots)
APIs
Cloud workloads
Virtual machines (VMs)
Containers

Scenarios

Predicting when a data breach will occur is difficult. However, predicting the data breach attack type is easier. As part of your data breach response plan, you want to research the types of data breaches that impact your industry and the most common attack methodologies. In some cases, the two will be the same. For instance, social engineering attacks are common across all industry verticals. However, cybercriminals can target certain attack types against industries with unique data handling risks. For example, malicious actors leverage card skimming attacks against the financial services industry’s ATMs.

RANSOMWARE

Cybercriminals increasingly use ransomware attacks that encrypt companies’ data to make it unusable and exfiltrate it to “hold hostage.” Planning for a ransomware attack needs to include additional factors now that malicious actors incorporate exfiltration.

As part of planning for this scenario, you want to consider reviewing:

Firewall log data
Server disk usage
Abnormal account login times/locations
Network intrusion detection

CREDENTIAL THEFT

Although credential theft can be used as part of a ransomware attack, cybercriminals often engage in this methodology for other reasons. For example, they may want access to NPI or corporate secrets.

As part of planning for this scenario, you want to consider reviewing:

User behavior analytics (UEBA)
Abnormal login times
Abnormal login locations
Failed login attempts
Locked accounts from failed login attempts

DISTRIBUTED DENIAL OF SERVICE (DDOS)

During a DDoS attack, malicious actors overwhelm an organization’s networks. This leads them to stop responding, essentially shutting them down.

As part of planning for this scenario, you want to consider reviewing:

Approved source IP addresses and protocols
Load, server, router, firewall, and application logs
Network analyzer reports
Ability to throttle traffic close to network cloud
Ability to change traffic routing

Security policies

Policies are the written foundation of how you secure your IT stack and mitigate risks. Therefore, every data breach response plan must be integrated into the company’s IT, security, and privacy policies. Generally, organizations create a series of policies that interconnect through cross-references and appendices.

GENERAL INFORMATION SECURITY POLICY

The general information security policy is based on the company’s risk assessment and risk tolerance. It outlines the controls you put in place that mitigate risks.

As a best practice, this policy should cover:

Encryption: covers algorithm, key length, hashing, authentication
Acceptable Use: lists allowed and disallowed activities for corporate devices and consequences for violations
Clean Desk: includes removing sensitive information from the desk as well as rules for locking workstations to prevent snooping
Data Breach Response: covers the full plan for detecting and responding to data breaches
Disaster Recovery: defines steps to recover from physical or digital disaster, including backup best practices
Digital Signature Acceptance: defines accepted uses and methods for validating signers on electronic documents
Email: outlines appropriate use of the corporate email
Ethics: provides rules for appropriate behavior, whistleblower policies, and accepting vendor gifts
Pandemic Response Planning: directs how to manage pandemic outside of traditional disaster recovery, including payment, work location, and furlough
Password: defines guidelines for creating a secure password and protecting passwords
Security Response Plan: develops and implements responsibilities for responding to product or service security incidents
End-User Encryption Key Protection: scopes covered encryption keys and outlines practices for preventing unauthorized disclosure of them

NETWORK SECURITY POLICY

The network security policy focuses on controls that protect your network from intrusions.

As a best practice, this policy should cover:

Acquisition Assessment: establishes vendor due diligence steps before, purchasing
Bluetooth Baseline Requirements: defines baselines for connecting Bluetooth enabled devices to corporate network or devices
Remote Access: establishes standards for connecting to the corporate network from personal or public networks
Remote Access Tools: sets out requirements for remote desktop tools and their configurations
Router and Switch Security: outlines minimum security router and switch configurations when used in production network or production capacity
Wireless Communication: defines technical requirements and the continued need to meet requirements for wireless infrastructure devices to connect to the network

SERVER SECURITY POLICY

Whether on-premise or in the cloud, servers contain an organization’s most important asset, data. Digital transformation has increased the Infrastructure-as-Code (IaC) model, where you store data in code-based cloud repositories rather than on-premise hardware.

As a best practice, this policy should cover:

Database Credential Policy: established database username and password secure storage and retrieval requirements
Information Logging Standard: specifies requirements for generating audit logs and integrating with enterprise log management
Lab Security: outlines lab requirements to prevent compromising confidential information and technologies
Server Security: sets minimum server security configurations inside production network or use in production capacity
Software Installation: defines requirements for installing third-party software on corporate devices
Technology Equipment Disposal: sets procedures for electronic equipment disposal including hard drive, USBs, CD-ROMs, and media considered sensitive

WEB APPLICATION SECURITY POLICY

As malicious actors continue to leverage vulnerabilities in Software-as-a-Service (SaaS) applications, your web application security policy becomes more critical.

As a best practice, this policy should establish guidelines for how an organization assesses a web application’s security and outline the process for engaging in the assessment.

Responsible parties

Every data breach response plan needs to identify roles and responsibilities. Since a data security incident can touch various departments, you want to make sure that you define a role in the department responsible for specific activities. If everyone knows what they need to do before a data breach occurs, you create a more efficient and effective response plan.

MANAGEMENT TEAM

The leadership team reviews and approves the policy, budget, and staffing. They also coordinate with the internal and external stakeholders throughout the remediation and post-event analysis stages.

IT SECURITY TEAM

This group handles prevention, containment, remediation, and removal with threat research and technical control remediation.

IT ADMINISTRATION STAFF

System and network admins work as part of the daily prevention team, but they also understand remediation actions such as taking an affected system offline.

LEGAL

The legal team reviews all policies, plans, and procedures to ensure compliance with laws and industry standards. They also coordinate post-breach activities like engaging outside counsel, collecting evidence, prosecuting a suspect, managing a lawsuit, and coordinating customer notification activities.

MARKETING AND PUBLIC RELATIONS (PR)

Data breaches lead to a lot of negative press that can ruin a company’s reputation. The PR team works with the media and public to share information about the breach, post-breach activities, and reduce reputation risk.

HUMAN RESOURCES (HR)

The HR department should handle any data breach related to malicious insider activity.

Disaster Recovery, Business Continuity Planning, Notice

In today’s hyper-connected world, a data breach can lead to downtime for businesses. For example, DDoS attacks overwhelm networks, ultimately leaving web-based applications unresponsive. Meanwhile, ransomware attacks leave data unusable.

DATA BACKUP

A strong disaster recovery policy is a data backup that stores recent images of all data necessary. Following the 3-2-1 best practices for creating a data backup includes having three copies of all information, on two different media types, with one of them offsite. Leveraging cloud solutions reduce the time to recover, reducing the downtime costs associated with a data breach.

INSURANCE

Obtaining a cyber insurance policy helps transfer some of the costs that come from a data breach. Typically, a cyber insurance policy should include:

Reputation protection and repair
Software or hardware repair
Loss of income
Customer notification costs

POINTS OF CONTACT

Your disaster recovery and business continuity plan should also consider the internal and external stakeholders that keep the business running when a data breach happens. In a lot of ways, this process is similar to when a robber steals physical items.

As part of this process, you should include the following parties:

Law enforcement: to help locate the perpetrator
Legal: to help determine response to lawsuits or compliance violations
Forensics: to help track the perpetrator and obtain evidence
Vendors/Customers: to work towards securing the supply chain

COMPLIANCE

The compliance team wears many different hats when a data breach occurs. As part of your disaster recovery processes, you should consider the following responsibilities for your compliance team:

Review the incident for control failures leading to compliance violations
Review notification to ensure compliance with privacy laws and industry standards
Review remediation activities for compliance with internal best practices

Incident Handling

Policies are the plans for how you plan to respond to a data breach. However, you need to follow best practices for handling incidents. Whether you choose the NIST or SANS model, best practices remain similar.

Identify/detect and protect

Intrusion detection is the process of monitoring for and detecting abnormal activity and analyzing the activity to determine whether it qualifies as an incident.

Identifying or detecting starts by noticing abnormal activity from compromised credentials, malware, phishing, or system/network vulnerability exploitation.

The first step in the identification/detection process is to understand the most common attack vectors to focus monitoring on those areas. Some of these include:

External/removable media: like placing malware on a USB drive
Attrition: like using a brute force method to degrade systems, networks, or services
Web: like cross-site scripting attacks that steal credentials
Email: like malware stored as an attachment
Impersonation: like spoofing
Improper usage: like authorized user installing software without IT’s approval
Equipment loss or theft: like having a smartphone stolen

Information, software, and hardware that enable this process include:

Log alerts
Error messages
Failed login attempts
Access requests
Intrusion detection systems
Firewalls
Port lists
OS, application, protocol, intrusion detection, and antivirus product documentation
Network diagrams
Deviation from baselines
Digital forensic workstations
Backup devices
Portable printers
Pack sniggers
Protocol analyzers
Digital forensic software

As part of this process, your team should be considering:

Where the incident occurred
The person reporting or discovering the incident
How the person discovered the incident
Potentially compromised areas
Impact scope
Business impact
Location of incident sources

Your incident response team should document their activities and should include the following:

Incident status
Incident summary
Indicators
Additional related incidents
Incident handler actions taken
Evidence chain of custody
Incident impact assessment
Responsible party contact information
Investigation evidence list
Incident handler comments
Planned next steps

Containment

During the containment phase, your incident response team focuses on limiting damage and preventing additional damage from happening.

As part of the containment process, you want to make sure that you consider:

Identifying affected and non-affected systems
Potential resource theft or damage
Preserving evidence
Service availability
Time and resources needed
Effectiveness
Ability to isolate the problem
Backup capabilities

During the containment period, the incident response team should focus on preventing additional harm to data and engage in activities that help identify the attacking host. Some commonly performed activities that do not undermine the containment process include:

Validating attacking host IP address
Using search engine research to identify attacking host
Collecting and consolidating data from incident databases
Monitoring communication channels the attacking host may use

Often, companies take a two-step approach to containment using short-term and long-term strategies.

SHORT TERM CONTAINMENT

Short-term containment activities involve rapid response to limit the damage. Some strategies include:

Isolating network segments containing infected workstations
Taking hacked production servers offline
Wiping and reimaging systems after taking a forensic impact
Shutting down impacted systems
Disabling functions
Redirecting malicious actor to a sandbox for additional activity monitoring

LONG-TERM CONTAINMENT

Long-term containment focuses on getting systems to function normally and preventing the threat actor from moving within the systems and networks. Some strategies include:

Removing impacted accounts
Eliminating backdoors
Installing security patches for affected and neighboring systems

Eradication

During the eradication step, incident handlers remove all the attack components and work toward restoring the affected systems. As part of this process, some activities may include:

Deleting malware
Disabling breached user accounts
Identifying vulnerabilities
Mitigating vulnerabilities
Identifying all affected hosts
Reimaging and hardening systems with patches
Removing all artifacts left by the attacker

Recovery

Finally, the recovery process brings the affected system back online after testing, monitoring, and validating that attackers will be unable to compromise it again.

Recovery activities include:

Restoring from a clean backup
Rebuilding from scratch
Replacing compromised files with clean files
Installing patches
Changing passwords
Re-securing networks with updates to controls like new firewall rulesets or boundary router access control lists

During recovery, you also want to consider the following:

A realistic timeline for restoration
Tools to test, monitor, and verify systems
Additional monitoring for affected systems
Monitoring data necessary
Benchmarks for measuring monitoring effectiveness

Lessons Learned

After completing the recovery process, your organization needs to review its data breach response capabilities and incorporate any lessons learned. Engaging in a post-data breach incident handling analysis gives you insight into what processes worked well and what actions you can take to prevent a similar event.

Conducted as soon as possible after the incident, the lessons learned meeting should incorporate objective and subjective information that you can use to enhance processes, justify spending, and incorporate into the annual risk assessment.

As part of this process, you want a written report documenting the following:

Details of the event: what happened, when it happened, and who detected it
Incident scope: systems, networks, software impacted
Process: details of containment and eradication
Recovery work: steps taken to bring affected systems back online
Conformance to procedures: whether responsible parties followed procedures and whether procedures were adequate
Information availability: whether more information was needed earlier in the process
Roadblocks: whether steps or activities got in the way of recovery
Changes needed: whether staff or management would do anything differently
Information sharing: improvements needed for future incidents
Corrective actions: changes that prevent future similar incidents
Monitoring: precursors or indicators needed to detect future incidents
Tools/Resources: additional detection, analysis, and mitigation resources

SecurityScorecard enhances data breach response plans

A fundamental part of your data breach response plan should focus on prevention. Continuous monitoring, prioritizing alerts, and proactively remediating potential attack vectors enable you to mitigate data breach risks. Threat mitigation strategies focused on data breach prevention enhance the detection portion of your data breach response plan.

SecurityScorecard enables robust data breach response plans by continuously monitoring your IT stack and giving you an outside-in view of your controls’ effectiveness. Our platform monitors across ten categories of risk, including network security, IP reputation, patching cadence, endpoint security, and web application security. With our A-F security ratings, you get real-time, at-a-glance visibility into your security posture. Additionally, our alerts prioritize risks so that you can more efficiently prevent a data breach.

Stopping attackers before they are successful cuts the head off the beast. SecurityScorecard gives you the sword you need to detect and prevent a data breach more proactively.