Turning Your Third-Party Risk Program Upside Down

I have dedicated a good part of my career to inventing new ways to manage the growing threat from third-parties. Each year, third-party risk becomes a bigger risk and continues to evolve. First starting with supply chain partners, then expanding into scalable workforce, then to business process outsourcing, and now to cloud service delivery, as well as consumption and consumerization of technology. 

Historically the approach of evaluating third-party risk involved understanding the data type and regulatory information, as well as dollar amount of business (impact) and the maturity of a vendor’s security controls. Taken together, this would determine the likelihood of a failure in their security program that would cause a financial loss, brand damage, or even regulatory good standing to the organization.

While today’s third-party risk management processes have seen some innovation and scale with scoring, automation, monitoring, and exchanges, it is still behind other parts of security programs. However, as you look forward, things are about to change. 

Moving from third-party risk to application risk

The current process of evaluating a vendor’s infrastructure security and development practices will soon be obsolete. 

Business digitalization is quickly moving the majority of business workloads to cloud IaaS/SaaS applications. Combine that with “cloud first” business digitalization, and it results in a massive shift in how we look at our service providers. Most companies already have more applications running on SaaS and IasS solutions than they do on-premise. And in cases where applications are still on-premise, organizations are using middleware, APIs, and other technology to connect cloud services to access the data and information.

This means we need to make a fundamental shift in how we think about third-party risk. 

The focus needs to move from vendor risk to application risk.  This means moving away from vendor IT risk that focuses on the core infrastructure questions, (e.g. “Do you have written policies?”) to asking the questions that really matter to determine the security level in the cloud application world, such as: 

• “Show examples of your policy being applied to application development and support” 
• “What are the authentication methods implemented?” 
• “How often is the application been penetration tested?”
• “Do you have a bug-bounty program?”

Calculating application risk

Think about the fundamentals: the inherent risk and offsetting controls. To understand the business profile risk of the vendor, assess their financial stability and the country risk remains the same. Then the focus needs to turn to the application. First understand how much risk you have associated with an application, given the sensitivity of data and criticality of the application to your business operations. A combination of the business profile risk and the sensitivity/criticality is commonly referred to as “inherent risk”. 

The current best-practice is to do a validated assessment of the vendor’s security practices based on ISO27001/2, NIST 800-53/CSF, CSA CSM, or other similar security frameworks. Today we rely upon representations made by the third-party on their security practices and information that can be gathered from the internet about their infrastructure vulnerabilities. 

In the future, when your security team shows up to perform an onsite audit, they’re likely going to find the vendor is using cloud applications to develop and deploy their solutions with no infrastructure at all, and possibly not writing any application code either! That is the future of third-party risk. Moving from vendor risk to application risk and having the ability to understand how resilient the application is for availability, and how vulnerable it is to a possible disclosure. Shift your assessments to focus on the security and availability of the application, and choose a system that can provide application risk scoring. Some good standards for secure application development are Open Web Application Security Project (OWASP) or Building Security in Maturity Model (BSIMM).

Beyond third-party risk

Fourth-party risk has always been difficult to identify and, with the power of API’s, an application may be communicating with other applications to process or even store your sensitive information. 

Consider an application that you are using for analytics of confidential data. You contract an analytics provider that has seemingly a good system. You do your due diligence on the vendor’s financial standing and country risk, given the level of the sensitivity of the data, and you fully understand your inherent risk. Next is assessing the application risk of the system you will be using, as the vendor may have many applications in their portfolio. 

Once all of this is complete you feel that you understand the level of controls in place for the application and all is good. Except, unknowingly, the vendor stores all your data at a partner’s location. This is fourth-party risk. This can be in the form of transferring data, doing API calls for application functionality, etc. All of this exposure to your information has gone unchecked. Hence the need to understand all applications that the system uses and the data flows outside of the system.

Continuous monitoring

A vital part of the third-party risk program is to consistently monitor the health of the provider and the security of the applications. We are closer than ever to being able to continuously monitor controls in real time. This is where the elusive continuous risk monitoring comes into play. There are a number of controls that can be continuously monitored for critical health as it relates to security. Establish a regular cadence of evaluating the applications based on the level of inherent risk. Consider the application security testing tools as part of your program to validate the claims of the vendor. Implement automatic alert during times of change such as financial status, new releases, and acquisitions. 

Conclusion

We need to think differently about how we approach third-party risk and retool our strategies and systems to better understand application risk. Of course, being a realist, nothing is 100% and there will be hybrid environments just like we see in the cloud today.  But the trends are moving more to applications being built on cloud platforms and away from internally developed solutions. The time to rethink your strategy and investments is now.