Risk is inevitable with third party vendors that have access to your company and client data. With expanding attack surfaces, dispersed supply chains, and IoT issues on the rise, TPRM (third party risk management) is becoming a more mission-critical security practice in the cloud. Let’s look at problems and solutions.
What is third party risk?
A widget where you’ve stored passwords becomes the entry point into the enterprise, which was otherwise well-protected. A third party that handles your data processing falls prey to a simple email-based attack. Your third parties have fourth parties that they may have no control over.
What’s a security manager to do? Assess third party risk prior as part of the vendor selection process. Prior to providing access to sensitive data or outsourcing critical business processes, conduct due diligence on every vendor before signing a contract. Ensure vendors will guarantee to meet your security requirements, use a risk-based approach assess them regularly, and track their performance in security as you would other service levels.
Cloud service providers are vendors too and must be considered in TPRM diligence. However, the ease of access in purchasing these services enable end users to bypass important security controls. Let’s say Fred in accounting signs the enterprise up for an unvetted cloud service using a company credit card. Within a few minutes, he installs the app and starts putting sensitive or regulated data into a misconfigured public cloud. In years past, setting up an external service typically required special access through your IT team. Today, you don’t need to be technical to create a shadow IT problem for your company. If the service is free, you might not even need a credit card.
Scenarios such as these remove significant controls that protect sensitive data. You may have configurations and controls to catch things after the fact, or even to prevent them—perhaps your firewall will block the service, or finance will catch a new subscription—but these are not universal.
Shadow IT is a big problem in the cloud. Additionally, you will generally lose the ability to negotiate a contract with third parties, not to mention their fourth parties. The terms of service are what they are, and you can’t dictate security controls and responsibilities, especially to the larger services.
Shared responsibility matrix with third party cloud services
The specific security services from your cloud service provider will vary based on the type of service: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Service (SaaS). At one end, IaaS controls the cloud fabric and infrastructure, and you get a bare virtual server. From the Operating System (OS) level on up, security is your responsibility. At the other end, SaaS gives you an application with limited ability to configure it. While you control things like access, much of the underlying security is the provider’s responsibility. Note that the categories may bleed into one another. For instance, Microsoft Azure and Amazon Web Services offer IaaS, but also offer plenty of services that would fall into PaaS.
The exact dividing lines are not critical. What is critical is to understand where your service contract falls on this spectrum, and to understand your security responsibilities as well as theirs. This demands a security architecture and design that documents where the specific security controls lie, and what roles or software implements them. This is critical to determine up front as part of the vendor due diligence process. Pay special attention to contractual requirements for response management, and game it out to include outages and compromises.
Vendor risk assessments
In a Preliminary Vendor Risk Assessment, you need to know what data is flowing to the cloud, what is happening to it there, what data is flowing back to you, and what data may be flowing to fourth parties. This lets you establish a basic risk rating. This is not a full blown NIST 800-30 or FAIR Risk Assessment, but a high-level rating based on a few key factors. For instance, any data flow involving PII or PHI is probably going to get your highest risk rating since a compromise of that data will trigger regulatory breach notification requirements and result in significant liability.
On an ongoing basis, you may then decide to modify that risk rating based on various mitigating factors. A key outcome of the due diligence exercise will be your ongoing risk treatment; specifically, how deep you intend to review the vendor. If the vendor is refilling your candy machines, then the physical access is your main risk, and you aren’t likely to do a deep review of its IT infrastructure unless the candy machine is connected to your network. On the other hand, if the vendor is receiving and processing PHI, possibly involving a fourth party, it will be getting your highest level of review—external certifications, onsite inspections, and penetration testing, for instance. Again, make sure this is in the contract before you sign.
Every cloud provider and new vendor onboarded should have an associated data flow, and every vendor risk assessment should strive to validate that the data elements mapped are still valid. This may involve a multi-pronged discovery effort, including manual discovery from interviews with users, review of procurement records to identify ongoing payments to third parties, firewall traffic analysis, and, if you have one, use of a Cloud Access Security Broker, or CASB. The CASB is a vital tool in combatting shadow IT by knowing what goes where, and how it is secured. Identifying the data flows to the cloud and putting teeth in the enforcement of your policies are critical to getting this problem under control.
Relying on External Audits?
Very often, you will have to rely on an external audit (ISO, SOC, etc.) conducted on the provider. These audits can provide an in-depth, objective, technical review of the third party’s security. What they demonstrate is that the vendor is trying to align their security program with a commonly accepted standard. These reports might be your best available resource for understanding a cloud provider’s risk—make sure you read them right.
Some key points to consider when reviewing external audit and certification reports:
- Is the business stream and/or application listed in the scope included in the products or services provided by the vendor?
- Are all the products or services provided by the vendor in scope?
- Are all required regulatory requirements in the scope?
- Are the control categories adequately addressed?
- Are all vendor locations that provide the service/product in the scope?
- Are relevant sub-contractors included in the scope?
- Is the timeframe (when the audit was conducted) of the report/certification relevant/current?
- Is the report the result of a point-in-time assessment or a review over a period of time?
- Is the certification current, and have mandated interim or surveillance audits been carried out?
- Internal or external audit? If external, conducted by a reputable company? If it is a certification, is it by an accredited organization?
Does shared responsibility mean shared risk?
Let’s assume that you do have a reasonable level of access, documented in the contracts with the provider. The likelihood—not the certainty—is that basic security hygiene has been taken care of.
You can also use the contract to transfer some of the risk to the cloud provider, who will want to assume as little risk as possible. As an assessor, review the contracts and service level agreements to understand what, if any, risk they assume. If it’s “little or none,” then look to cybersecurity insurance policies. Review them carefully to make sure that the policy addresses appropriate risks and at a reasonable level. Legal advice is critical here.
In conclusion, the new and evolving world of cloud services means that we need to reconsider and adapt our methods of assessing vendor risk. There are ways—from due diligence to ongoing reviews—but constant vigilance is the price to be paid.