Avoiding cloudbursts
Cloud environments give you speed and flexibility — but they also create a lot of room for misconfiguration. An S3 bucket left publicly readable, an IAM policy that’s too permissive, a metadata endpoint that shouldn’t be reachable from the application layer. These are the kinds of issues that don’t show up until someone exploits them.
During a cloud security audit I review your cloud infrastructure against security best-practices. The review covers:
- User Management, Authentication, Authorization, Access Policies
- Component Isolation, Security Groups, VPN Settings, Ingress/Egress Routing
- Object Storage Visibility (like S3)
- Security of Serverless Functions (like Lambdas)
- Hardening of Metadata WebServices (which can be abused by SSRF vulnerabilities)
- Encryption of Data-in-Transit & Data-at-Rest
- Key Management & Secret Management (use of vaults)
- Logging & Monitoring
- DFIR-Readiness (Digital Forensics & Incident Response)
I combine the latest CIS benchmark tests with my pentesting experience in cloud-based environments. So the findings are weighted by how exploitable they actually are in your specific setup, not just whether they pass or fail a generic compliance check.
Review of container orchestration platforms
Most cloud environments I review also run container orchestration platforms like Kubernetes (K8s) or OpenShift. These add their own layer of security concerns — RBAC policies, pod isolation, control plane hardening — that go beyond what a cloud-level review covers. If your infrastructure includes container platforms, I offer a dedicated Container Platform Review that can be combined with this cloud security check for full coverage.
Detailed reporting
The resulting report of the found security issues includes detailed descriptions of the findings (along with all evidence collected) and mitigation advice to remediate each issue and tips to further harden your application. To better distribute the individual findings towards the relevant parties, I categorize all findings by function (business, architecture, development, operations) to which the finding applies.
After sending the report, an on-site or remote debriefing meeting will be arranged to further discuss the report and any potential questions along with the team members assigned to remediate the findings.
This process can optionally be followed by a second check of remediated findings, which leads to an updated report.
Prerequisites
This kind of security check requires access on high-privileged level to the cloud environment in order to review its security.
It is helpful to get some information upfront about your architecture and desired cloud setup in order to let the review be as targeted as possible. This also includes some high-level information about your architecture, as what components are used and what kind of data (in terms of sensitivity) is handled on which component.
This information is usually provided and discussed in a kick-off workshop (remote or on-site) at latest a few days before the review begins.