# AEGIS — Blue Team Framework

- **Document ID:** ARCH-46
- **Phase:** E.3 — Adversarial/Defensive Teams
- **Status:** Draft for review (post four-reviewer discipline)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect

---

## 1. Purpose

Codify the Blue Team's defense engineering function: detection engineering, IR readiness, and continuous tuning. The Blue Team is *the* consumer of Red-Team findings and *the* author of the deterministic detection layer AEGIS depends on.

## 2. Responsibilities

- **Detection engineering.** Sigma rule authorship + tuning + fixture-testing + coverage against ARCH-03 threat model.
- **IR readiness.** Runbook currency (ARCH-21), drill leadership, tool proficiency.
- **Baseline maintenance.** Detection metrics (ARCH-24), false-positive tuning, false-negative recovery from red findings.
- **Detection content lifecycle.** Signed contributor pipeline (ARCH-14 §7).
- **Threat-intel integration.** Feed vetting + trust vector.

## 3. Cadence

- **Weekly.** Rule tuning; false-positive review; ATT&CK coverage delta.
- **Monthly.** New-rule authoring; regression tests; corpus rotation.
- **Quarterly.** Purple engagement (ARCH-47); ATT&CK-technique-coverage audit.
- **On trigger.** Every red-team finding → rule / runbook / tests; every incident → post-mortem + threat-model diff.

## 4. Detection-Content Spec (mandate #2 per rule)

Every published detection rule includes:
- **Purpose.** What behavior it detects.
- **Threats Addressed.** ATT&CK techniques + AEGIS adversary-profile refs.
- **Residual Risk.** What it misses.
- **Verification Method.** Positive fixture + negative fixture + fuzz variant.
- **Operational Cost.** Rule-eval latency + FP rate baseline.
- **Failure Mode.** How the rule degrades (data-schema drift, tenant baselines).
- **Recovery Method.** Auto-disable on eval-timeout + review path.
- **Removal Criteria.** Superseded by broader rule, deprecated threat class, or coverage moved to statistical detector.

## 5. Assumptions (hypothesis)

- **H-1.** *Sigma-based rules with fixture coverage catch ≥ 70% of correlation load through v0.*
   - Evidence: baseline measurements; industry norms.
   - Validation: measured against threat-simulation library.
   - Confidence: Medium.
   - Expiration: v1.
   - Review Date: 12 months.

## 6. Trust Score Contribution

Blue-team activities feed the Trust Score (ARCH-52) under `Verification`, `Health`, and `Operational History`.

## 7. Independent Architecture Review

- **F-1.** *Rule proliferation.* Governance rule + retirement discipline.
- **F-2.** *FP fatigue.* Metric-driven tuning + budget.

## 8. Adversarial Architect Review

- **A-1.** *Attacker author submits a rule that hides their own class of activity.* Signed contributor + review + fixture-required + cross-tenant view.
- **A-2.** *Attacker suppresses a fixture set.* Fixture-set signed; consistency-checker catches gaps.

## 9. Operational Reliability Review

- **O-1.** Cadence sustainable at team size.
- **O-2.** Onboarding for new detection engineers documented.

## 10. Self-Critique

- **S-1.** *Statistical detectors deferred to v1.* Documented as debt.
- **S-2.** *Rule quality dependent on team maturity.* External detection-engineering advisor supplements.

## 11. First-Target Analysis and Redesign

**Target:** rule-deletion path. A malicious deletion silences detection. Response: `Delete-Rule` capability is one-shot + break-glass + Auditor + regression tests must pass with the deleted rule considered active.

## 12. Future Risks / Known Limitations / Out-of-Scope / Retirement

- **Future Risks.** Adversarial rule-generation from LLMs; AI-crafted evasion.
- **Known Limitations.** Signature-based detection lags novel behavior; statistical detection is post-v0.
- **Out-of-Scope.** Autonomous rule generation without human review.
- **Retirement Conditions.** Never — Blue Team is permanent.

## 13. Decisions

### D-46-1. Detection-content spec per rule + retention discipline

- **Reason.** Mandate #2.

## 14. Change Log

- **0.1 (2026-07-10)** — Initial draft.