Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
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
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
Download: Six Key Control Areas of Cloud Security
Some other approaches can provide similar information, such as:
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
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.
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:
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.
February 21, 2024
By IANS Research
Learn why cloud IR is critical to security and not just another box to check. Find guidance to get started building a strong cloud IR program.
February 15, 2024
By Alex Sharpe, IANS Faculty
IANS Faculty member Alex Sharpe discusses the risks around AI adoption and provides governance guidance to make your AI launch safe and mitigate risk.
February 13, 2024
By IANS Faculty
Learn how to how to use NIST to modify secure baseline configurations to account for risk and improve security posture.