Forget obscure bug classes—some of the sneakiest vulnerabilities hide in plain sight.
These are the by-design security issues—those vulnerabilities inherent to a system's functionality. They can often be well-known system ‘quirks,’ yet their full impact is under-explored. While traditional vulnerabilities require line-item code fixes, these by-design issues frequently demand a complete rethinking of a system and a total overhaul of its functionality.
When cloud service functionality deviates from the industry norms or customer expectations, the described ‘bug’ might be inherent to its design, yet it can have some profound security implications.
This post delves into these impactful, often structural cloud vulnerabilities, exploring why remediation of by-design security bugs requires more than a simple patch.
Feature Abuse vs. Insecure-by Design Vulnerabilities in Cloud Security
Let’s take a moment to define the edges of Insecure-by-Design vulnerabilities by contrasting them with Feature Abuse, or rather the intentional misuse of a feature, another common security issue in the cloud.
Feature Abuse - An Acknowledged Risk in Cloud Environments
Feature Abuse describes an actor using a cloud feature to advance a malicious goal. It does not indicate a vulnerability or flaw; instead, it represents the ill intent behind using a legitimate cloud feature.
Let’s highlight the standard functionality in IAM systems that allows for generating credentials for a user other than oneself. This capability defines lateral movement (and likely privilege escalation) with the recognized risk of intentional misuse. However, no vulnerability exists in an IAM system that allows one user to generate credentials for another. Instead, the industry works to prevent and detect this feature abuse with available mitigating controls.
Insecure-by Design - A Cloud Vulnerability Class
Industry expectations and norms extend to the security controls surrounding cloud-provided features. Insecure-by-design vulnerabilities can include insufficient control available by the cloud provider.
In the credential generation scenario described above, service consumers would expect authorization checks before issuing credentials and logging such events. The absence of these controls would expose customers to significant risk, indicating a design flaw in the service.
A more tangible example of an insecure-by-design vulnerability occurred recently within Google’s DocumentAI service. A user of Document AI could move Cloud Storage objects outside of the Project using the privileges of the DocumentAI service agent without the IAM system verifying that the end user had access to the objects.
The lack of expected authorization checks represented a considerable deviation from secure design principles.
Insecure-by-Design Vulnerabilities and the Shared Responsibility
As we can see, some of the most insidious security risks are baked directly into a system's design. These Insecure-by-design flaws become apparent when a service's functionality or available controls deviate from established norms and customer expectations.
Insecure-by-design flaws can be particularly frustrating in the cloud, where preventing service abuse is the customers' responsibility. However, due to the delineation of duties in the shared responsibility model, the service provider is responsible for making the necessary controls available, providing accurate documentation, and education to implement a service securely.
Mitigating the Impact of Insecure-by-Design Vulnerabilities in Cloud Services
Traditional vulnerability remediation often involves a straightforward approach: identify the faulty code, patch, and deploy the update. But this' fix-it-and-forget-it' mentality falls short when it comes to insecure-by-design vulnerabilities in cloud services. Why? Because two characteristics distinguish these vulnerabilities from classic vulnerabilities in a software package.
- These vulnerabilities are often deeply intertwined with service functionality or even underpin its fundamental principals, making a simple 'fix' impractical. Disabling or significantly altering the feature could disrupt countless workloads.
- With always-available APIs, functionality with abuse potential affects not just those who leverage the service but all customers regardless of whether or not they use the API.
A zero-sum mindset that focuses solely on 'fixing' the service limits the options for effective risk reduction. Instead, those focused on cloud safety need a more holistic strategy. This involves implementing preventative and detective controls to mitigate risks while exploring potential long-term solutions for the underlying design flaw. One powerful tool in this strategy is the use of guardrails.
Mitigating Controls: Guardrails
In cloud security, guardrails are preventative controls that enforce security policies and standards across an organization's cloud environment. They act like bumpers along a bowling lane, giving security admin assurances that usage won’t stray too far from a prescribed pattern.
Providing pre-canned guardrails can help mitigate cloud vulnerabilities. They are especially helpful for turning off or completely removing undesirable behavior. However, the effectiveness of guardrails diminishes when insecure features are deeply embedded in critical processes. In these cases, blocking access to the feature may not be feasible.
Mitigating Controls: Detection and Response
While preventative controls like guardrails are valuable, they aren't always sufficient. Implementation can be complex, and exceptions are often necessary to accommodate legitimate use cases. Moreover, more than guardrails and preventative controls are needed to help customers who already rely on insecure functionality.
That's why detection and building a nimble response are often the most valuable remediation activities when insecure functionality is identified.
When looking at detection and response as mitigating controls for cloud vulnerabilities, ask yourself these questions:
- Do customers receive high-fidelity signal of the offending behavior, or are additional logs needed
- Are the logs enabled by default, or does the customer need to be notified to allow for additional logging
- Can you rapidly act on the detection result to reduce and remove damage?
Sunsetting Insecure Cloud Functionality: The Long Goodbye
Introducing insecure-by-design features with abuse potential can prove costly for service providers. Once integrated into customer workflows, these features can be challenging to remove or modify due to downstream dependencies and assumptions in product and customer workloads.
While it's often possible to eventually remove or fix these vulnerabilities, especially with a phased approach and introducing more secure alternatives, the process is rarely quick. This is why guardrails and detective controls are crucial. They act as much-needed bandages, buying organizations and their customers valuable time to transition away from insecure functionality without disrupting business processes.
Detect Abuse & Implement Guardrails:
- Buy your development teams the time they need to transition away from insecure features in an orderly manner using the two levers of detective and preventative controls.
Sunset Functionality:
- Migrate existing workloads that depend on insecure functionality to more secure patterns. Discontinue the use of vulnerable features and finally sunset the offending APIs.
Shared Fate Approach to Cloud Vulnerability Remediation
Ultimately, addressing insecure-by-design vulnerabilities requires a shared fate approach. Cloud providers and their customers must work together, acknowledging the intertwined nature of their responsibilities.
Providers must be transparent when security controls fall short of expectations and create insecure-by-design vulnerabilities. Customers, in turn, need to leverage the tools available to prevent and detect feature abuse and transition their environments away from insecure, legacy patterns.
This collaborative approach will help ensure the cloud continues to evolve into a more resilient, secure-by-design system.