The shared responsibility overlap for vendors using cloud services can create a gap where the cloud service provider (CSP) functionality exists but may not be properly configured by the vendor. Reports can help identify issues in that gap, including advisor
reports; Service Organization Control (SOC) 2 reports; Cloud Security Alliance (CSA) Security, Trust, Assurance and Risk (STAR)/ISO reports; and penetration tests. However, they are all limited and nothing works as well as discussing the design with
the vendor’s security architect.
This piece details vendor cloud shared responsibility risk issues and recommends ways to ensure the gap between the CSP and the vendor is properly vetted.
When assessing vendors’ security posture, it’s important to review their configuration of cloud platforms for potential security gaps exposed by misunderstandings of the cloud
shared responsibility model. Specifically, if a vendor is leveraging a CSP like Microsoft Azure, AWS or Google Cloud Platform, the CSP is responsible for its security and the vendor being assessed is responsible for its products and services. Detailed information about both of these elements can be found in existing SOC 2 audits and published documentation, but it is considerably more difficult to verify the vendor being assessed has properly configured the CSP elements within its areas of shared responsibility.
READ: Third-Party Risk Management: Guidance for InfoSec Teams
CSP Outsourcing Complexity
The fundamental design flaw of the shared responsibility model can be expressed with the old adage, “If everyone is responsible, no one is responsible.” By outsourcing the complexity of operations to a CSP only to have the complexity of configuration
outsourced right back to the vendor by the CSP, it is far too easy to wind up in a situation where neither party configures that cloud’s components as a security design would warrant.
While the CSP can provide tools to simplify this process, such as the AWS Trusted Advisor, Azure Advisor and Google’s Security Command Center, those tools are limited to only the CSP’s view of best practices. Absent an understanding of how the overall product or service
is designed, the CSP’s recommendations are limited to generic best practices. Further, all the best practices that can be made a secure default have already been converted, so the recommendations that remain from those sorts of reports must
be re-contextualized to the vendor’s operating context. While it is appealing to request such a report, it is practically impossible to get one and, if one is obtained, it will not provide a comprehensive review of the overall environment’s
security.
Download: Six Key Control Areas of Cloud Security
Other Vendor Review Approaches
Some other approaches can provide similar information, such as:
- The SSAE 18 SOC 2 Type 2 audit includes some review of the shared responsibility areas. However, the depth to which the auditors go varies greatly
between auditors and between systems. While you can expect some elements, such as role configuration and access reviews to be well represented, some of the more technical practices, such as proper use of key management services, will be absent.
- The CSA STAR Registry approach involves the specific controls within the CSA’s Cloud Controls Matrix.
The different types of STAR reporting can be confusing. In short, if a vendor is listed in the STAR Registry as a Level 2 Certification, as is required under ISO/IEC 27001:2013, you can be reasonably assured its controls were properly reviewed. While,
generally speaking, a SOC 2 report is “better” than an ISO certificate for several reasons (such as auditor rigor and details disclosed in the report), the STAR alignment to SOC 2 is much weaker than its alignment to ISO, so the ISO certificate
should be viewed as more trustworthy when considered in this context.
- Penetration test results can cover this need as well, but care should be taken to ensure the pen test was properly scoped to include the overlap of shared responsibility. It is common for
penetration tests to be network-focused or application-focused, and either approach will typically not involve a third party’s systems. If presented with a pen test report during the due diligence phase of assessment, it is best to work with
the vendor to review the shared responsibility matrix for its offering and get written confirmation the testing covered those areas.
Use Manual Vendor Reviews
The better approach is very resource-intensive and involves dedicating time to working with a vendor’s engineer/architect. Clarifying how the service is designed and implemented should be understood as well as its controls and how its controls are
verified. While similar to the penetration test scoping approach above, this approach is significantly more detailed because it does a deep dive into specific items, such as whether each tenant has an assigned set of encryption keys, providing cryptographic
isolation of the multi-tenant environment. Determining which of the shared responsibility set of controls warrants such a deep dive and under which circumstances that level of analysis is warranted will vary significantly from company to company.
READ: 6 Ways to Optimize Vendor Management Programs
Shift-Left to Reduce Vendor Risk
As with all third-party relationships, there is a limit as to what can be done to improve the security of your vendors and partners. Recognizing this limit and taking internal action to reduce the risk of such relationships can be more effective than
analyzing third-party security using partial data from reporting. By minimizing data sets, tokenizing critical data elements and verifying data deletion practices, you may be able
to reduce a vendor’s risk rating to such a point where a gap in security between the vendor and its cloud platform is low enough that the risk is acceptable.
As with all shift-left approaches to security, emphasizing resilience in this way will only get you so far, but where it works, it can be extremely powerful and cost-effective.
Risk-Based Steps for Vendor Security
It can be difficult to get all the information you need to feel comfortable about a vendor’s security posture. However, you can get close by following some key steps:
- Check the STAR Registry: If the vendor has a Level 2 ISO certificate, that is the best validation you can get.
- Review advisor and SOC 2 reports: These reports aren’t as comprehensive, but they are better than nothing.
- Talk to the vendor’s security architect: Context is key and discussing the context of any reports you review with an expert will help you the most.
Fundamentally, there is no way to know for certain a vendor is properly using its cloud controls, but there is also no way to know if it is properly using its non-cloud controls. The situation is not that different than it was pre-cloud. Outsourcing is
inherently risky and by making the decision to outsource, the business has already accepted that risk. Make sure your reviews aren’t consuming more time/resources than the risk of the vendor warrants.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.