Over the last few years, public cloud providers have been increasing their capabilities in order to answer customers’ most pressing cloud security questions, but even with how far they’ve come, they can’t meet every customer’s needs. This article focuses on a few key areas where public cloud providers’ native security tools are less helpful and more difficult to operationalize than CloudHealth Secure State.
When most customers start their public cloud migration, they start with a small test and play environment. Very soon after, they’re moving production and business-critical applications to the cloud. Developers are feeling great with their enhanced capabilities and how quickly they can now deploy the latest versions of their software. This is usually the time that the security and compliance teams step in and ask, “How are we protecting and securing our public cloud?”
At this point, most customers turn to the cloud provider to see what cloud security capabilities are available natively. The tools they find are like those found inside a toolbox—they’re all good by themselves, but the user must figure out how to make them all work together to get the job done.
Cloud service providers’ native security tools also lend themselves to other concerns. For example:
- How do I manage alerts so we aren’t overwhelmed?
- How quickly will I see misconfigurations?
- How do we handle exceptions?
- How do we see all the findings from our different accounts?
- What about multi-cloud?
These questions are common and important. Over the last few years, public cloud providers have been increasing their capabilities in order to answer these questions, but even with how far they’ve come, they can’t meet every customer’s needs.
This article will only point out a few of the areas where cloud providers’ native security tools are less helpful and more difficult to operationalize than CloudHealth Secure State. I would be performing a disservice if I didn’t point you to a few previously written articles that highlight how CloudHealth Secure State provides better visibility, context, and prioritization capabilities for managing cloud security risk. You can see those articles here:
- Avoid These Common Misconfigurations That Can Lead to Cloud Security Data Breaches in AWS
- 5 Ways to Improve Your Cloud Security Posture
- CloudHealth Secure State: New Capabilities to Combat Cloud Security Risks
Public cloud providers’ native security tools compared to CloudHealth Secure State
For our discussion, we’ll focus on a few topics that highlight the differences between public cloud providers’ native security tools and CloudHealth Secure State (CHSS).
Alerts
When companies enable either the native or third-party tool to monitor their public cloud infrastructure, the first question they must answer is, “Who is going to get the alerts?” The answer to this can be very complicated. Is it the security operations center? Cloud operations? Developers?
The answer? It could be all of the above. You need to have flexibility in not only who gets the alerts, but also how they receive them. We’ve seen organizations that have different alert preferences for different teams. One might want the alert in Slack while another might want an email.
With cloud providers’ native security tools, the ability to create and customize alerts is not available out-of-the-box. You can build your own custom-created alerts and integrations, but in general, the alerting systems are very limited out-of-the-box.
In CHSS, alerts are easy to set up and customize. Customers can pick from a variety of filters to send the right alerts to the right group with their preferred platform. Below you can see an example of an alert created based on the CIS AWS Benchmark and High Severity. Even though this might seem like a simple scenario, customers struggle to operationalize their cloud security and compliance programs without this.
Speed of detection
As we all know, the speed at which things can be deployed (and destroyed) in public clouds is much faster than in your data center. There are companies that spin up and down thousands of workloads multiple times a day. This has enabled developers to move faster and roll out new features and apps like never before, but it’s also created a problem for security and compliance teams. How do you keep up with the speed of the cloud?
Cloud providers’ native security tools have improved their speed of detection in recent years, but depending on the asset, detection might only be once a day or four times daily. For a lot of organizations, this is not enough.
Customers need to identify misconfigurations as soon as possible so they can mitigate security risks and educate end users. Waiting a few hours or days can cause awkward conversations such as:
SecOps: “Jenny, you deployed an EC2 instance with an open SSH port and public IP”
Jenny: “ I did? Do you have the ID so I can look it up?”
SecOps: “Sure, i-1234523xxx”
Jenny: “Hmm… I don’t see that instance. You know I spin up and down instances all day. I must have terminated it already. Thanks anyway.”
When it comes to cloud security, speed is critical. CHSS provides alerts in near real-time, which leads to two important benefits:
- You can send alerts to the end user or SOC as resources are being added. This allows for immediate correction and conversation between security and development, leading to a more secure future deployment.
- The speed of detection allows customers to integrate the CHSS solution into their CI/CD pipeline, reducing the amount of misconfigurations that make it into production.
Exception handling
For every rule there are exceptions. When security and compliance teams roll out the controls they want enforced within the public cloud, exceptions are the first thing that comes up. For example, do we need the same controls in our Dev accounts as our Prod accounts? What if we can’t fix the finding for a few months due to the application limitations?
Granting exceptions and being able to track them over time are both critical capabilities for cloud security and compliance teams. And as a best practice, any exception should be reviewed every few months to validate its worth, which is also a requirement of most standard compliance regulations.
Most public cloud providers’ security and compliance monitoring functions don’t offer any exemption capabilities as this time. The ones that do are limited—you have to select the objects you want to exempt and provide a date when the exemption would expire. This doesn’t scale. Imagine having multiple accounts in multiple clouds and trying to track all the exceptions!
With CHSS, we allow our customers to not only exempt objects or rules, but we also allow you to exempt certain rules in specific accounts. This enables customers to enforce rules in production and not in their test/dev environments. We’re also building on this—soon, you can also set regions and tags as parameters to auto-exempt objects from rules.
More than one cloud provider
It’s no surprise that the largest hurdle public cloud providers have when competing with third-party tools is that they don’t typically support other cloud providers. Most customers we work with are in at least two clouds, with some being in more than four. What’s also true is that most customers have multiple accounts with one provider, which makes security and compliance almost as complicated as having more than one cloud provider.
Leveraging a tool such as CHSS allows customers to consolidate their information so they have one place to manage their cloud security posture across multiple accounts and cloud providers.
This improves not only cloud security, but also operations—there’s no need to dig into each cloud environment and search for a finding that might need to be exempt. Multiple users from different organizations or lines of business can have access to the solution, and you can implement customized permissions, so users are limited to only the resources they’re responsible for.
To wrap up
Although I only touched on a few areas that differentiate CHSS from public cloud providers’ native security tools (alerts, speed of detection, exception handling, multiple clouds), there are many other distinguishing features that CHSS brings to the table. When evaluating which direction to go, people forget to think about how to operationalize the solution. Public cloud providers have some security and compliance capabilities, but they’re not easily operationalized and have their limitations.
In order to have a successful cloud security and compliance program that can grow with a company’s cloud growth and still be easily operationalized, you need to look outside what cloud providers can offer. This is where CloudHealth Secure State can help. Reach out and let us show you how.
