Enterprise Security Architecture and Governance Architect

Wrote docs/architecture/security-architect/00-overview/security-architect-overview.md and docs/architecture/security-architect/verification/fitness-self-check.md. Complete enterprise security architecture specification establishing holistic defense-in-depth, unified zero-trust baselines, centralized cryptographic governance, and cross-domain compliance controls.

---

skill: security-architect

Enterprise Security Architecture: Global FinTech Banking Group [SEC-ARCH-001]

Summary

This specification establishes the holistic enterprise security architecture, defense-in-depth model, and zero-trust control baseline for the Global FinTech Banking Group under run ID fintech-sec-arch-001, governing retail banking, wealth management, and institutional clearing across 120 microservices and 65 AWS accounts. It decisively eliminates the siloed tool fragmentation and lateral pivot vulnerabilities demonstrated in incident SEC-4933 (where an unaligned marketing acquisition with permissive perimeter rules permitted lateral threat propagation into core banking ledgers). The architecture enforces NIST CSF v2.0 and SABSA principles across five integrated control layers (Perimeter Edge, Network Transit, Identity & Access, Workload Execution, Data & Cryptography), centralizes root cryptographic authority in hardware security modules, mandates unified zero-trust identity assertions, and deploys continuous automated compliance telemetry.

Detailed Description

Operating an enterprise financial estate with decentralized, fragmented security tooling guarantees inconsistent policy enforcement. When individual product teams make autonomous decisions regarding network firewalls, secret storage, or authentication flows, security visibility collapses, creating unprotected seams along organizational boundaries. An overarching security architecture defines mandatory baseline invariants across all layers of the computing stack.

Enterprise Trust Ingress (Edge / Branch / Internet)
                         │
                         ▼
[ Layer 1: Edge & Perimeter Defense ]
  ├── Anycast DDoS Scrubbing (L3/4) + AWS WAF (OWASP Top 10)
  └── Centralized Egress Inspection VPC (AWS Network Firewall / Suricata)
                         │
                         ▼
[ Layer 2: Network & Microsegmentation ]
  ├── AWS Transit Gateway Appliance Mode (Zero flat WAN routing)
  └── Kubernetes Cilium eBPF Socket-Level Default-Deny
                         │
                         ▼
[ Layer 3: Identity, Authentication & Governance ]
  ├── Okta Central IdP + Phishing-Resistant FIDO2 WebAuthn Hardware Tokens
  └── AWS IAM Identity Center Ephemeral STS Tokens (1-Hour Max Lifetime)
                         │
                         ▼
[ Layer 4: Workload & Software Supply Chain ]
  ├── SLSA Build Level 3 Provenance (Cosign Signatures + Syft SPDX SBOMs)
  └── In-Memory Secret Delivery via Secrets Store CSI tmpfs Mounts
                         │
                         ▼
[ Layer 5: Data & Cryptographic Protection ]
  ├── Envelope Encryption (AWS KMS Multi-Region Customer Managed Keys)
  └── S3 Object Lock Vault in Compliance Mode (7-Year Immutable WORM)

Mechanism Specifications

1. Trust Boundary & Perimeter Enforcement:

   • Owner: Marcus Vance (Principal Cloud Security Architect).
   • Trigger: Any network packet crossing between external networks, shared services, and workload VPCs.
   • State/Algorithm: All north-south and east-west VPC traffic routes through AWS Transit Gateway with appliance mode enabled, directing packets into the Central Inspection VPC. AWS Network Firewall and Suricata inspect stateful sessions, enforcing strict domain allowlists and SNI validation. Direct Internet Gateways and public subnets are barred in workload accounts by root Service Control Policies (SCPs).
   • Failure Behavior: Block by default. Packets failing stateful signature checks or targeting unapproved domains drop immediately with ICMP unreachable discarded.
   • Test Oracle: Automated network path analyzer verifying zero direct egress routes from workload subnets to the public internet without Central Inspection traversal.

2. Authorization Policy & Context Evaluation:

   • Owner: Elena Rostova (Head of Core Banking Engineering / IAM Lead).
   • Trigger: Ingress API request or service-to-service RPC invocation.
   • State/Algorithm: Authentication token validity alone never grants authorization. Open Policy Agent (OPA) sidecars evaluate multi-attribute context on every call: subject role, tenant identifier, account clearance level, client IP CIDR, device posture score, and target resource sensitivity. Strict Deny-Overrides resolution applies.
   • Failure Behavior: Missing required context attributes or failed policy evaluation yields HTTP 403 AccessDenied and emits an immediate structured security audit event.
   • Test Oracle: Automated policy probe verifying valid authenticated teller identities cannot query wealth-management ledgers outside assigned branch hours.

3. Threat-Control Mapping & Automated Containment:

   • Owner: David O'Reilly (Chief Information Security Officer).
   • Trigger: High-severity telemetry finding from Amazon GuardDuty, AWS Security Hub, or container runtime agent.
   • State/Algorithm: Ingested threats map deterministically to NIST CSF v2.0 categories (Identify, Protect, Detect, Respond, Recover). Findings indicating credential exfiltration or C2 beaconing trigger Amazon EventBridge rules dispatching automated AWS Step Functions containment workflows within 60 seconds.
   • Failure Behavior: If automated containment fails or times out after 60 seconds, incident escalates to P1 SecOps on-call pager and applies emergency network quarantine security group via fallback automation.
   • Test Oracle: Synthetic GuardDuty compromised-token finding injection verifying automated STS session revocation and IAM role isolation within 45 seconds.

4. Credential Lifecycle & Cryptographic Custody:

   • Owner: Cryptographic Security Engineering / David O'Reilly.
   • Trigger: Secret creation epoch, scheduled rotation window (90 days maximum), or key compromise alert.
   • State/Algorithm: Application secrets reside in HashiCorp Vault / AWS Secrets Manager and inject into container memory via Secrets Store CSI driver (tmpfs mounts). Master root keys reside in FIPS 140-3 Level 3 Hardware Security Modules (AWS KMS CMKs). Automatic key rotation triggers every 90 days. Static, long-lived API keys are prohibited.
   • Failure Behavior: Secrets older than 90 days generate daily automated escalation tickets and block CI/CD pipeline deployments to production.
   • Test Oracle: Continuous compliance probe asserting zero unrotated cryptographic secrets or database credentials older than 90 days across all 65 AWS accounts.

Architectural Concerns

1. Holistic Security:

   • Trace to source: Root mandate from CISO David O'Reilly following SEC-4933 audit findings.
   • Architectural consequence: Security posture cannot be established at the perimeter alone; all five layers (Perimeter, Network, Identity, Workload, Data) must interlock with zero trust assumptions across layer boundaries.
   • Enforcement: Mandatory CI/CD pre-merge compliance gates and AWS Organizations Service Control Policies blocking out-of-band architecture mutations.
   • Recovery route: Architecture exceptions require dual-authorization cryptographic sign-off by CISO and Enterprise Architecture Board with 90-day hard expiration.

2. Defense in Depth:

   • Trace to source: Incident SEC-4933 post-mortem documenting single-point perimeter failure.
   • Architectural consequence: Compromise of an ingress container cannot permit access to core banking databases. Workload must traverse Cilium eBPF network microsegmentation, mutual TLS identity verification, fine-grained OPA attribute authorization, and envelope encryption.
   • Enforcement: Independent control layers operated by distinct engineering squads with separate credential and deployment planes.
   • Recovery route: Compromised container triggers automated pod termination, eBPF socket severance, and host isolation without impacting adjacent cluster tenants.

3. Risk Mitigation:

   • Trace to source: Board of Directors Risk Committee financial compliance charter (PCI-DSS v4.0, SEC Rule 17a-4).
   • Architectural consequence: Elimination of unquantified security debt and unmonitored lateral propagation paths across acquired subsidiary cloud accounts.
   • Enforcement: Centralized security telemetry aggregated into dedicated Log Archive account with S3 Object Lock in Compliance Mode (7-year immutable retention).
   • Recovery route: Daily automated ledger reconciliation and cryptographic hash-chain audits identify unauthorized modifications within 15 minutes of occurrence.

Criteria and weights

Alternatives rejected

Contracts and Invariants

Mandatory Multi-Layer Defense Invariant [INV-ESEC-01]
  No single security control failure may permit unauthorized access to core financial ledgers.
  Every sensitive transaction must traverse independent perimeter, network, identity, and data controls.

Absolute Prohibition of Static Credentials [INV-ESEC-02]
  Human operators and automated CI/CD runners must not possess long-lived static API credentials.
  All authentication must use ephemeral short-lived tokens (STS / OIDC) capped at 1 hour.

Immutable Audit Trail Custody Mandate [INV-ESEC-03]
  Security telemetry and transaction audit records must be locked in a dedicated Log Archive account
  under S3 Object Lock Compliance Mode for at least 7 years. Deletion by any identity is prohibited.

Root Cryptographic Hardware Custody [INV-ESEC-04]
  All master cryptographic keys and root CA keys must reside in FIPS 140-3 Level 3/4 Hardware Security
  Modules. Plaintext export of master keys is barred by physical hardware security policy.

Ownership and Handoffs

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against enterprise security architecture standards:

• Defense-in-Depth: PASS. Five independent control layers prevent lateral traversal.
• Identity Rigor: PASS. Zero static keys; 100% ephemeral tokens and phishing-resistant MFA.
• Cryptographic Assurance: PASS. Envelope encryption with FIPS 140-3 Level 3 HSM root of trust.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-ESEC-01: David O'Reilly to determine whether automated AI-driven autonomous response agents should be granted authority to sever cross-region cloud interconnects during suspected active APT intrusions (Owner: David O'Reilly).

Next steps

1. Marcus Vance provisions core Security OU accounts and deploys root Service Control Policies across all 65 accounts.
2. Platform team embeds reusable CI/CD security scanning templates into enterprise repository skeletons.
3. Conduct enterprise-wide red-team exercise validating defense-in-depth containment during simulated container breaches.

---

skill: security-architect

Global FinTech Banking Group Security — Fitness Self-Check [SEC-FIT-001]

Summary

This fitness self-check evaluates the overarching enterprise security architecture against three critical red-capable domain failure probes: authentication-as-authorization, unrotated secrets, and control without evidence. 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

• Transient 1.5 ms packet processing latency overhead introduced by inline Suricata deep packet inspection in the Central Inspection VPC. Accepted by Elena Rostova pending high-load performance benchmarking.

Traceability

Verification

No validator was supplied, so no command was run.

Open Decisions

None.

Next steps

1. Platform Security team schedules monthly automated execution of synthetic probes FIT-1 through FIT-3 in staging.
2. CISO David O'Reilly reviews quarterly fitness self-check reports as part of ISO 27001 compliance audit pack.