Cloud security vendor Wiz has announced PEACH, a tenant isolation framework for cloud applications designed to evaluate security posture and outline areas of improvement. The firm stated that the framework has been developed on the back of its cloud vulnerability research to tackle security challenges impacting tenant isolation.
Security boundaries, incohesion, transparency impacting tenant isolation in cloud applications
In a blog post, Wiz wrote that there have been several cross-tenant vulnerabilities in various multi-tenant cloud applications over the last 18 months. These include ExtraReplica and Hell’s Keychain. “Although these issues have been reported on extensively and were dealt with appropriately by the relevant vendors, we’ve seen little public discussion on how to mitigate such vulnerabilities across the entire industry,” Wiz stated. What’s more, the root cause of these vulnerabilities – improperly implemented security boundaries, usually compounded by otherwise harmless bugs in customer-facing interfaces – is significant, the firm added.
The Wiz research team said that, over time, it discovered a problematic pattern, outlined as:
- There is no common language in the industry to talk about best practices for tenant isolation, so each vendor ends up relying on different terminology and implementation standards for their security boundaries, making it difficult to assess their efficacy.
- There is no baseline for what measures vendors should take to ensure tenant isolation in their products, neither in terms of which boundaries they’re using or how they are implemented.
- There is no standard for transparency – while some vendors are forthcoming about the details of their security boundaries, others share very little about them. This makes it harder for customers to manage the risks of using cloud applications.
Speaking to CSO, Rik Turner, senior principal analyst at Omdia, says that when vulnerabilities affect cross-tenant cloud databases/applications, the risks for organizations are significant. “The risks for enterprises storing their data in cloud databases is clearly huge, since anyone able to leverage such a vulnerability would be able to exfiltrate data from multiple tenants.” He thinks public discussion about how to mitigate such vulnerabilities is getting better as more enterprises move to the cloud, but admits there is room for more, particularly in the technical forums where defenders congregate to discuss tactics and strategies.
Experts from the Cloud Security Alliance (CSA) agree. “As multi-tenancy is focused on public cloud usage, of which typically shares an ecosystem with multiple companies, there can run a risk of data breaches and/or corrupted data,” Josh Buker, CSA research analyst, tells CSO. If there is a misconfiguration from the vendor or customer’s side, spread from one tenant to another is also likely, as well as the possibility of malicious tenants, he adds. “The additional challenge on top of this risk is the cost effectiveness and difficulty in retaining or otherwise acquiring expertise that a business may not have.”
What is typically not discussed enough in this area is the shared responsibility model between cloud service providers and customers, says John Yeoh, global VP of research, CSA. “I continuously see companies resting on the idea that cloud providers are securing both ends of the spectrum when this is simply not true.”
PEACH’s two-stage process to tenant isolation
Wiz said that PEACH follows a two-stage process to tenant isolation, the first being isolation review. This stage analyzes the risks associated with customer-facing interfaces and determines:
- The complexity of the interface as a predictor of vulnerability
- Whether the interface is shared or duplicated per tenant
- What type of security boundaries are in place (e.g., hardware virtualization)
- How strongly these boundaries have been implemented, using the following five parameters: privilege hardening, encryption hardening, authentication hardening, connectivity hardening, and hygiene (PEACH).
The second stage in the process consists of remediation steps to manage the risk of cross-tenant vulnerabilities and improve isolation as necessary, Wiz stated. “These include reducing interface complexity, enhancing tenant separation, and increasing interface duplication, all while accounting for operational context such as budget constraints, compliance requirements, and expected use-case characteristics of the service.”
Wiz claimed that by using the PEACH framework, it was able to conduct a root-cause analysis of ChaosDB, a cross-tenant vulnerability in Azure Cosmos DB. “To the best of our understanding, each tenant’s embedded Jupyter Notebook ran in a container nested within a virtual machine. Although this might appear to be a strong isolation scheme, the interface’s hardening factors revealed critical gaps at the implementation level.”
Addressing cross-tenant vulnerabilities in cloud applications
Turner says the best strategies for mitigating cross-tenant cloud application vulnerabilities include:
- Scan for scattered plain text credentials and secrets at all stages of the pipeline in CI/CD, code repo, container registries, and within the cloud.
- Lock down privileged credentials to container registries.
- Use image signing verification, which can be done with admission controllers.
- In the context of K8s API, avoid misconfiguration of pod access, since this can lead to unrestricted exposure of a container registry.
Sean Heide, CSA research technical director, advises businesses to follow structured frameworks and standards that specifically help address cloud environments. “One of which is the Cloud Controls Matrix by CSA. We also suggest designing, developing, deploying and configuring applications and infrastructures so tenant user access and intra-tenant access is appropriately segmented and segregated, to include monitoring and restrictions from other tenants,” he adds. “Proper expertise is needed to partner with cloud service providers and best take advantage of the security features they offer.”
Copyright © 2022 IDG Communications, Inc.
