Over the past year, the Wiz research team disclosed several critical cloud vulnerabilities such as the AWS IAM cross-account vulnerabilities, ChaosDB, and OMIGOD. In each, there was a startling level of uncertainty around who was responsible for what between security teams and the Cloud Service Providers (CSPs). This lack of certainty hampered customers’ remediation efforts and sowed confusion between them and CSPs. It struck me that while the shared responsibility model in cloud infrastructure was (over-) discussed, the same cannot be said for the vulnerability disclosure and response model in the cloud.

In this post, I lay out why we need a shared response model for cloud vulnerabilities, review the current state, and describe what a more transparent and scalable model could look like.

The need for a shared response model to cloud vulnerabilities

Operating in the cloud does not absolve customers of their responsibility to actively manage security. However, security does not fall entirely on the shoulders of customers. In reality, it is a balance between CSPs and customers, particularly when it comes to securing cloud services. We have seen how this balance plays out and falls short as major cloud vulnerabilities were disclosed over the last year.

The recent Log4j vulnerabilities triggered an unprecedented number of CVE advisories by affected software vendors, while CSPs managed their advisories through a long list of updates mixed with required actions by customers (AWS and Azure advisories). Customers were expected to read and implement the advisories without any form of tracking.

This is exactly how CSPs responded to the cloud vulnerabilities Wiz discovered and disclosed earlier in 2021. For example, when the AWS IAM cross-account vulnerabilities were disclosed, AWS updated their documentation and alerted vulnerable customers via email. After the update, any customers that didn’t follow the outlined manual steps were left exposed. ChaosDB was disclosed responsibly to Microsoft, which fixed the vulnerability and updated only customers “affected by the research activity”, via email, with an obscure description of the vulnerability and the required manual actions on their end: key rotation and network access configuration. This vague notification process triggered mass response among customers and media.

These cases illustrate the challenges that customers face trying to understand and prioritize their response to cloud vulnerabilities. For customers, maintaining a strong security posture requires transparency from CSPs in terms of what CSPs will and will not address from the areas of the stack that they control and an efficient way to enumerate and track the required actions. Without transparency and tracking, customers can’t know if they are vulnerable or how best to respond when issues arise.

Where we fall short: the ChaosDB example

Let’s dive into ChaosDB to think through the shared responsibility model as it is handled today.

The media picked up on Microsoft’s security notification and dramatically raised public awareness. Had the media not provided such extensive coverage, the vulnerability would have ended with nothing but an email to the customers Microsoft believed to be affected. Several aspects should be scrutinized:

1. What is the proper way to update customers about the required mitigative actions? Merely updating documentation and sending emails are the de facto standards, but they are clearly inadequate.

2. Who determines the scope of the notification? Wiz researchers believe that Microsoft should have updated thousands more customers.

3. How can customers easily understand what happened and how to respond? The guidance from Microsoft included a flurry of documentation links that were very difficult to piece together.

4. How can customers or CSPs assure that the requested remediation actions were performed? The ChaosDB response was to rotate the Cosmos DB cloud keys, but these keys don’t have a “last updated” record.

5. Given the rapid pace of change in the cloud, how can customers learn when their security baselines change? When Jupyter Notebooks were enabled by default by Microsoft, customers had no meaningful way of knowing about their additional exposure or how to preemptively disable the new “feature.”

ℹ️For additional examples, see our earlier blog post on the need for a cloud vulnerability database.

These questions highlight that where we are today is not good enough. But what exactly does the situation look like for CSPs and customers when it comes to security reasonability? Let’s focus next on the current state of affairs.

The state of cloud vulnerability disclosure and response today

To understand the current state of cloud vulnerability disclosure and response, it is important to differentiate between CSP vulnerabilities and customer vulnerabilities:

• CSP vulnerabilities —Flaws in code, packages, default configurations, etc. in the infrastructure maintained by Cloud Service Providers under the shared responsibility model. ChaosDB, for instance, related to an integration between Azure services that was (nearly) silently enabled by default for all Azure customers.

• Customer vulnerabilities —Flaws in code, packages, default configurations, etc. in the infrastructure maintained by customers under the shared responsibility model. The recently disclosed log4j vulnerability (CVE-2021-44228), for example, involved a popular open-source logging framework that is embedded in many applications installed by customers on CSP infrastructure.

With this distinction in mind, let us analyze the security response process in terms of (1) Enumeration of threats and their severity, (2) Assessment of the affected resources, and (3) Remediation processes to mitigate the threats.

Clearly, CSP vulnerabilities are not currently handled in a rigorous, transparent manner.

The same basic framework can also be used to analyze risks arising from newly released cloud features (e.g. Jupyter Notebooks added to CosmosDB) and customer-controlled security configurations:

The current state affairs with respect to cloud features and security configurations also leaves much to be desired.

How can we bring the transparency and centralization that customers already enjoy with respect to customer vulnerabilities to CSP vulnerabilities, cloud features, and security configurations? We need a new model of shared responsibility in the cloud.

The shared responsibility model for cloud security

As a community, we’ve made good progress on clarifying software vulnerability patching by customers, but we lack a formal model in the other areas of the cloud shared responsibility model. Broadly speaking, it is not the CSP’s responsibility to secure software vulnerabilities or security configurations, but they should provide enumeration. CSPs must clearly explain what expected secure usage is for every resource, and what the alternative is. Customers need to understand what actions are required of them and be empowered to take those actions.

I propose the following model as a starting point:

CSP responsibilities

Cloud service providers should be responsible for:

• Enumerated cloud security benchmarks

• Threat model change log

• Cloud vulnerability database

Enumerated cloud security benchmark

An enumerated cloud security benchmark would be a vendor-provided enumerated list of secure configurations that are available to customers, along with their severity rankings and posture analyses. These should include a benchmark of all the features that may impact customers’ cloud security posture, and guidance on how to control them (hopefully programmatically). The enumeration should be updated as new features are released that impact threat models so customers could make informed decisions on their posture. Taking Azure CosmosDB as an example, the configurations that could be enumerated are:

• AZ-COSMOSDB-101: Rotate keys

• AZ-COSMOSDB-102: Configure FW restrictions

• AZ-COSMOSDB-103: Enable diagnostic logs

• AZ-COSMOSDB-104: Enable private endpoints

Threat model change log

A threat model change log would communicate to customers when a new benchmark becomes available or is updated. This information must flow from CSPs to customers because CSPs know when they make changes, such as connecting CosmosDB to Jupyter Notebook, that create new attack surfaces for customers.

Cloud vulnerability database

A cloud vulnerability database would define security flaws, assign unique identifiers to them, and clarify how to identify vulnerable services and products. It would also update customers when a vulnerability was identified and fixed, and share which resources were impacted. In addition, the CSP advisory should refer customers to the list of enumerated secure configurations that are required in order to mitigate and compensate for the vulnerability that the CSP identified. For a security responder, the cloud vulnerability database should serve as a clear call to action with what they’re expected to do. The goal is to move away from sending people to scattered documentation for different elements of the response.

This is how the ChaosDB advisory should have looked in a cloud vulnerability standard format:

Customer responsibilities

Customers should be responsible for:

• Vulnerability management

• Correct cloud configuration

Vulnerability management

Customers are and should remain responsible for managing and remediating cloud vulnerabilities.

Correct cloud configuration

Similar to the vulnerability management process, customers are responsible for following security benchmarks and applying them across the environment. To accomplish this, some CSPM point solutions are available, but they generally include a high level of subjectiveness around severity and implementation, creating noise and challenges for customers. This should be standardized and enriched with context just like the vulnerability management process.

The importance of a shared responsibility model for cloud security

CSPs and customers must work together to address cloud vulnerabilities. I believe something like the shared responsibility model laid out above would help CSPs and customers improve security posture while identifying and compensating for any gaps that may arise between the two parties. Overall security posture in the cloud is affected by every layer in the stack, and the response to a cloud vulnerability can include actions from the customer, the CSP, or both. With improved transparency and a clear model for handling cloud vulnerabilities and new features, we will be able to take large steps forward in our overall cloud security posture.

If you’re interested in this topic, the Wiz Research Team took a deeper look at the need for a cloud vulnerability database. Check it out here. Or you can join our Slack channel to discuss this topic directly with the Wiz Research Team.