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 e