Customization is critical to meet your unique cloud security needs. We cover how you can take advantage of customizable cloud security policies and actions to meet rapidly evolving cloud requirements and business requests.
There’s no one size fits all to cloud security. Security and compliance frameworks are great, but every organization is different and so are its security needs. We’ve often seen customers follow CIS Benchmarks to start their cloud security journey, but as they try to implement, they want to make modifications to it. For example, in AWS CIS 1.4, the recommendation is to rotate keys every 90 days or less, but customers want to change this frequency as per their engineering team’s or CISO’s request.
What’s more, is that security rules and policies are always evolving. Using new insights from public data breaches or even learnings from insider incidents, organizations want to create their own rules. When your Red team comes back with their Pen Test assessment with newly identified holes in your configuration, what do you do for protection? Or when your auditor comes back to you with an important check that’s missing, how do you add that in?
And what about the scripts and automation that you’ve built to fix violations? You’ll want to adapt those as well. The next time you learn about a new way a misconfigured S3 IAM policy can cause privilege escalation, you’ll want to build automation to auto-mitigate that without manual interjection. It’s just not possible to manually fix thousands of misconfigurations that your development teams create. Adapting your tools to changing requirements is critical to stay one step ahead.
Customization is Key in Cloud Security
At CloudHealth Secure State, we understand exactly what customers mean when they say, “I wish I could change this policy to only apply to resources with the “Production” tag, or I wish I could change the SSH accessible source address to my internal IP.” We’ve made a commitment to providing our users flexibility to customize their security practices end-to-end. We allow users to customize rules and even automated guardrails to ensure that throughout the prevention, detection, and response phases, they can meet their security needs.
Custom Security Rules
Let’s walk through an example of a custom rule our internal security team created when they learned about another way of privilege escalation on Amazon S3. Typically, auditors check for the delete permission s3:DeleteObject, or the write permission s3:PutObject, that is deemed risky, but with S3, you can assign permissions via a bucket policy. So they wanted to create a custom rule to check for IAM permission s3:PutBucketPolicy, s3:PutLifecycleConfiguration, and s3:PutBucketAcl that allows users to escalate their IAM permissions, providing users the ability to assign new permissions.
Using our rich Gremlin query interface, they wrote a custom rule with the following query:
The custom rule creates security findings when an InlinePolicy or ManagedPolicy has a PolicyStatement with a bucket delete permissions or assign permissions access. They did this through the create rule API using a simple Python script.
Custom Auto Remediation Actions
Similarly, we’ve seen customers create their own auto remediation actions. For instance, a customer wanted to create a custom remediation action to restrict access of the EC2 SSH port (TCP 22) from any source address to an internal IP range. The Secure State native remediation job “ec2_close_port_22” revokes the security group ingress for any source address, but rather than revoke SSH access entirely, the customer wanted to change it to an internal IP.
Here’s a snippet from the Python job code that revokes the open ingress:
Since all our remediation jobs are open source on GitHub, they referred to our examples and simply modified the “ec2_close_port_22” job to remove ingress from any source address but provide ingress access for the 10.10.10.0/24 internal IP.
Here’s the code snippet that they added to the Python job:
They created the custom remediation job by following our job authoring guidelines, protecting open SSH ports with a custom guardrail that fit their requirements.
The ability to customize your tools is critical to meet your unique cloud security needs. Customization lets you build trust with internal teams by making modifications to policies per their requests. It also empowers you to adapt and respond to new threats, and meet rapidly evolving cloud requirements. So when your CISO asks you whether your organization is protected against the cause of the latest public data breach in the headlines, you can confidently say “yes”!
Learn more about how you can take advantage of customizable cloud security policies and actions in in our technical report: Mitigating Security and Compliance Risks with CloudHealth Secure State
