Contact
Phone & 24/7 emergency hotline+49 2932 465265-0 Emailinfo@rootsektor.deMon–Fri 8:00 a.m.–5:00 p.m. CET/CEST · outside business hours: 24/7 emergency hotline
Request a pentest quote Report an emergencySecurity Services
Your responsibility in the cloud – independently reviewed.
AWS secures the infrastructure; you secure everything you configure on top of it. In our AWS security review, we check your AWS accounts for overly broad IAM permissions, publicly accessible data, open network access, and gaps in logging – and provide you with a prioritized roadmap for hardening.
Definition
An AWS security review is an independent security assessment of your Amazon Web Services environment: we scrutinize it setting by setting – from your account structure, identities, and permissions to data stores and networks, encryption, logging, and detection. What matters is not each deviation on its own but which settings actually put your data and workloads at risk. Our yardsticks are the CIS AWS Foundations Benchmark, the Security Pillar of the AWS Well-Architected Framework, and the AWS Foundational Security Best Practices.
At the core is the shared responsibility model: AWS is responsible for security “of” the cloud – data centers, hardware, and virtualization. You are responsible for security “in” the cloud: who can access what, which buckets are public, which ports are open, and whether suspicious activity is logged at all.
Risks rarely arise from a single bad decision; they come from speed and growth. Teams create accounts and resources via the console or infrastructure as code, roles are “temporarily” given full access, and access keys remain valid for years. Each deviation is small on its own – together they form attack paths through which a single leaked key can lead to the takeover of entire accounts.
The review creates clarity and evidence: it shows where your environment deviates from proven security baselines and demonstrates to auditors, customers, and insurers that you take the requirements of the GDPR (Art. 32), ISO/IEC 27001:2022, or the EU NIS2 Directive for secure cloud use seriously. On request, we also check whether your data stays in EU regions such as Frankfurt as intended.
Our approach
For the review, you provide a dedicated IAM role with read-only permissions, for example based on the AWS managed policies “SecurityAudit” and “ViewOnlyAccess” – accessed via temporary credentials, so no long-term access keys are needed. If you use AWS Organizations, we include all agreed member accounts and regions.
First, we capture the configuration automatically and compare it with the CIS AWS Foundations Benchmark and AWS recommendations. Our assessment team then evaluates the results manually: it analyzes IAM policies and trust relationships, looks for privilege escalation paths, and checks which resources are actually reachable from the internet.
The result is not a scanner list but an assessed selection: Which findings are critical in your context, which deviations have been accepted deliberately, and which measures deliver the greatest security gain? If you use infrastructure as code, we take that into account in our recommendations – so fixes end up permanently in your Terraform or CloudFormation templates instead of being overwritten by the next deployment.
Common vulnerabilities
Wildcards such as “Action: *” and “Resource: *” in policies, unnecessarily broad roles, and missing permissions boundaries give users and workloads more rights than they need. Even individual permissions such as iam:CreatePolicyVersion or iam:AttachRolePolicy can be enough for privilege escalation all the way to administrator.
IAM users with static access keys that haven’t been rotated in years end up in Git repositories, CI/CD variables, or on developer machines. A single leaked key is all attackers need to get in.
A root user without MFA, with its own access keys, or in daily use is a significant risk. Whoever controls the root user controls the entire account.
Bucket policies with “Principal: *” as well as disabled Block Public Access or publicly shared EBS and RDS snapshots make customer data, backups, and source code publicly accessible.
SSH, RDP, or database ports open to 0.0.0.0/0 expose instances directly to the internet. Without proper VPC segmentation, an attacker can move freely after the first successful access.
If instances still allow the older instance metadata service IMDSv1, a single SSRF vulnerability is enough to steal temporary role credentials. Passwords and API keys in Lambda environment variables, user data, or templates instead of Secrets Manager make the risk worse.
Without an organization-wide CloudTrail across all regions, important traces are missing when an incident occurs. If GuardDuty, AWS Config, or Security Hub run only in individual accounts, blind spots emerge in which suspicious API calls and changes go unnoticed.
Production, development, and logs in the same account, workloads in the management account, missing service control policies, and backups without deletion protection increase the damage from an incident – up to total loss from ransomware.
Possible focus areas
The following focus areas are options to fit your needs, not fixed packages. During scoping, we tailor the scope to your accounts, workloads, and goals.
Compact
The most important security fundamentals of individual AWS accounts – reviewed compactly.
Multi-account
For environments with AWS Organizations, Control Tower, or many workload accounts.
Assumed breach
For elevated protection needs – the review is extended with active tests from an attacker’s perspective.
Process
Predictable and transparent like all our security services – and without interfering with your day-to-day operations.
We clarify accounts, regions, workloads, and goals – such as preparing for an audit, meeting a customer requirement, or hardening after a migration.
Within 24 hours of scoping (on business days), you receive a fixed-price quote for the agreed scope – with no hidden costs.
You provide an audit role with read-only permissions. We give you instructions for setting it up.
Automated data collection across all agreed accounts and regions, followed by manual evaluation, attack path analysis, and comparison with the benchmarks.
A prioritized report with an executive summary, affected resources, and concrete measures – with a joint results meeting on request.
After remediation, we retest the fixed findings free of charge and issue a test certificate.
Reporting
We document each finding with the affected account, region, and resource, a risk rating, and a concrete recommendation. The executive summary puts the results into context for executive and IT management; the technical section gives your cloud team all the details needed for implementation.
Whether it’s a single account or an organically grown organization with many workloads: we review your AWS environment and show you where to start.
FAQ
Didn’t find your question? Call us at +49 2932 465265-0 or email info@rootsektor.de.
Yes. For a number of approved services – including EC2, RDS, Lambda, and API Gateway – customers may carry out security assessments and penetration tests without prior approval. Exceptions include denial-of-service tests, which are subject to separate rules. For a purely read-only configuration review, these rules don’t apply anyway. Because AWS occasionally adjusts the list and the rules, we check active tests against the current version beforehand.
Read-only rights only. As a rule, an IAM role with the AWS managed policies “SecurityAudit” and “ViewOnlyAccess” is sufficient; we use it via temporary credentials. We don’t need write permissions or the root user, and we don’t access the contents of your buckets or databases for the review.
The review examines the configuration of your AWS environment systematically and from the inside. A cloud penetration test, by contrast, actively attacks your applications and services and demonstrates which vulnerabilities are actually exploitable. The two approaches complement each other; we’ll clarify which combination makes sense for you during scoping.
Yes. On request, we include Amazon EKS and ECS, Lambda functions, API Gateway, and the associated IAM roles. For Kubernetes, we also look at cluster access, the mapping of IAM roles to pods, and the reachability of cluster endpoints.
Yes, with our Microsoft 365 & Azure security review. In multi-cloud environments, we coordinate the two reviews so that trust relationships between the platforms – such as federation via Entra ID or shared identities – aren’t overlooked.
The effort depends on the number of accounts, regions, and workloads. Individual accounts can often be assessed in a few days of testing; large organizations need correspondingly more time. We define the exact scope and schedule in the fixed-price quote.
Cloud environments change with every deployment. We recommend a review at least once a year and after major changes such as migrations, new accounts, or product launches. Between reviews, AWS Config, Security Hub, and GuardDuty help you with ongoing monitoring – and we assess their configuration as part of the review, too.
We look at configuration data such as policies, roles, and settings – not business data. We treat results and documents as strictly confidential; you should time-limit the review access and remove it after the review. If you wish, we sign a non-disclosure agreement beforehand.
Tell us how many accounts you have, which regions you use, and what your most important workloads are. We’ll suggest the right scope and prepare a fixed-price quote for you.
Diese Seite gibt es auch auf Deutsch.