Your organization’s third-party ecosystem is likely larger than ever, increasing its vulnerability to ransomware, credential and data exposures, technology outages, denial-of-service attacks, and other threats. If you’ve read the latest breach-related headlines, it should come as no surprise that attacks on your partners, suppliers, and service providers can have devastating implications on your reputation and bottom line. Fortunately, the National Institute of Standards and Technology (NIST) offers practical guidance on how to handle cyberattacks affecting your organization and its third parties.
Applying the NIST SP 800-61 Incident Handling Framework to Third-Party Risk
The NIST Computer Security Incident Handling Guide, SP 800-61, prescribes four foundational phases that security teams should consider for their incident handling programs. Below are summaries of each phase, with additional notes on where third-party risk management comes into play. Be sure to consult the NIST publication for complete and detailed guidance.
- Communication plans: Start with building contact lists, communication plans, and escalation procedures. Be sure to include key third parties in your communication plans and gather information about their emergency contacts and escalation paths. This will also be helpful in phase 2: Detection and analysis.
- Facilities: Establish internal war rooms and secure storage facilities.
- Technology: Ensure that response teams have access to incident analysis hardware (laptops, servers, backup devices) and software (e.g., packet sniffers, protocol analyzers, forensic software, issue tracking, and images of clean installs for restoration and recover).
- Documentation: Document incident analysis resources, including port lists, technology (e.g., OSes and applications in use), network diagrams, baselines of expected network activity, and more.
- Prevention: Implement host, network, and malware security software. Conduct internal and third-party risk assessments and establish a security awareness training program.
Detection and Analysis
- Attack vectors: Account for all the paths attackers can take to reach your organization (e.g., web application attacks, phishing, impersonation, improper usage, lost/stolen equipment, etc.). Be sure to map your connections and relationships to third parties and fourth parties as part of this process.
- Signs of an incident: Look for precursors of potential future incidents and indicators of incidents that have occurred. This is where third-party risk monitoring services are useful for parsing through public and private sources of threat intelligence.
- Incident Analysis: Attempt to determine whether an incident has actually
occurred by investigating the accuracy of the precursors and indicators described in the previous step. NIST SP 800-61 lays out several recommendations for making analysis easier and more effective.
- Incident Documentation: Implement an issue tracking system to record all pertinent information about each incident. Third-party risk management platforms will typically provide document management capabilities for vendor incident tracking.
- Incident Prioritization: Because of inevitable resource limitations, NIST recommends prioritizing incidents based on their functional impact, information impact, and recoverability. Tiering your vendors and suppliers for monitoring and assessment on the frontend can help you be ready to respond appropriately when incidents do occur.
Containment, Eradication, and Recovery
- Containment: This is where security teams attempt to “stop the bleeding” and minimize the impact of an incident. Containment tactics vary depending on the type of incident and can involve suspending an errant user account, blocking network traffic, quarantining systems, redirecting attackers to a sandbox, and other actions. Deciding on a course of action requires weighing several criteria including potential damage, need for evidence preservation, service availability, available resources, and more.
- Evidence Gathering: While necessary for resolving the incident, evidence gathering is also critical for informing any subsequent legal proceedings. It’s important to get legal input on evidence gathering and record-keeping requirements to ensure that evidence will be admissible in court.
- Identifying Attackers: While NIST SP 800-61 emphasizes the need to focus on containment, eradication, and recovery, the guidance does indicate a few ways to potentially identify attacking hosts. These include validating attacking hosts’ IP addresses, search engine research, incident databases, and monitoring attacker communication channels. Third-party cyber risk monitoring can assist with these efforts.
- Eradication and Recovery: Eradication is the process of removing malware, disabling compromised accounts, and mitigating exploited vulnerabilities – while recovery is the process of restoring systems to normal operation. Third-party risk management providers often offer remediation services to assist with security exposures.
- Identifying Lessons Learned: Hold a de-briefing session to review the incident, how it was handled, and how to improve incident handling moving forward. The resulting reports can be used for internal communication and training – as well as for making updates to documented processes.
- Leveraging Incident Data: Data such as number of incidents, time spent handling incidents, and objective and subjective incident assessments can be used for several purposes including identifying systemic security weaknesses and justifying additional investments. One application for third-party risk management is identifying additional controls to inquire about in your vendor risk assessments.
- Creating an Evidence Retention Policy: The final step is defining a policy for retaining incident evidence based on potential use in legal cases, broader data retention policies, and cost constraints. A third-party risk management platform can help store, tag and catalog evidence and documentation related to specific third parties.
Accounting for Third Parties in Your Incident Handling Strategy
Ready to account for vendors and suppliers in your incident handling planning? Start by considering two simple questions:
- Are there any third-party organizations connected to your network? Could they be a source of a malware infection?
- Do any third parties have your data in their environments? Could you be impacted by a ransomware infection that hijacks their data stores and backups?
If you answered yes to either question, then it’s critical to account for third-party risk in your incident handling process – as covered in the above NIST 800-61 summary.
At the same time, be sure to incorporate questions about incident handling processes in your third-party risk assessments. Start with broad questions during vendor sourcing and selection. For instance, does the potential vendor even have an incident response plan? Then, build questions about their specific attack prevention, detection, and response strategies into subsequent assessments. Inherent risk assessments should turn up any notable weaknesses prior to onboarding.
Finally, complement your periodic assessments with continuous external monitoring to identify potential third-party exposures and incidents before they impact your organization.
Ensuring Resilience and Availability in Response to Third-Party Breaches
We’re becoming more reliant on products and services from others all the time, but in many cases, haven’t adapted our incident handling controls and processes to include “what if?” scenarios regarding third-party incidents and breaches. At a minimum, your third-party risk management practices should focus on maintaining resilience and availability when faced with malware infection, data exposure, illicit access, or compromised supply chains (e.g., SolarWinds and others).
For more guidance on this topic, watch the on-demand version of my webinar, How to Prepare for the Next Third-Party Attack, or check out Prevalent’s Third-Party Incident Response Service, which can help you quickly discover, score, and remediate risks from vendor breaches.