Which accounts, regions, and workloads are in scope?
A useful boundary identifies the relevant organization structure, shared services, application accounts, environments, and any explicit exclusions.
AWS cloud security
AWS cloud security assessments.
Cydem combines AWS configuration review, IAM privilege analysis, exposure assessment, and authorized attack simulation to identify the paths that create meaningful cloud risk.
Request a quoteAssessment focus
- Organization and environment
- IAM and privilege
- Network and exposure
- Data security
Configuration review with architectural context.
Automated posture tools are useful for known patterns. Manual analysis is required to reason about IAM escalation, cross-account trust, workload identities, architecture, service relationships, and how several individually modest weaknesses combine.
Cloud risk is defined by relationships: which principal can assume which role, what a workload can reach, where data is exposed, and whether monitoring covers the path. A manual assessment adds that context to configuration review.
Scoping questions
Questions to resolve before testing.
Clear answers help define the right accounts, identities, workflows, technical boundaries, and safety constraints for the quote and test plan.
How do people and workloads receive AWS permissions?
Federation, IAM Identity Center, roles, resource policies, workload identities, and cross-account trust all shape the paths that require analysis.
Which data and operations require the strongest controls?
Critical resources, administrative actions, production data, secrets, and deployment paths help prioritize manual review and authorized validation.
Which actions are prohibited in the live environment?
The rules of engagement should identify destructive operations, availability constraints, monitoring expectations, escalation contacts, and service-specific AWS restrictions.
What this service provides
Each assessment is designed to give technical teams clearer risk, usable evidence, and a defined path from finding to fix.
Visibility into IAM risk
The assessment explains excessive permissions, trust relationships, and realistic privilege escalation paths.
Context for cloud findings
Configuration issues are evaluated alongside workload identities, public exposure, data access, and architecture.
Prioritized cloud remediation
Cloud and security teams receive practical actions ordered by likely impact and the relationships between affected resources.
Assessment coverage
Testing areas are confirmed during scoping.
The areas below describe available coverage. The final test plan reflects the architecture, roles, objectives, and written authorization for the engagement.
Organization and environment
Understand the account structure, workloads, regions, and control architecture in scope.
- AWS Organizations
- Accounts and regions
- Organizational units
- SCPs
- Workloads
- Identity architecture
- Network architecture
- Logging architecture
IAM and privilege
Analyze principals, policies, trust, and the actions that could create or extend authority.
- Users and roles
- Policies and trust policies
- Resource policies
- Cross-account access
- Permission boundaries
- Identity Center
- Federation
- Wildcard permissions
- Long-lived credentials
- Role chaining
- Privilege escalation
Network and exposure
Trace reachable services and the controls that separate public, private, and management paths.
- VPC and subnets
- Routing
- Security Groups
- NACLs
- Load balancers
- Public endpoints
- Management interfaces
- Transit relationships
- VPN security where in scope
Data security
Review access, resource policies, cross-account relationships, public exposure, and protection settings.
- S3
- RDS
- EBS
- KMS
- Secrets Manager
- Resource policies
- Public exposure
- Encryption
- Cross-account access
Compute and workloads
Assess the security boundaries around deployed applications and runtime identities where applicable.
- EC2
- Lambda
- ECS
- EKS
- API Gateway
- CloudFront
- Workload roles
- Application-to-cloud access
Detection and attack paths
Identify coverage gaps and validate authorized paths without destructive exploitation.
- CloudTrail
- GuardDuty
- Security Hub
- AWS Config
- Logging coverage
- Detection gaps
- Role assumption
- Cross-account movement
- Data-access paths
- Service-trust abuse
Engagement timeline
Engagement process and timing.
The sequence is tailored to the accounts, identities, workloads, regions, access model, and operational constraints included in the assessment.
Before engagement
Scope and quote
Confirm the accounts, regions, services, identities, workloads, objectives, exclusions, and expected deliverables. The quote records the agreed scope and commercial terms.
Before testing
Preparation
Confirm written authorization, rules of engagement, points of contact, the agreed access approach, production constraints, and applicable AWS testing restrictions.
Agreed testing window
Testing
Review the in-scope environment and assess IAM, trust relationships, public exposure, workload controls, data access, logging, and authorized attack paths.
After testing
Analysis and report
Validate the evidence, connect related weaknesses, assess likely impact, and document prioritized findings, privilege paths, and practical remediation guidance.
After testing
Debrief
Walk cloud engineering and security stakeholders through significant findings, identity relationships, affected resources, and remediation questions.
After remediation
Included retesting
Recheck high and critical configuration or permission findings after changes are available. Additional retesting is available at no additional charge when requested by the client.
Exact dates, testing duration, and deliverables are confirmed in the quote. Additional retesting of high and critical findings is included at no additional charge when requested. The sequence may be adapted to the agreed scope and production constraints.
Illustrative attack path
Workload role privilege escalation.
A compromised application can use its workload role, assume a more privileged identity through permissive trust, and reach a sensitive AWS resource.
Public workload
EC2 / Lambda role
sts:AssumeRole
Sensitive AWS resource
Boundary to validate: Workload identity and role trust combine into privilege escalation
Methodology baseline
AWS guidance and benchmarks used as a baseline.
Methodology can draw on the AWS Well-Architected Security Pillar, IAM security best practices, service documentation, and relevant benchmarks. Testing is limited to the client’s authorized configuration, workloads, identities, applications, permissions, and architecture. Cydem does not test AWS infrastructure itself.
- AWS Well-Architected Framework Security Pillar
- AWS IAM security best practices
- AWS service security documentation
- Relevant industry benchmarks
Examples of issues assessed
- IAM privilege escalation
- Excessive permissions
- External trust
- Cross-account movement
- Confused deputy paths
- Public workload exposure
- Sensitive resource access
- Weak resource policies
- Long-lived credentials
- Detection gaps
- Insecure workload roles
- Application-to-cloud attack paths
Deliverables
What the engagement provides.
Deliverables are adapted to the agreed scope and give stakeholders evidence, context, and remediation guidance.
AWS security assessment report
Findings across IAM, network, compute, data, detection, and configuration.
IAM privilege analysis
Dangerous permissions, escalation opportunities, role relationships, and external trust.
Attack-path narratives
Clear explanations of how credentials, roles, workloads, and resources interact.
Architecture observations
Practical improvements grounded in the environment and operating model.
Prioritized remediation matrix
A delivery-oriented view of what to fix first and why.
Included retesting
Additional validation of high and critical findings is available at no additional charge when requested.
Questions
Assessment FAQ
Access, timing, production constraints, and deliverables are confirmed during scoping.
Access depends on the objectives. Configuration and architecture review can often use a constrained read-only role plus documentation and interviews. Authorized attack simulation may require dedicated test identities or additional scoped permissions agreed in advance.
Not by default. Access should be proportionate to the assessment. Administrator access is not treated as a generic prerequisite, and any higher-risk permission is discussed explicitly during scoping.
Yes. Multi-account assessments can review organization structure, SCPs, Identity Center, cross-account roles, resource policies, centralized logging, and trust paths within the agreed scope.
Yes. IAM is a major focus, including users, roles, policies, trust, permission boundaries, federation, external access, role chaining, and combinations of permissions that may enable escalation.
Automated posture tools are useful for known configuration patterns and ongoing visibility. A manual assessment adds context around IAM escalation, trust relationships, architecture, workload identities, attack paths, and how individual conditions can be combined.
Any production interaction is governed by the agreed rules of engagement. Testing uses minimally destructive validation, respects AWS testing requirements and service restrictions, and excludes destructive activity unless it is explicitly authorized.
Yes. Additional retesting of high and critical findings is included at no additional charge when requested. The relevant configuration or permission changes are rechecked after remediation is ready.