# AEGIS — Operational Security Standard - **Document ID:** ARCH-23 - **Phase:** C — Standards & Operations - **Status:** Draft for review (post four-reviewer discipline) - **Version:** 0.1 - **Date:** 2026-07-10 - **Owner:** Chief Security Architect - **Depends on:** ARCH-10 through ARCH-22 - **Consumed by:** ARCH-24 and every operational playbook. --- ## 1. Purpose Codify how AEGIS is operated day-to-day such that operational reality does not silently undo architectural intent. Focus areas: access control for operators, ceremonies, change management, drills, third-party risk, personnel security, physical security for HSM/root artifacts, sustainability of on-call, and jurisdictional handling. Implements mandate #32 (Operational Simplicity) as an explicit organizing principle — everything in this standard must be executable by a well-trained security engineer without hidden knowledge. ## 2. Scope - **In scope:** operating AEGIS-as-a-product (both self-hosted deployments AEGIS supports and future hosted service). - **Out of scope:** tenants' operational choices inside their own environments. Standard provides guidance tenants may adopt but does not prescribe for them. ## 3. Requirements - **REQ-1.** Every operational procedure is a signed runbook (ARCH-21). - **REQ-2.** Every ceremony is drilled and audited (ARCH-22 §4.9). - **REQ-3.** Every operator access is capability-scoped, time-boxed, and audited. - **REQ-4.** Every third-party dependency has an assessed operational risk and a documented alternative. - **REQ-5.** Every jurisdictional obligation is mapped to a runbook. ## 4. Mandatory Rules ### 4.1 Operator Access - **M-1.** No shared accounts. Every action is attributable to an identified individual. - **M-2.** Least-privileged capabilities: standing capabilities cover routine ops; elevated capabilities require break-glass (ARCH-08 §4.10). - **M-3.** MFA required for all operator accounts; hardware key (FIDO2/passkey) recommended; TOTP fallback documented. - **M-4.** Session TTL bounded; re-auth for privileged operations at inner interval (per ARCH-11 Continuous Validation windows). - **M-5.** Termination process: identity revoked ≤ 1 hour of notification; capability directory reconciled; session revoked. ### 4.2 Change Management - **M-6.** Every production change goes through PR review + CI gates + canary deploy + monitoring windows. - **M-7.** Changes to security-critical paths require two-approver (ARCH-19). - **M-8.** Emergency change process: expedited path with Owner approval + post-hoc review within 5 business days. - **M-9.** Rollback plan mandatory in every change; canary metrics gate promotion. ### 4.3 Ceremonies - **M-10.** Ceremonies are conducted per ARCH-22 §4.9: two operators + Auditor observer + recording + hash-registered artifact. - **M-11.** Ceremony calendar published within AEGIS; ceremonies scheduled during working hours in the primary time zone unless emergency. - **M-12.** Ceremony rehearsals in staging at least twice per year, cross-team. - **M-13.** Ceremony participants trained + tested annually. ### 4.4 Drills - **M-14.** Runbook drills per category quarterly (ARCH-21 §10). - **M-15.** Table-top exercises for SEV-1 scenarios biannually. - **M-16.** Recovery drills (backup restore, DR, KEK rotation) per ARCH-18 §6.3. - **M-17.** Chaos drills — synthetic alarm injection — monthly. - **M-18.** Drill results tracked; failed drills produce incident-style reports. ### 4.5 Third-Party Risk - **M-19.** Every third-party dependency (cloud provider, KMS/HSM provider, AI provider, storage provider, IdP, threat-intel feed, plugin publisher, model provider) has a **Vendor Risk Assessment** (VRA) covering: SOC 2 or equivalent, data-residency, incident-history, SLAs, exit strategy, contractual right to audit. - **M-20.** For every critical third-party dependency, a **documented alternative** must exist that could be adopted within a stated migration window. - **M-21.** Provider incident notifications trigger AEGIS internal incident triage. - **M-22.** Trust vectors (ARCH-11 §6) inform routing; low trust = route away. ### 4.6 Personnel Security - **M-23.** Background checks for roles with production access (jurisdictionally compliant). - **M-24.** Separation of duties: production access ≠ audit access; signing ≠ verification; IC ≠ Communicator (ARCH-21). - **M-25.** Onboarding + offboarding runbooks; access review quarterly. - **M-26.** Security training annually + incident-response training biannually. ### 4.7 Physical Security (for on-prem HSMs, ceremony rooms, air-gap storage) - **M-27.** Physical access to HSM racks requires multi-party + logged entry. - **M-28.** Ceremony rooms: secured, camera-monitored, isolated network. - **M-29.** Air-gap media handling: chain-of-custody documented; media destroyed at end of life per policy. - **M-30.** For customer self-hosted deployments, AEGIS publishes recommended physical controls but does not enforce. ### 4.8 Jurisdictional Handling - **M-31.** Every tenant has a documented jurisdictional posture: primary region, permitted regions, restricted regions, applicable regulatory frameworks (GDPR, HIPAA, ISO27001, SOC2, FedRAMP-Mod, etc.). - **M-32.** Jurisdictional matrix mapped to runbooks: cross-jurisdiction actions (L3 AI calls, data exports, tenant transfers) require jurisdiction check + audit. - **M-33.** Regulatory notification obligations documented per jurisdiction; templates versioned. ### 4.9 On-Call Sustainability - **M-34.** Rotation modeled such that on-call fraction of time per person does not exceed policy threshold. - **M-35.** Burnout signals monitored; rotation adjustments driven by SLO deviation. - **M-36.** On-call compensation documented; escalation paths ensure no single individual is a SPOF. ### 4.10 Documentation and Knowledge Management - **M-37.** Runbooks, ceremony scripts, tenant docs, and security posture living in-repo; PR review; version-controlled (mandate #30). - **M-38.** Knowledge transfer sessions when key personnel change roles. - **M-39.** Playbooks tested by rotation; "who knows this" is a metric. ### 4.11 Cryptographic-Material Handling - **M-40.** Root keys generated at witnessed ceremony (multi-party, video, chain of custody). - **M-41.** Backup key material stored per ARCH-11 (dedicated backup KEK hierarchy). - **M-42.** Key ceremony participants rotate; no permanent "key holder". ## 5. Recommended Practices - **R-1.** Prefer automation for repetitive ops (with human-checkpoint gates). - **R-2.** Prefer clarity in runbooks — imperative, checkable steps. - **R-3.** Prefer training over hidden knowledge; if operators need a wiki page not linked from a runbook, the runbook is broken. - **R-4.** Prefer boring, well-understood tooling over shiny. - **R-5.** Prefer weekly cadences over ad-hoc for routine ops. - **R-6.** Prefer explicit post-mortems even for small drill failures. ## 6. Verification Process - **Weekly ops review.** Metrics + incident + drill outcomes; anomalies discussed; action items assigned. - **Monthly change review.** All changes reviewed; unusual patterns flagged. - **Quarterly access review.** Who has what capability + why; unused = revoked. - **Biannual DR + ceremony rehearsal.** Full stack drills. - **Annual audit** by external party against SOC 2 / ISO 27001 controls. ## 7. Operational Guidance - **New team members:** onboarding runbook + shadow rotation before primary on-call. - **When runbook fails:** IR opens on runbook itself; runbook updated within the SLO. - **When a drill fails:** action items with owners + due dates; auditor visibility. - **When a vendor fails:** Vendor Risk re-assessed; migration to alternative if warranted. - **When jurisdictional obligation changes:** matrix updated + all affected tenants notified within SLO. ## 8. Future Evolution - **Automated response for narrow ops** (Phase 3 Response Engine). - **Federated ops for MSSP** — multi-tenant hosted mode requires additional runbooks for cross-tenant separation. - **Regional operations** — 24/7 rotation across regions once headcount permits. - **Continuous compliance monitoring** — automated evidence collection for annual audit. ## 9. Independent Architecture Review (Reviewer 1) - **F-1.** *"Well-trained SE"* is an SLA on training, not just tools. Standard mandates M-26 annual training + drills; measurable. - **F-2.** *VRA maintenance decays.* Reassessment cadence documented; incident-driven refresh. - **F-3.** *Alternative-vendor plans get stale.* Migration drill included in DR cadence — actually exercise the exit strategy. - **F-4.** *Physical security is deployment-dependent.* AEGIS publishes recommendations; customer environments vary. ## 10. Adversarial Architect Review (Reviewer 2) - **A-1.** *Insider grants themselves capabilities.* Two-approver + auditor visibility + drift monitor; anomaly detection on grant patterns. - **A-2.** *Attacker phishes an operator into approving a bad change.* MFA + hardware keys + structured verification of change details out-of-band. - **A-3.** *Attacker infiltrates as a new hire.* Background checks + trial period for privileged access + gradual capability grant. - **A-4.** *Attacker exploits a jurisdictional gray zone to move data.* Jurisdictional matrix + jurisdiction check on cross-region ops; matrix updates ceremony-controlled. - **A-5.** *Attacker suborns a vendor.* Vendor trust vector + alternatives + exit strategy; incident triage on vendor incident. - **A-6.** *Attacker exhausts on-call to lower response quality.* Rotation health metrics + escalation paths + secondary on-call always available. ## 11. Operational Reliability Review (Reviewer 3) - **O-1. Ops sustainability at 15 years.** Rotation modeling; documented burnout thresholds; escalation. - **O-2. Documentation drift.** Docs-as-code + drift monitors on runbook age. - **O-3. Vendor churn.** Alternatives documented + drilled; migrations planned. - **O-4. Access review scaling.** Automated candidate list; human-review only anomalies. - **O-5. Drill overhead.** Balanced cadence; automated where safe. - **O-6. Training scaling.** Track training completion; refresh materials annually. - **O-7. Global team support.** Runbook language + tooling ready for cross-region ops. ## 12. Self-Critique (Reviewer 4) - **S-1.** *"Alternative vendor exists"* is easy to claim without exercising the exit path.* Added: exit-path drill included in DR cadence (M-16). - **S-2.** *M-34 rotation modeling* — "policy threshold" is unspecified. Standard should provide default (e.g., ≤ 20% of a person's calendar as on-call); companies vary. Left unspecified in standard but noted for operational policy. - **S-3.** *Physical security applies unevenly.* AEGIS runs SaaS in cloud (mostly); on-prem for some customers. Standard makes clear the split. - **S-4.** *Personnel security across jurisdictions is legally complex.* Ack; runbook flag for legal review per jurisdiction. - **S-5.** *"Weekly ops review"* is easy to become perfunctory.* Structured agenda templates + rotating chair + auditor visibility mitigate; but this is culture-dependent. Added metric: weekly-review action-item close rate. - **S-6.** *Access review quarterly* — long time; some access should be revalidated more frequently (privileged access weekly). Added: privileged access review weekly; standard access quarterly. Revising in place: - Added **M-16a.** Exit-path drill for each critical third-party dependency at least once per year. - Added **M-4a.** Privileged access re-attestation weekly; standard access quarterly. - Added metric tie-in to ARCH-24. ## 13. Attacker's First-Target Analysis and Redesign **"If I were an experienced attacker, what part of this standard would I target first?"** **Operator onboarding.** Reason: onboarding is when trust is granted with the least evidence — a new hire has a background check but no operational track record, and their initial capability grants set the pattern for years. An attacker who can plant a legitimate hire (via a social-engineering approach to a hiring manager, or by inserting themselves via a compromised recruiter) starts with legitimate credentials and a clean history. **Redesign response.** 1. **Graduated capability grants.** New operators do not receive elevated capabilities on day one. A documented ramp gives capabilities as operational track record accrues. 2. **Trial period for privileged access.** First 90 days: paired ops only; no solo elevated actions. 3. **Cross-team review.** New operator capability grants reviewed by a peer team beyond the hiring team; auditor visibility. 4. **Structured onboarding drill.** New operators complete IR drills before independent on-call rotation. 5. **Behavior baseline.** Adaptive Trust (ARCH-11 §6) applied to operators — anomalous first-months patterns alarm. 6. **Recurring background/security check** on ceremony participants (jurisdictionally compliant). **Second target.** Ceremony rehearsal quality. Response: rehearsals scheduled; test artifacts used; failure modes injected; results reviewed by Auditor. **Third target.** Vendor exit path staleness. Response: exit drills annually (M-16a); metric tracks currency. ## 14. Decisions ### D-23-1. Graduated capability grants for new operators (§13 response) - **Advantages.** Structural resistance to malicious hires; incremental trust. - **Disadvantages.** Slower productivity initially. - **Security Impact.** *Strongly positive.* - **Performance Impact.** N/A. - **Operational Complexity.** Moderate. - **Maintainability.** Positive. - **Scalability.** Positive. - **Alternatives.** *Full capabilities on day one.* Rejected — attack target too rich. - **Reason.** §13 first-target analysis. ### D-23-2. Documented + drilled alternative per critical vendor - **Advantages.** Real exit path; not just paper claim. - **Disadvantages.** Migration drills are expensive. - **Security Impact.** *Positive.* - **Performance Impact.** N/A. - **Operational Complexity.** *Higher* — but bounds vendor lock-in risk. - **Maintainability.** Positive. - **Scalability.** Positive. - **Alternatives.** *"Provider is chosen and stable."* Rejected — dependency risk. - **Reason.** Mandate #34 Platform Sustainability + Zero SPOT. ### D-23-3. Weekly review of privileged access - **Advantages.** Bounds silent-drift window; catches unusual patterns fast. - **Disadvantages.** Reviewer time. - **Security Impact.** *Positive.* - **Performance Impact.** N/A. - **Operational Complexity.** *Moderate.* - **Maintainability.** *Positive.* - **Scalability.** *Positive.* - **Alternatives.** *Quarterly only.* Rejected for privileged access. - **Reason.** Continuous Validation + Zero SPOT applied to access. ## 15. Open Questions - Q-23-1. Regional on-call rotation timing. Roadmap. - Q-23-2. Continuous-compliance evidence collection framework. Roadmap. - Q-23-3. Federated-ops runbook for MSSP mode. Phase 3. ## 16. Change Log - **0.1 (2026-07-10)** — Initial draft after four-reviewer discipline.