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.
