Good Guidance on Third-Party Cyber Risk

Good news if you’re still smarting from that Amazon Web Services failure earlier this week that paralyzed large swaths of the business world! Regulators in New York just released fresh guidance about how to manage the cybersecurity risks of third-party technology providers. Apparently we all need a refresher course, so let’s take a look.

The New York Department of Financial Services released the guidance on Tuesday, the very same day that the AWS outage made headlines around the world. Technically the material is intended for financial services firms that do business in New York, to help them comply with the state’s Cybersecurity Regulation — but the points raised in the guidance are good and useful for internal auditors and risk managers everywhere, regardless of your industry or geographic location.

For starters, the guidance emphasizes the importance of senior-level accountability for, and engagement in, cybersecurity risk management. For example… 

Senior governing bodies and senior officers must engage actively in cybersecurity risk management, including the oversight of [third-party]-related risks … Senior governing bodies must have a sufficient understanding of cybersecurity-related matters to exercise appropriate oversight, which includes the ability to provide a credible challenge to management’s cybersecurity-related decisions to ensure that those decisions align with the entity’s overall risk posture and resiliency objectives.

That’s a fancy way of saying the board needs to know enough about cybersecurity to ask probing questions of the management team about cybersecurity risk. It’s not enough for management to present a seemingly thoughtful risk management plan and the board gives a cursory, “Sure, sounds good to us!” The board needs enough expertise to know whether that plan addresses the right issues or is just a pile of baloney.

Most importantly, the board needs to be able to weigh the pros and cons of relying on third-party service providers. For example, using SaaS providers to run all your mission critical business processes might bring lots of operational gains, but managing the security risks from so many service providers could also be an internal controls nightmare. You need a board that can evaluate the trade-offs in operational gains versus business risks and decide on the wisest course of action. 

OK, enough big picture. Let’s delve into the nitty-gritty. 

Due Diligence on Third-Party Providers

The DFS guidance spends lots of time talking about how to select a third-party service provider: the due diligence you perform on each one, and wise criteria for making a final choice. 

Specifically, the guidance offers 10 bullet points that internal auditors, CISOs, and vendor risk managers could incorporate into your vendor risk assessment process. For example… 

  • The type and extent of access to your IT systems and non-public information that the third party will have.
  • Whether the third party maintains and regularly tests its incident response and business continuity plans.
  • The third party’s practices for selecting, monitoring, and contracting with its own downstream service providers (that is, your fourth parties).
  • Whether the third party uses unique, traceable accounts for personnel accessing your IT systems and whether it maintains audit trails meeting the requirements of the Cybersecurity Regulation.

Those are all good points for a vendor risk assessment, as are the other six mentioned by DFS. By all means, take the issues tucked inside each one and include it in your vendor evaluation process somehow. 

I’m more concerned about the larger context here: Do you have an ability to assess each vendor and the security risks it poses, so you can manage those risks in an appropriate way?

For financial firms, that’s a requirement of the Cybersecurity Regulation: “Covered entities should develop a tailored, risk-based plan to mitigate risks posed by each third-party service provider.” 

So what do audit or risk management teams need to have in place — what information do they need to know; what tools do they need to have — to execute those tailored, risk-based mitigation plans for each vendor? That’s the bigger question CISOs and vendor risk managers should ponder. 

For example, the DFS guidance includes this rather bland statement: “Covered entities must assess the cybersecurity risks the third-party poses to the covered entity’s  information systems and non-public information.”

But consider everything you need to have or know so that you can perform that assessment:

  • You need to know where all your non-public information is, and who accesses it.
  • You need to know exactly what service the third-party is providing; what specific function it is performing in which business processes.
  • You need an ability to assess the vendor’s risks, whether that’s through a simple questionnaire (woefully inadequate, but at least a start) or more thorough SOC audits or your own security tests.
  • You need an ability to monitor the third party in case its own operations (and security risks) change over time. You need both the technical ability to do that work, and the legal right to do it via contract language.

Well, do you have the resources for all those needs, and have you fashioned them into a rigorous, disciplined process? (Including the use of some GRC automation tool, perhaps.) Because that’s the only way you’ll be able to govern third-party cybersecurity risks at scale and on a sustainable basis.

If you don’t have that mature, robust risk assessment process, then at least to some extent (and possibly a great one), you’re going to reinvent the due diligence wheel every time. 

Burdens on the Third Parties

Another part of the DFS guidance walks through the security and compliance provisions that financial firms “should consider” including in their contracts with third-party service providers. For example:

  • Requirements for third parties to develop and implement policies and procedures addressing access controls, including multi-factor authentication, that comply with the Cybersecurity Regulation.
  • Provisions for timely notice to the firm of any breach or other incident that  directly affects your IT systems or data. 
  • Requirements for the third party to disclose the use of subcontractors that may have access to your data or IT systems, as well as the ability of your firm to reject the use of certain subcontractors.

Those are all sensible contract provisions from the perspective of you, the firm contracting with a third party. You won’t necessarily want to impose all the DFS recommendations (there are seven in total) on every third party; you can tailor your requirements to the specific third party and the purpose you want it to serve in your IT environment. (Again, that also means you should know exactly why you’re hiring a third party in the first place.)

I’m more curious about the third-party service providers out there: are you prepared to meet all these potential contract demands? 

third-party

Kelly’s Law of Third-Party Risk.

That is, the more you’ve built your own robust system of cybersecurity, and can demonstrate that security posture to potential customers, the more quickly you’ll be able to get through the customer’s risk assessment process. And as we can see from this post, regulators are pushing firms to make sure that their risk assessment processes are thorough. 

So how can you, third-party provider, document your access controls (including proper use of multi-factor authentication)? How can you demonstrate good governance over your own third parties, who are your customers’ fourth parties? How can you demonstrate your policies and procedures for encryption, breach notification, data transfer, and more?

Your ability to do that, and do it well, will be a key selling point in today’s risk-addled world.