The Challenge
Cloud environments grow fast and informally. An engineer opens port 22 to debug something and forgets to close it. A developer creates an IAM user with admin access for a quick integration and it stays active for two years with active credentials and no MFA. An S3 bucket gets made public for a customer demo and nobody changes it back. These aren't hypotheticals — they're findings we see in nearly every audit engagement we conduct.
The challenge is that cloud environments are dynamic and large enough that manual review doesn't scale. A mid-sized startup on AWS might have 50+ IAM roles, 200+ security group rules, dozens of S3 buckets with varying access policies, and resources spread across multiple regions — only one of which has CloudTrail enabled. Human review of all of that is impractical; you need automated tooling combined with expert analysis to find what actually matters.
The audit also surfaces the compliance gap — the distance between your current configuration and what SOC2, ISO 27001, or PCI-DSS requires. That gap is usually larger than teams expect, and understanding it with a clear remediation roadmap is far less painful than discovering it when an auditor delivers their findings report.
Signs You Need This
- Your AWS account has resources created by multiple engineers over years with no consistent security review
- You're pursuing SOC2, ISO 27001, or PCI-DSS certification and need a gap assessment before engaging an auditor
- You've had a security incident or near-miss and want to understand your full exposure
- A customer or investor is asking for a security assessment report as part of due diligence
- Your engineering team has grown and you've lost visibility into what resources exist and why
- You don't have a clear answer to "what would an attacker find if they compromised a developer credential?"
How We Approach It
Automated Scanning with Prowler & ScoutSuite
We run Prowler against your AWS account — over 300 checks covering CIS Benchmark, SOC2, PCI-DSS, ISO 27001, and GDPR controls. Prowler produces a structured JSON output we parse and categorize by severity and control framework. For multi-cloud environments we layer in ScoutSuite, which provides a visual network topology map alongside its findings. The raw output gives us a comprehensive baseline before we start manual analysis — automated tools find breadth, manual review finds depth.
# Run Prowler with CIS and SOC2 compliance frameworks
prowler aws \
--compliance cis_level2_aws_account_security_onboarding \
--compliance soc2 \
--output-formats json html csv \
--output-directory ./prowler-results \
--log-level WARNING \
--profile security-audit-readonly \
--regions us-east-1 us-west-2 eu-west-1
# Prowler creates an IAM role — attach these policies for read-only access:
# - arn:aws:iam::aws:policy/SecurityAudit
# - arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
# Parse HIGH/CRITICAL findings from JSON output for triage:
jq '[.[] | select(.severity == "high" or .severity == "critical")]
| sort_by(.service_name)
| .[] | {check: .check_id, resource: .resource_arn, status: .status}' \
prowler-results/prowler-output.jsonIAM Deep Dive
IAM is where most cloud breaches start — either through credential theft or through privilege escalation exploiting overly permissive policies. We review every IAM user, role, and policy: unused credentials older than 90 days, roles with wildcard actions (Action: "*") on sensitive services, inline policies that bypass permission boundary controls, and cross-account trust relationships. We use IAM Access Analyzer to surface resources publicly accessible or accessible from other accounts, and Steampipe for custom queries against the IAM graph to find privilege escalation paths.
A common privilege escalation path we find: a developer IAM user has iam:AttachRolePolicy permission — enough to grant themselves admin without any other permissions:
# Step 1: Attacker (developer IAM user) lists their own permissions
aws iam list-attached-user-policies --user-name john.dev
# Returns: DeveloperPolicy (allows iam:AttachRolePolicy)
# Step 2: Attacker attaches AdministratorAccess to a role they can assume
aws iam attach-role-policy \
--role-name dev-deployment-role \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
# Step 3: Attacker assumes the newly admin role
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/dev-deployment-role \
--role-session-name escalation-session
# Step 4: Now operating as full admin — can access all services, read all secrets
aws secretsmanager list-secrets # dumps all secrets
aws s3 ls # full S3 access
# Fix: Remove iam:AttachRolePolicy from developer policies,
# use IAM permission boundaries to limit maximum effective permissions.Network Topology & Exposure Review
We map your VPC architecture — subnets, routing tables, security group rules, NACLs, and internet-facing resources. We identify services publicly accessible when they shouldn't be (RDS with public subnet placement, EC2 instances with inbound 0.0.0.0/0 on non-standard ports, ElasticSearch clusters without VPC placement), security groups widened for debugging and never tightened, and VPC peering configurations that allow lateral movement between environments that should be isolated.
Data Security Review
We audit encryption posture for data at rest — S3 SSE with KMS vs. SSE-S3 vs. unencrypted, RDS storage encryption status, EBS volume encryption, and whether secrets live in AWS Secrets Manager or plaintext environment variables in ECS task definitions or Lambda. We also review data in transit: TLS versions enforced by load balancers and CloudFront, cipher suite configuration, and certificate management. Public S3 buckets and misconfigured bucket policies get flagged immediately as critical findings.
Compliance Gap Analysis
We map every finding to your target framework — SOC2 Trust Services Criteria, ISO 27001 Annex A controls, or PCI-DSS requirements. Each gap gets a control reference, a CVSS-informed severity rating, an estimated remediation effort (hours), and a specific remediation recommendation. The output is a clear, prioritized roadmap — not a raw list of findings. We separate quick wins (misconfigurations that can be fixed in an hour) from longer remediation projects (restructuring IAM) so you can make informed prioritization decisions.
Steampipe — Custom IAM Graph Queries
Steampipe lets us run SQL queries directly against the AWS API — exposing privilege escalation paths, stale credentials, and over-permissive roles that Prowler's preset checks don't surface:
-- Find IAM users with access keys unused for 90+ days (stale credentials)
SELECT
u.name,
k.access_key_id,
k.status,
k.access_key_last_used_date,
DATE_PART('day', NOW() - k.access_key_last_used_date) AS days_since_used
FROM aws_iam_user u
JOIN aws_iam_access_key k ON u.name = k.user_name
WHERE k.status = 'Active'
AND (k.access_key_last_used_date IS NULL
OR DATE_PART('day', NOW() - k.access_key_last_used_date) > 90)
ORDER BY days_since_used DESC;
-- Find roles with wildcard Action on sensitive services
SELECT
r.name AS role_name,
s.statement ->> 'Effect' AS effect,
s.statement -> 'Action' AS actions
FROM aws_iam_role r,
JSONB_ARRAY_ELEMENTS(r.inline_policies::jsonb) AS p,
JSONB_ARRAY_ELEMENTS(p -> 'Statement') AS s
WHERE s.statement ->> 'Effect' = 'Allow'
AND s.statement -> 'Action' ? '*';
-- Find S3 buckets with no server-side encryption
SELECT name, region, server_side_encryption_configuration
FROM aws_s3_bucket
WHERE server_side_encryption_configuration IS NULL;Tools We Use
We combine automated scanning breadth with manual expert analysis — tools catch what's known, manual review catches what's unusual or business-logic-specific.
Common Mistakes We Prevent
- Running only automated tools and treating the output as the final audit — scanners miss business-context-specific risks like overly broad cross-account trust or unusual IAM role chaining
- Prioritizing findings by CVSS score alone without considering business impact — a publicly accessible S3 bucket with only internal CSS files is lower priority than an IAM user with admin access who hasn't logged in for 18 months
- Generating a findings list without a remediation roadmap — a 200-item list with no prioritization or effort estimate is not actionable
- Reviewing only the primary region and missing CloudTrail disabled in secondary regions where resources are running
What we consistently find: Unused IAM users with active access keys, S3 buckets with legacy ACLs granting public read, CloudTrail disabled in at least one region, and security groups widened for debugging that were never tightened. These four finding categories appear in over 80% of AWS accounts we audit.
What You Get
- Full Prowler scan output with findings categorized by severity and compliance framework
- IAM analysis report covering every user, role, and policy with specific remediation steps
- Network exposure map identifying all internet-facing resources and associated risks
- Data security assessment covering encryption at rest and in transit across all services
- Compliance gap analysis mapped to SOC2 / ISO 27001 / PCI-DSS with control references
- Prioritized remediation roadmap with quick wins separated from longer projects
- Executive summary for leadership and technical annex for your engineering team
Timeline & What to Expect
After the review call, we remain available for 30 days to answer questions on specific findings as your team works through remediation. For critical findings (publicly accessible databases, admin credentials with no MFA), we'll flag them the moment we find them — not wait for the final report.
Frequently Asked Questions
Do you need production access?
We need read-only access to your AWS account — we use a Prowler IAM role with SecurityAudit and ViewOnlyAccess managed policies. We never need write access for the audit phase. If you want us to implement remediations afterward, we scope that separately and use a tightly controlled role for each specific change. All access is logged in CloudTrail and revoked immediately after the engagement.
How disruptive is the audit?
Not at all — the audit is entirely read-only. Prowler and ScoutSuite make API calls to enumerate resources; they don't modify anything. The only potential disruption is API rate limiting if your account has aggressive Service Control Policies, which we account for by running scans during off-peak hours. Your team doesn't need to do anything differently during the audit period.
What if you find critical vulnerabilities?
We notify you immediately — we don't hold critical findings until the final report. If we find a publicly accessible database, a publicly readable S3 bucket with sensitive data, or IAM credentials with no MFA and admin access, you'll get a same-day notification with specific remediation steps. The goal is to reduce your risk as fast as possible, not to deliver a comprehensive report weeks after a critical issue was discovered.
When This Is the Right Fit
This engagement is right for any team that has been running on AWS for more than 6 months and hasn't had a systematic security review, for teams preparing for a compliance audit or enterprise security questionnaire, or for teams who've had a security incident and need to understand their full exposure. It's also valuable as an annual security health check even when everything appears to be fine — the threat landscape changes and so does your infrastructure.
This is not a penetration test — we audit cloud configuration and access control, not application vulnerabilities. If you need application-layer testing (SQL injection, business logic flaws, API security), that's a separate engagement. The two complement each other: the cloud audit addresses infrastructure exposure, the pentest addresses application exposure.