Cloud Security

Secure your digital backbone.

In the cloud, the question that matters is rarely whether there is an exploit. It is what one identity can reach. We find the permissions nobody needed, the storage nobody meant to share and the changes nobody reviewed, across AWS, Azure and GCP, and deliver the fixes as code.

  • AWS, Azure and GCP

    Each assessed against its own CIS Foundations benchmark.

  • Read-only access

    Configuration review runs through a read-only role, not admin keys.

  • Fixes as code

    Findings come with Terraform and CloudFormation snippets.

  • Tools, then people

    Scanners for breadth, manual review for the identity paths they miss.

Shared responsibility

Your provider secures the cloud. You secure what you put in it.

Every cloud provider draws a line. Below it, the infrastructure is theirs to protect. Above it, your data, your identities and your configuration are yours, whichever service you use.

Most cloud incidents happen on your side of that line, which is exactly where our work sits.

YouSharedProvider
Shared responsibility model by service type
LayerIaaSPaaSSaaS
Data and contentYouYouYou
Accounts and identitiesYouYouYou
Identity and directoryYouSharedShared
ApplicationsYouSharedProvider
Network controlsYouSharedProvider
Operating systemYouProviderProvider
Physical hosts and datacentreProviderProviderProvider

The common shape of the model. Exact boundaries vary by provider and by service.

What we look at

Six domains, and the question behind each

The same six domains the App Defense Alliance Cloud profile groups its checks into. A benchmark tells you whether a setting is right; these are the questions that tell you whether you are safe.

Identity and access

“Which identities can reach what, and which of those permissions are ever used?”

Storage

“Is anything readable without authentication, including snapshots and backups?”

Networking

“Which management ports and services can the internet reach?”

Logging and monitoring

“If someone got in, would you be able to tell afterwards what they did?”

Compute

“Are instances and containers hardened, patched and running with minimal roles?”

Database services

“Are databases private and encrypted, and backed up where you think they are?”

Mapped to the benchmark for each provider

Amazon Web Services

CIS AWS Foundations Benchmark

Microsoft Azure

CIS Microsoft Azure Foundations Benchmark

Google Cloud

CIS Google Cloud Platform Foundation Benchmark

The domains are explained in full in our guide to the ADA Cloud App and Config profile.

Configuration drift

An assessment describes the day it was run

Cloud configuration changes every time someone deploys. An illustrative view of the same environment, watched two ways, after the same assessment.

Our approach

Assess, design, implement

We don't just secure infrastructure; we build resilience. Every service below belongs to one of three phases, so you can start wherever you are.

Questions

Frequently asked questions

Do you need write access to our cloud accounts?
No. A configuration assessment runs through read-only access: a read-only IAM role on AWS or the Reader role on Azure, for example. Penetration testing is scoped separately, and any access it needs is agreed in writing before testing starts.
What is the difference between a cloud security assessment and cloud penetration testing?
An assessment reviews how your accounts are configured, against the CIS benchmark for your provider and against how identities can actually move between resources. A penetration test actively attacks what is exposed, to show what an attacker could achieve from outside or from a compromised foothold. Many organisations start with the assessment.
Which clouds do you cover?
Amazon Web Services, Microsoft Azure and Google Cloud, and combinations of them. Multi-cloud estates are assessed per provider, because each has its own identity model and its own benchmark, and then reviewed together for the trust relationships between them.
Isn’t the cloud provider responsible for security?
For part of it. Under the shared responsibility model the provider secures the underlying infrastructure, while your data, identities and access are always yours to secure, along with more of the stack the lower the service level you use. Most cloud incidents sit on the customer’s side of that line, which is where an assessment looks.
Do you just run a scanner against the CIS benchmark?
We start with one, because tools such as Prowler, ScoutSuite and Steampipe check a benchmark quickly and thoroughly. Then a consultant reviews what benchmarks are not built to find: over-broad roles that are technically compliant, cross-account trust, and paths where a low-privilege identity can reach something it should not.
Can you fix what you find?
Findings come with remediation guidance, including Terraform and CloudFormation snippets so the fix can go into your infrastructure code rather than being clicked into a console and lost. If you want hands-on help, the implementation phase covers IaC security, DevSecOps integration and posture management.
What is CSPM and do we need it?
Cloud security posture management continuously checks your accounts against a baseline and flags changes that break it. You need something like it if your environment changes often, because a point-in-time assessment describes the day it was run, and cloud configuration drifts every time someone deploys.
How often should we have a cloud assessment?
At least annually, and after significant changes such as a migration, a new account structure or a major new service. Between assessments, continuous posture management is what catches drift.

Ready to secure your cloud?

Partner with Adayptus to build a secure, resilient, and compliant infrastructure. Tell us which providers and how many accounts, and we will come back with a scope.