Security model
Security is a property of the delivery system, not a review that happens before launch. This page describes the model; the standards that follow describe each part of it.
Shared responsibility
| Layer | AWS | Customer |
|---|---|---|
| Physical | Data centres, hardware, network fabric | — |
| Hypervisor and managed-service platform | Patching, isolation, availability | — |
| Network configuration | VPC primitives, security group and NACL enforcement | VPC design, subnet segmentation, routes, flow logs |
| Identity | IAM service availability | Users, roles, policies, MFA, federation |
| Data | Storage durability and encryption primitives | Classification, encryption choices, key policy, access |
| Application | Runtime and framework (for managed runtimes) | Code, dependencies, input validation, secrets |
| Configuration | Service defaults are secure-by-default | Every deviation from the default |
The boundary moves with the service. On EC2 the customer patches the OS; on Lambda and Fargate, AWS does. The delivery standard has to state which side of the line each control sits on, or controls fall into the gap between them.
Security domains
| Domain | What it covers | Standard |
|---|---|---|
| Governance | Roles, responsibilities, policy, risk acceptance | This page, Policy as code |
| Identity and access | Who can do what, with what credential, for how long | Identity and SSO |
| Infrastructure protection | Network segmentation, edge protection, host hardening | Infrastructure protection |
| Data protection | Classification, encryption, key management, retention | Network and encryption |
| Detection | Threat detection, posture monitoring, alerting | Detection |
| Compliance | Continuous evaluation against a standard | Config compliance |
| Application security | Secure SDLC, scanning, dependency and secret management | DevSecOps shift-left |
| Incident response | Detection to containment to recovery to learning | Runbooks |
Control layers
Controls are applied at multiple points so that no single failure is sufficient for a breach.
Prevent SCPs · IAM boundaries · network controls · KMS key policy
Detect GuardDuty · Security Hub · Config rules · Prowler · CloudTrail
Respond EventBridge · runbooks · quarantine SCP · incident process
Recover Backups · restore drill · key recovery · post-incident review
A control implemented only at the detection layer allows the violation and reports it afterwards. Use prevention where the consequence is unacceptable, and detection where remediation is safe.
Principles
- Least privilege, enforced by structure. Separate accounts, scoped roles and resource-level policies, not just a written rule.
- Short-lived credentials. Roles and OIDC; access keys are the exception and are rotated on a maximum age.
- Encrypt by default. Encryption at rest and in transit is the default configuration; disabling it requires a recorded decision.
- Immutable infrastructure. Rebuild rather than patch, so a compromised host is replaced rather than cleaned.
- Shift left. Security requirements, threat modelling and scanning happen in design and build — not at a pre-release gate.
- Evidence continuously. Compliance is demonstrated from telemetry, not from a quarterly document.
- Assume compromise. Detection, containment and recovery are designed in advance and exercised.
Risk acceptance
Not every finding is fixed immediately. A finding may be accepted when:
- It is documented with an owner and an expiry date.
- The compensating control is recorded.
- The acceptance is approved by someone with the authority to carry the risk.
- It is reviewed at expiry.
An accepted risk with no expiry is an ignored risk.
Evidence
- Control inventory mapped to a standard (CIS, SOC 2, ISO 27001) where applicable.
- Config compliance dashboard and rule list.
- Security Hub findings and their resolution.
- Penetration test or DAST report with remediation record.
- Incident response runbooks and drill records.
- Risk register with accepted risks and expiry dates.