
Cloud, Network & Identity Security
Cloud security assessment for AWS, Azure and Google Cloud
A configuration, posture and access review of your AWS, Azure or Google Cloud environment against CIS Benchmarks and provider best practice.
Key areas covered
- Platforms
- AWS, Microsoft Azure, Google Cloud; Kubernetes (EKS, AKS, GKE) on request
- Access needed
- A read-only audit role. We make no changes to your environment.
- Reference standards
- CIS Foundations Benchmarks and provider security best-practice guidance
- You receive
- Prioritised findings report, executive summary and debrief
Overview
About cloud security assessment
Most cloud security incidents are not caused by the cloud provider. They come from how the environment has been set up: storage left public, identities with far more access than they need, management ports open to the internet, logging that was never switched on.
A cloud security assessment reviews your configuration using read-only access and tells you what to fix first. We assess against the CIS Foundations Benchmark for each provider and the provider’s own security guidance. Automated configuration checks are combined with manual review of identity and network design.
A typical starting point
You have moved workloads to AWS, Azure or Google Cloud and are not sure the configuration is as tight as it should be.
What’s covered
What we review in your cloud accounts
Area 01
Identity and access
- Root and global administrator usage, and multi-factor authentication
- IAM roles, policies and service accounts, checked against least privilege
- Long-lived access keys and how they are managed
- Cross-account access and privilege escalation paths
Area 02
Network exposure
- Security groups, network security groups and firewall rules
- Public IP addresses, load balancers and exposed management ports such as SSH and RDP
- Network segmentation and private connectivity to services
Area 03
Data protection
- Publicly accessible storage buckets, blobs and snapshots
- Encryption at rest and in transit, and key management
- Secrets handling and backup exposure
Area 04
Logging and detection
- Audit logging (AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs) and retention
- Alerting on high-risk changes
- Native threat detection services, such as Amazon GuardDuty, Microsoft Defender for Cloud and Security Command Center
Area 05
Compute and containers
- Instance metadata service settings and instance roles
- Container registries and image handling
- Kubernetes RBAC, network policies and pod security settings
Area 06
Governance
- Account, subscription and project structure
- Preventive guardrails such as AWS service control policies and Azure Policy
- Infrastructure-as-code templates such as Terraform, on request
The security problem
Common cloud security risks
Publicly exposed storage and services
Storage buckets, databases or management interfaces left open to the internet.
Over-privileged identities
Users, roles and service accounts with far more access than they need, so one stolen key reaches everything.
Missing logging and monitoring
Without audit logging and alerting, suspicious activity in the cloud goes unnoticed.
Inconsistent environments
Development, test and production accounts configured differently, with weaker controls where attackers start.
Our approach
How a cloud security assessment is carried out
Step 1: Scoping
We agree the accounts, subscriptions or projects in scope, your critical workloads and your priorities.
Step 2: Read-only access
We give you the exact role or policy definition to create. You stay in control and can revoke access at any time.
Step 3: Automated configuration checks
Benchmark checks across every in-scope account, using established open-source assessment tools such as Prowler and ScoutSuite.
Step 4: Manual review
Identity design, network architecture and data flows: the areas automated tools handle poorly.
Step 5: Validation and prioritisation
We remove noise and rank findings by real exposure, so the report leads with what matters.
Step 6: Reporting and debrief
A walkthrough of findings and remediation options with your cloud team.
Step 7: Re-assessment (optional)
We re-check remediated findings and confirm they are resolved.
Standards and references we work to
- CIS Foundations Benchmarks
- Consensus security configuration baselines for AWS, Azure and Google Cloud.
- CIS Kubernetes Benchmark
- Configuration baseline for Kubernetes clusters, where in scope.
- AWS Well-Architected (Security)
- AWS’s own security design principles.
- Microsoft cloud security benchmark
- Microsoft’s security baseline for Azure.
- Google Cloud security best practices
- Google’s security foundations guidance.
Good to know
Configuration assessment or cloud penetration test?
A configuration assessment examines your cloud from the inside with read-only access, and usually finds the most issues for the effort involved. A cloud penetration test attacks your internet-facing cloud resources from the outside, as part of infrastructure penetration testing or application testing. Many organisations start with the assessment and test externally afterwards.
Good to know
The shared responsibility model
Your cloud provider secures the underlying infrastructure. You are responsible for how you configure identities, networks, storage and workloads. An assessment focuses on your side of that line.
What you receive
What you receive from a cloud assessment
Executive summary
Overall posture, the most significant exposures and recommended priorities.
Prioritised findings
Each finding with affected resources, risk rating, benchmark reference, and remediation steps for the console or CLI.
Benchmark results
Pass and fail results against the relevant CIS Foundations Benchmark, useful as audit evidence.
Debrief
A working session with your cloud team on findings and remediation options.
Re-assessment summary
If in scope, confirmation of which findings have been resolved.
Sample finding
Database backups publicly readable in cloud storage
AWS account prod-01, S3 bucket example-db-backups
CIS AWS Foundations Benchmark: S3 Block Public Access
- What we found
- A storage bucket holding nightly database backups allows anonymous read access.
- Evidence
- From an unauthenticated session we listed the bucket and confirmed a backup object was downloadable, without opening it. Bucket policy and access logs attached.
- Business impact
- Anyone who discovers the bucket name could download full copies of the production database.
- Fix
- Enable S3 Block Public Access at account level, remove the public policy, encrypt backups with KMS and alert on any future public access change.
- Status
- OpenFixed, verified at retest
Before we start
What we need to review your cloud environment
- Read-only access. For example: the SecurityAudit and ViewOnlyAccess managed policies in AWS, the Reader and Security Reader roles in Azure, or the Viewer and Security Reviewer roles in Google Cloud.
- A list of accounts, subscriptions or projects in scope.
- A technical contact who knows the architecture.
- Architecture diagrams, if you have them.
Not sure you have everything?
We confirm exactly what cloud security needs from your side during the scoping call, before any work is agreed.
Book a scoping callFAQ
Questions about cloud security
Still have a question?
Ask about scope, timing or cost for cloud security, even if you are not ready to commission work yet.
Contact our teamWill you make any changes to our environment?
No. The assessment uses read-only access. We do not create, change or delete resources, and you can revoke our access at any time.
Do we need to notify AWS, Microsoft or Google?
Not for a configuration assessment, which only reads configuration through standard APIs. If you also want active penetration testing of cloud resources, each provider’s testing policy applies. Most common services can be tested without prior approval, and we confirm this before testing.
How long does an assessment take?
It depends on the number of accounts and how complex the environment is. A small environment can be assessed in a few days. We provide a fixed estimate after scoping.
Can you help us fix what you find?
Yes. Every finding includes remediation steps, and we can advise your team as they work through them and re-check the fixes afterwards.
Do you review Kubernetes and Terraform?
Yes, on request. Kubernetes configuration is reviewed against the CIS Kubernetes Benchmark. Infrastructure-as-code templates can be reviewed to stop misconfigurations from being reintroduced at the next deployment.
Related services
Often combined with cloud security
Talk to us about cloud security
Tell us what has prompted the conversation. We will reply to arrange a short, no-obligation scoping call for cloud security.
