3 Golden Rules of Modern Third-Party Risk Management

SaaS-to-SaaS integrations are an inherent part of modern software-as-a-service use in business, and the adoption of third-party services is scaling rapidly to adapt. Malicious actors aren't lagging behind. They realize the lucrative benefits of leveraging these integrations to steal, leak, or abuse organizational assets.

Traditional third-party risk management (TPRM) solutions were introduced to help streamline and automate compliance processes. Recent supply chain breaches, such as the malicious third-party OAuth token abuse that affected GitHub customers, show how threats grow while SaaS use scales, making it imperative for business requirements around third-party risk evaluation and management to shift. The cybersecurity community's approach to these risks must shift accordingly.

While TPRM solutions serve a noble purpose — assessing the security of an organization's vendors — their value stops there. A vendor could be considered healthy in terms of its security controls, with a low-risk score, but only as a stand-alone vendor and regardless of its required integration and interaction with the organization and its valuable assets. Risk assessments, questionnaires, and aggregated data are time-consuming and costly to manage and provide minimal value without the proper context and holistic strategy to govern them.

Here are three critical considerations that should be top of mind as you assess and onboard third-party vendors:

Can You Continuously Assess Their Access Level and Business Impact Risk?

Existing TPRM solutions usually lack the context needed to understand the scope and nature of SaaS-to-SaaS integrations with third-party vendors. Given the dynamic nature of the SaaS sprawl, this can introduce tremendous amounts of (otherwise avoidable) risk. As part of the onboarding process, organizations must be able to accurately gauge critical elements of this partnership: Is the original business impact assessment aligned with the actual interaction with the vendor? Is the initial vendor assessment aligned with the permissions granted and the organizational need for the vendor? Did the relationship with the vendor or business requirement change over time?

TPRM questionnaires must be customizable and allow organizations to evaluate and manage vendors according to their associated business risk. Vendors that are crucial to your business and require access to sensitive information such as employee or customer data should be assessed using different parameters from those used to assess a lower-risk vendor.

Adding to this complexity is the interconnectivity between vendors. As the number of vendors grows, so does the number of connections. Supply chain management requires comprehensive visibility into all vendors and the vendors connected to them. Without such accountability, an organization can be breached through a third-party integration it wasn't even aware existed in its supply chain. For example, Salesforce may have third-party plug-ins that access sensitive data and personal identifiable information (PII) in Salesforce and therefore may pose a risk for an organization that uses Salesforce but is unaware of other vendors connected to it. In such a case, the vendors behind such plug-ins should be assessed accordingly.

Do You Have a Vendor Offboarding Process?

This is a deceptively simple question that has profound implications for third-party risk management. When an employee leaves the company, their privileges are revoked using a dedicated identity access and management (IAM) offboarding process, yet there's no similar procedure to offboard vendors. Making matters worse, vendors are onboarded daily by multiple functions across the organization. Even if a TPRM assessment process is triggered, it is set and forget, without the necessary continuous reassessment over time as the vendor access drifts from the initial setup.

What follows is a veritable vendor graveyard. Some vendors may have been onboarded during a previous vendor selection process, one was chosen, but the other two remain dormant and connected to the organization, usually with high privilege access that is never revoked. It is imperative to realize that even if you terminate your tenant on a vendor's platform, it doesn't mean you revoked its tokens to your environment.

Most organizations fail to adopt the required processes that answer this significant question: Is the vendor still used by the business unit? Without a periodic review of your vendors, their access privileges, who uses them, and how — you will have no way to establish and assess their risk.

Can Your Vendor Risk Processes Scale to Support a Decentralized IT Organization?

In a modern organization with dozens or hundreds of SaaS applications, IT is now decentralized and end users, citizen developers, and business owners onboard new third-party vendors daily. The lack of continuous supply chain risk assessment as the organization becomes more decentralized renders initial vendor evaluations irrelevant and outdated. As a result, security teams are increasingly unable to detect if a vendor has altered its characteristics, if its access into the organization has widened, or worse — if it has been compromised.

It's therefore critical to ask whether the vendor's business impact has increased over time and whether it requires a new assessment. Manually assessing vendor privileges and integrations is impractical and quickly becomes irrelevant in an increasingly agile and dynamic SaaS environment. Adding to this burden is the lack of awareness on the part of users and even system administrators of the importance of updating assessments and ensuring they're aligned with current needs and requirements. The absence of a clear policy defining when and how to conduct inventories of vendor integrations prevents common-sense changes from being implemented.

Make Room for Changes

A uniform approach to third-party vendor assessments is a near-sighted, partial solution to a dynamic problem.

Vendors differ in their essential purpose, with some geared toward low risk and others requiring access to personal or financial client information which, if leaked, lost, or stolen, could pose significant harm. Therefore, the security community must expand existing TPRM approaches to adapt to the vendor risk management life cycle and ensure its effectiveness in securing SaaS-to-SaaS integrations in the dynamic digital enterprise.