Organizations partner with third parties when the benefit to the organization is perceived to be greater than the risk of outsourcing. With access to third-party expertise, organizations increase their opportunities to offer more services, help more clients, become more efficient, and generate more revenue.

While the benefit outweighs the risk for many third-party relationships, partnering with third parties increases your attack surface twofold. You are at risk of an attack not only through the additional connections to your third party, but also through the supply chain introduced by the third party. As recent high-profile third-party incidents have shown, the question of third-party incident response is not necessarily "if" an incident will occur, but "when" and "how severe" an incident will be.

Having a plan for responding to third-party incidents when they occur is paramount to the incident management program and strategic success of the organization.

Know Your Vendors

You may have heard the phrase "the best offense is a good defense." In the case of incident management, this statement could not be more true. While vendor management may not be the most glamorous component of third-party incident response, the steps you take now to oversee vendors will greatly benefit you and your organization in the future.

To prepare for a third-party incident, ensure the following items are included in your vendor management program:

  • Contact Information: A best practice is to maintain up-to-date contact information for your third parties. When you find out about a third-party incident, the last thing you will want to do is scour the internet for a working phone number or email address. Scheduling routine check-ins with your third parties to confirm their contact information is an easy way to save time during incident response.
     
  • Agreements: Ensure agreements between you and your third parties define what incidents must be reported to the organization and how soon they must provide notice. The Interagency Guidance on Response Programs states, "an institution's contract with its service provider should require the service provider to take appropriate actions to address incidents […] including notification to the institution, as soon as possible." In addition, a recent rule by the FDIC, OCC, and FRB requires certain third parties (subject to BSCA) to notify their customers in the event of "a computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, covered services [...] for four or more hours."
     
  • Due Diligence Documents: Request and review third-party due diligence documentation, such as business continuity plans, incident response plans, service level agreements, and SOC reports. Ensure the third party maintains controls equal to the level of controls maintained by your organization for the services being provided.

The Waiting Game

When it comes to third-party incident handling, there is a fine line between being prepared and being paranoid. While your third parties may not experience a business-halting incident every day, one could happen at any time.

The good news is if your agreements require them to notify you of an incident, you just need to keep performing excellent vendor oversight. They will let you know if anything needs your attention, or they risk facing legal consequences. If, however, your agreements do not address incident notifications, you will need to determine another form of learning if the third party experienced an incident and/or consider renegotiating the terms of the contract.

"There's been an Incident."

Game time. Whether you receive notification via email, phone call, or you saw an article about the incident while scrolling through LinkedIn, it's time to put your incident response plan into action.

The early stages of third-party incident response are some of the most critical. The longer an incident is allowed to occur, the more damage it can cause. However, incorrect handling of an incident can cause even more damage. Assemble the team, enact the plan, and avoid calling an audible, if possible.

So… What's the Plan?

Your plan should include steps to follow through the six-stages of incident response, per the NIST Computer Security Incident Handling Guide.

  • Detection: During the detection stage, you find out about the incident. As part of detection, it is important to identify the lead incident handler, gather statements provided by the third party, and document as much information as you know about the incident. You will thank yourself later.

  • Analysis: A goal of analysis should be to determine if the incident applies to you and how severe it could be. During the analysis stage, the team should review any third-party statements about the incident. This information can be used to determine if the incident applies to you through an assessment of things like the incident's scope, origins, occurrence patterns, and classification.

  • Containment: If you are or could be affected by the incident, steps must be taken to isolate the incident and prevent further damage. Depending on the analysis, some containment strategies to consider include revoking the third party's access to your systems and suspending processes for services supported by the third party.

  • Eradication: Eradicating the incident will largely depend on the nature of the incident, as well as your environment. Often, third parties will include recommendations for containment, eradication, and recovery in their official statements (e.g., installing patches, enabling or disabling certain system functions, etc.).

  • Recovery: Take steps to mitigate all exploited vulnerabilities. These may be provided to you directly by the third party. You will want to consider performing functional testing and ensuring the third party's systems were evaluated before resuming services.

  • Post-Incident: In your post-incident activities, you will want to confirm the root cause and all evidence were fully documented with the incident record, document the incident in the vendor management program, update the third-party risk assessment, and consider scheduling more frequent reviews for the third party. Document lessons learned from the incident response process and use the information to update your incident response plan.

For a full list of steps to follow, download our Third-Party Incident Checklist.

Conclusions

While there are a lot of benefits to engaging third-party service providers, if a third party experiences an incident, the organization may be held accountable for the effects. Having a clearly defined response plan can help avoid confusion, reduce damage, and more efficiently return operations to normal after an incident.

For more information about managing incidents, check out Tandem Incident Management. Featuring supplemental checklists (e.g., data breach, fraud, ransomware, etc.), a robust framework based on the NIST Computer Security Incident Handling Guide, and integration with Tandem Vendor Management, Tandem can help put your organization ahead of the curve for third-party incident response.

Update Log: