Many companies today use multiple clouds as part of their production environment, which can lead to increased complexity and risk. You can leverage CloudHealth Secure State’s remediation capabilities to reduce cloud security risk and improve your multicloud security posture.
It wasn’t so long ago when public cloud usage was limited. Most organizations were dipping their toes into the public cloud, but only with certain cloud providers and only for certain use cases. Companies limited their exposure and risk by limiting what was deployed into the public cloud.
Fast forward to today and you see that many companies use multiple clouds as part of their production environment, which, with all its benefits, can lead to increased complexity and risk. With this in mind, we’re going to discuss CloudHealth Secure State’s Azure remediation capabilities—to go along with our existing AWS remediation capabilities—and how you can leverage these solutions to improve your multicloud security posture.
Identifying and addressing cloud security risks
What typically happens when a customer turns on CloudHealth Secure State (CHSS) for the first time? They get a ton of findings (which is to be expected).
Most customers who’ve been in the public cloud for a while have learned over time how to more securely deploy their workloads. But what about the legacy stuff—those workloads that were spun up a year ago? When they start to investigate with CHSS, they see all the skeletons that were hiding before, now in the light of day. Not fun. Even customers relatively new to the public cloud are prone to make mistakes and introduce security risks to their environment.
So, what do you do? Some companies ignore most of the findings and focus on a few high-risk things that can limit their exposure. Others improve the go-forward controls to limit introducing new risks and misconfigurations. Surprisingly, the majority of companies try to tackle the beast in a systemic approach, and that means remediation and auto-remediation.
Remediation updates: Azure support and open-source community
When CloudHealth Secure State first released remediation capabilities, it only supported AWS and didn’t allow customers to customize the remediation job (code run by the worker). You can get more details about the architecture and deployment model of the CHSS remediation service in a great blog found here.
Fast forward a few months and now, CHSS not only supports both AWS and Azure, but also open-sourced the remediation jobs so customers can customize, create, and share their remediation jobs (these remediation jobs can be found at this GitHub repo location).
Let’s take a closer look at some of the new features and capabilities of CloudHealth Secure State’s remediation services.
Support for Azure remediation
CHSS now supports Azure remediation in the same way it supports AWS. Customers will first need to deploy a worker (docker image). (You can use one worker to cover both AWS and Azure, but we recommend splitting them out with one for each cloud provider).
In the above image, you can see I set up a new Azure worker and associated it with my Azure subscriptions that I want the worker to perform within. Within Azure, I then created a new account and created a key for the worker to authenticate to my Azure subscriptions. Now with the worker set up, you can start using either existing remediation jobs or create new ones to fix your findings.
Remediation and auto-remediation
Once remediation is enabled and tested, I recommend thinking about when to use auto-remediation and when not to. Auto-remediation or guardrails are a great way to reduce the number of new findings that are introduced into the environment.
When starting out and just gaining confidence in automation, you may want to manually select findings to be fixed at first. But once that’s achieved, most customers enable auto-remediation for findings that won’t break production or for rules that will never be allowed. Some examples of these are SSH or RDP open to the Public or the encryption of S3 buckets. Some customers even enable auto-remediation to disable public read access to an Azure blob. Each cloud has its own default configurations that may require CloudHealth Secure State auto-remediation to improve cloud security.
As you progress in your cloud remediation journey, don’t forget to share and help us build a community around remediation jobs. We encourage you to go to this GitHub link and start coding. We look forward to seeing what you come up with!
And to learn more about how to set up a successful cloud security practice, see our guide, which explains the key to auto-remediation for cloud security and key KPIs to track your progress along the way.
