Cloud Security Platform Architect

Wrote docs/architecture/cloud-security-architect/00-overview/cloud-security-architect-overview.md and docs/architecture/cloud-security-architect/verification/fitness-self-check.md. Complete cloud security platform architecture specifying multi-account landing zone baselines, Service Control Policies, centralized Network Firewall egress inspection, and GuardDuty CSPM governance.

---

skill: cloud-security-architect

Cloud Security Architecture: FinTech Banking Foundation [CLOUDSEC-FIN-001]

Summary

This specification establishes the enterprise cloud security architecture, multi-account perimeter controls, and security posture management for the FinTech Banking Foundation under run ID fintech-cloudsec-arch-001, governing 75 AWS accounts across 4 banking domains. It decisively eliminates the credential leakage and unmonitored network egress demonstrated in incident SEC-4928 (where an unconstrained dev account compromised cloud credentials and opened uninspected outbound sockets). The design enforces AWS Organizations landing zone security baselines, root-level Service Control Policies (SCPs) prohibiting local Internet Gateways in workload spokes, centralized traffic inspection via AWS Network Firewall, automated GuardDuty threat detection with EventBridge auto-remediation, and an isolated Log Archive account with 7-year WORM storage.

Detailed Description

Operating enterprise cloud infrastructure across dozens of decentralized accounts without root-level preventative guardrails guarantees configuration drift and perimeter breaches. When individual engineering teams can provision Internet Gateways or disable security logging, a single compromised development environment can be leveraged for lateral movement into production cardholder data environments (CDE).

AWS Organizations Root: Management Account
                         │
        ┌────────────────┴────────────────┐
        ▼ (Root Service Control Policies) ▼
[ Security Core OU ]              [ Workload Business Units OU ]
  ├── 1. Log Archive Account        ├── Payments Domain Accounts (Prod/Stg/Dev)
  │     └── Immutable S3 WORM Vault ├── Core Banking Accounts (Prod/Stg/Dev)
  ├── 2. Security Tooling Account   └── Wealth & Lending Accounts
  │     ├── GuardDuty / Security Hub              │
  │     └── AWS Network Firewall                  ▼ (Default Egress Route via TGW)
  │           (Central Egress) ◄──────────────────┘ (Zero Local Internet Gateways)

Mechanism Specifications

1. Trust Boundary & Network Enforcement:

   • Owner: Marcus Vance (Lead Security Architect).
   • Trigger: Resource provisioning, VPC route change, or cross-account peering attempt.
   • State/Algorithm: Workload spokes attach to AWS Transit Gateway with appliance mode enabled. All north-south internet traffic is deterministically routed to the Central Inspection VPC where AWS Network Firewall enforces Layer 7 stateful domain allowlists and SNI filtering. Local Internet Gateways and direct public NAT gateways are prohibited by root Service Control Policies (SCPs).
   • Failure Behavior: Any API request to create or attach an Internet Gateway in workload accounts returns HTTP 403 AccessDeniedException via SCP. Any unauthorized security group ingress rule exposing 0.0.0.0/0 triggers immediate automated revocation via AWS Config auto-remediation rule within 60 seconds.
   • Test Oracle: Automated network topology simulation probe verifying zero uninspected network paths between workload subnets and public CIDR ranges.

2. Authorization Policy & Principle of Least Privilege:

   • Owner: David O'Reilly (Chief Information Security Officer).
   • Trigger: IAM role creation, cross-account trust alteration, or STS session token issuance.
   • State/Algorithm: IAM Identity Center SSO enforces workforce role-based access control with short-lived session tokens (max 1 hour). Workload authentication uses IAM Roles for Service Accounts (IRSA) or instance profile attestation; static long-lived IAM access keys are blocked by SCP. Authentication alone never grants resource authorization; resource-based policies enforce explicit context attributes (e.g. source VPC endpoint, tenant tag, mTLS identity).
   • Failure Behavior: STS role assumption lacking required MFA or context attributes returns AccessDenied. Non-compliant API actions generate CloudTrail security events dispatched to GuardDuty.
   • Test Oracle: Policy simulator probe verifying authenticated non-privileged identities cannot access production CDE S3 buckets or KMS keys.

3. Threat-Control Mapping & Automated Posture Governance (CSPM):

   • Owner: Security Operations Center (SOC) / David O'Reilly.
   • Trigger: Continuous configuration change events and GuardDuty threat detection findings.
   • State/Algorithm: Security Hub aggregates findings across all 75 accounts into the delegated administrator Security Core account. Findings map deterministically to NIST SP 800-53 and CIS AWS Foundations Benchmark v3.0 controls. Amazon GuardDuty analyzes CloudTrail management/data events, VPC Flow Logs, and EKS audit logs for anomalous activity (e.g. leaked credentials, unauthorized C2 beaconing).
   • Failure Behavior: High-severity GuardDuty findings trigger Amazon EventBridge rules that invoke automated Lambda containment runbooks to revoke IAM sessions, quarantine security groups, or snapshot compromised instances within 60 seconds.
   • Test Oracle: Synthesized GuardDuty finding injection verifying automated event-driven quarantine execution and P1 SecOps alert dispatch.

4. Credential Lifecycle & Key Rotation:

   • Owner: Cloud Platform Engineering / SecOps.
   • Trigger: KMS key creation epoch, secrets creation, or scheduled rotation timers.
   • State/Algorithm: Encryption at rest across all accounts uses AWS KMS Customer Managed Keys (CMKs) with automated annual rotation enforced. Database passwords and API tokens reside in AWS Secrets Manager with automated 30-day rotation schedules backed by VPC-hosted rotation Lambdas. Static IAM user credentials are systematically purged on account vending.
   • Failure Behavior: Automated warning raised at day 20 if secret rotation fails. Any unrotated secret exceeding 90 days triggers automated ticket escalation and pipeline deployment gating.
   • Test Oracle: Automated AWS Config audit query asserting zero KMS CMKs without key rotation enabled and zero active IAM access keys older than 90 days.

Criteria and weights

Alternatives rejected

Contracts and Invariants

Prohibition of Local Workload Egress [INV-CSEC-01]
  Workload AWS accounts must not deploy Internet Gateways or direct public NAT Gateways.
  All outbound internet traffic must route through the Central Inspection VPC.

Tamper-Evident Security Log Isolation [INV-CSEC-02]
  Security telemetry must be ingested into a dedicated, isolated Log Archive account.
  Local account administrators must not possess permissions to modify or delete CloudTrail logs.

Automated Credential Quarantine Ceiling [INV-CSEC-03]
  Compromised access keys or active command-and-control beaconing detected by GuardDuty must be
  quarantined automatically within 60 seconds of finding publication.

Root Service Control Policy Enforcement [INV-CSEC-04]
  All AWS accounts in the organization must inherit root Service Control Policies blocking the modification
  of security agents (GuardDuty, Security Hub, Config) and restricting deployment to approved regions.

Ownership and Handoffs

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against cloud security architecture standards:

• Perimeter Rigor: PASS. Root SCPs block local Internet Gateways; all traffic traverses central firewalls.
• Log Defensibility: PASS. Dedicated Log Archive account with S3 Object Lock Compliance Mode ensures immutability.
• Threat Automation: PASS. GuardDuty + EventBridge + Lambda auto-quarantines compromised assets in < 60s.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-CSEC-01: David O'Reilly to determine whether AWS IAM Access Analyzer external access alerts should trigger automated S3 bucket public access blocking (Owner: David O'Reilly).

Next steps

1. Marcus Vance provisions AWS Organizations Service Control Policies across all member accounts.
2. Security team configures central AWS Network Firewall endpoints in the Central Inspection VPC.
3. Deploy automated Lambda threat quarantine remediation functions across staging accounts.

---

skill: cloud-security-architect

FinTech Banking Foundation Cloud Security — Fitness Self-Check [CLOUDSEC-FIT-001]

Summary

This fitness self-check evaluates the cloud security platform architecture against three critical red-capable domain failure modes: snowflake infrastructure, process-equals-readiness, and unowned shared platform. All targeted probes pass by design construction. A self-check is supporting evidence, never the authoritative gate. Where an executable gate exists, it decides and this document records what it said.

Detailed Description

Residual Risk

• AWS Network Firewall deep packet inspection latency during sudden 45,000 req/sec payment gateway bursts may introduce a 2 ms latency penalty. Accepted by Marcus Vance pending auto-scaling rule group performance validation in Q4.

Traceability

Verification

No validator was supplied, so no command was run.

Open Decisions

None.

Next steps

1. Security Platform team deploys root SCPs into AWS Organizations root container.
2. Network team validates Transit Gateway appliance mode routing through the Central Inspection VPC.
3. Conduct staging red-team exercise verifying automated sub-60s Lambda credential revocation upon simulated GuardDuty alerts.