# FortWin Attack Graph Strategy Generation Spec Version: 1.0 Status: Redis-first implementation spec Scope: Forge generation -> Promotion Assurance -> Council -> Control Plane strategy package ## Purpose FortWin should generate bounded defensive strategies from attacker paths, not just isolated artifacts. The strategy generator converts: - `AttackGraph` - `TraceSummary` - `ExploitClassification` - `RepairArtifactMatrixRow` - `HostFacts` - retrieval memory into: - bounded strategy variants - ordered strategy phases - compatible defensive artifacts - strategy validation inputs - a first-class `DefenseStrategyPackage` ## Core Rule Attack graph strategy generation is creative in composition but bounded by deterministic policy. It may not bypass: - `FAMS/ECE` - platform isolation - compiler hard gates - admission checks - replay validation - Promotion Assurance - Council selection ## Current V1 Scope Current implementation scope is intentionally narrow: - exploit family: `RedisChildShellExecution` - platform family: `windows` - matrix row: `windows.redis.execution.child_shell` - max phases: `2` - max artifacts: `2` - preferred strategy families: - `BehaviorGuard` - `BehaviorGuard -> ServiceHardening` `AutomatedRepair` and broader multi-service recovery strategies are out of scope for this slice. ## Pipeline `ingest -> classify -> matrix lookup -> retrieve memory -> generate repair intents -> compile strategy candidates -> validate strategy coherence -> promotion assurance -> council -> defense strategy package` ## Strategy Model ### Strategy candidate FortWin continues to use `StrategyCandidate` as the pre-council working object. Each strategy candidate contains: - `AttackGraph` - `DefenseGraph` - candidate artifacts - validation state - metadata including matrix row, exploit family, platform family, service family, and profile ### Defense strategy package Council emits a `DefenseStrategyPackage` as the post-selection authoritative strategy object. The package now carries: - `strategy_id` - `trace_id` - `attack_fingerprint` - `strategy_profile` - `exploit_family` - `matrix_row_id` - `platform_family` - `service_family` - `attack_phase` - `attack_graph` - `defense_graph` - `defense_nodes` - `defense_edges` - `phases` - `artifacts` - `activation_plan` - `safety_constraints` - `success_criteria` - `rollback_reference` ## Strategy phases FortWin uses these phase kinds: - `Contain` - `Harden` - `Recover` - `Observe` Each `StrategyPhase` includes: - `phase_id` - `kind` - `order` - `goal` - `artifact_ids` - `preconditions` - `success_criteria` - `activation_rules` ## Redis-first phase mapping For Redis child-shell execution on Windows: ### Phase 1: Contain Preferred artifact: - `BehaviorGuard` Goal: - stop `redis-server` from launching shell children Success criteria: - no shell child from `redis-server` - Redis process remains healthy ### Phase 2: Harden Preferred artifact: - `ServiceHardening` Goal: - reduce Redis exploitability after containment succeeds Success criteria: - Redis hardening applied successfully - Redis reload/restart remains healthy ## Defense graph mapping The strategy package derives a defense graph from the chosen candidate. It contains: - attack-transition nodes for the highest-confidence choke points - strategy-phase nodes - defense-artifact nodes - edges: - `defends` - `activates` - `depends_on` This provides an explainable mapping between: - attacker path - defensive choke point - ordered defense action ## Strategy generation rules Generator should emit bounded variants: - `Conservative` - `Balanced` - `Phased` For Redis-first V1: - `Conservative` should usually favor `BehaviorGuard` - `Balanced` may favor bounded `ServiceHardening` - `Phased` should compose `BehaviorGuard -> ServiceHardening` Generator must preserve: - exploit family - platform family - matrix row - service family Generator may not: - cross platform boundaries - use forbidden surfaces - emit artifact kinds forbidden by the matrix row ## Assurance role Promotion Assurance evaluates the strategy as a plan, not just as a single artifact. It critiques: - semantic drift - scope breadth - rollback completeness - phase ordering - policy fit - canary fitness - whether a smaller strategy would be safer It may still choose a single-artifact survivor over a multi-artifact strategy. ## Strategy validation `StrategyValidationResult` now includes: - hard gate outcome - replay/simulation outcome - canary readiness - rollback feasibility - `phase_ordering_valid` - `strategy_coherent` - `phase_count` - `phase_failures` Current phase validation checks include: - phase presence - sequential phase ordering - artifact membership by phase - dependency references - `Contain` before `Harden` for execution-path strategies - minimum phase depth for phased multi-artifact candidates ## Council behavior Council remains authoritative. It: - validates candidate strategies - scores them - records promotion assurance inputs - can choose the best single artifact or the best phased strategy - emits one authoritative `DefenseStrategyPackage` ## Activation rules Current activation planning remains phase-aware and adds: - `phase_count` - `phase_sequence` - `strategy_profile` Phase activation rules support gated sequencing, for example: - phase 2 requires phase 1 canary success ## Success criteria Strategy packages now persist success criteria such as: - no shell child from `redis-server` - Redis service remains healthy - critical execution transition interrupted - rollback available for each strategy phase ## Observability Current strategy events include: - candidate evaluated - replay validated - verdict emitted - strategy package created The strategy package created event now also records: - `phase_count` - `strategy_profile` - `exploit_family` - `matrix_row_id` ## Redis-first milestone The Redis strategy slice is successful when: - Forge generates a phased Redis candidate - Council can validate ordered phases - the package contains bounded matrix-valid artifacts - no platform or forbidden-surface drift occurs - at least one Redis strategy reaches Council ## Current truth This is the first attack-graph strategy slice, not the final system. What is real now: - strategy packages carry phased structure - Council validates strategy coherence - Redis execution strategies derive ordered containment/hardening phases - attack-to-defense mapping is persisted in package form What is not complete yet: - dedicated strategy revision loop - broader exploit-family strategy libraries - service-family-specific recovery phases beyond Redis-first bounded scope - dashboard visualization of strategy phases and defense graph structure