12 — Mission Profiles

Status: Ratified Version: 1.0.0 Applies to: config/profiles/<id>.yaml, Mission Engine, Planner, Workflow, Reporting

1. Purpose

A Mission Profile is the declarative definition of a complete assessment type. It binds together: workflow phases, objectives, allowed tools, expected outputs, reports, and the risk model. Profiles are data (YAML), validated against a JSON Schema, and versioned.

The twelve supported profiles are enumerated in 01 - Vision.md §6.

2. Profile Schema (common structure)

id: external-pentest          # stable identifier
version: 1
name: External Penetration Test
description: Perimeter-focused pentest of internet-facing assets.
supported_targets: [domain, ip, cidr, url]
phases:
  - id: recon
    name: Reconnaissance
    steps: <workflow steps, see 10 - Workflow Engine>
objectives:
  - "Identify internet-facing attack surface"
  - "Discover exploitable vulnerabilities with PoC"
allowed_tools:
  include: [subfinder, dnsx, nmap, nuclei, httpx, sqlmap, wpscan]
  exclude: [hydra]              # e.g., no brute-force by default
tool_profiles: { default: fast, stealth: quiet }
expected_outputs:
  findings: { min_severity: info }
  assets: [domain, host, ip, port, service, url]
  evidence: required
  reports: [technical, executive, evidence-package]
approval_level: operator        # auto|operator|destructive-approval
risk_model:
  formula: cvss-v3-base-v2      # risk model id
  weights: { exploitability: 0.4, impact: 0.4, exposure: 0.2 }
  escalation: { critical: alert, high: notify, low: silent }
compliance_map: [owasp-top10, pci-dss]
constraints:
  max_scan_duration_h: 24
  max_concurrency: 20
  default_timeouts: { per_request_s: 30 }

3. Cross-Cutting Profile Fields

Field Meaning
supported_targets Target kinds this profile accepts
phases Ordered workflow phases (see 10)
objectives Mission success criteria
allowed_tools Include/exclude tool ids (vs 07 §15 mission_rules)
tool_profiles Default tool run profiles (fast/thorough/stealth/quiet)
expected_outputs Contract: what the mission MUST produce
approval_level Human-approval requirement tier
risk_model Formula + weights + escalation
compliance_map Report mapping targets
constraints Time, concurrency, timeout budgets

4. The Twelve Mission Profiles

4.1 bug-bounty

4.2 web-security

4.3 api-security

4.4 external-pentest

4.5 internal-pentest

4.6 ad-assessment (Active Directory)

4.7 cloud-security

4.8 container-security

4.9 kubernetes-security

4.10 mobile-security

4.11 network-security

4.12 continuous

5. Approval Levels

Level Meaning Enforced
auto Runs without human in the loop none beyond scope
operator Mission start + destructive-class steps need approval approval gate step (10 §3)
destructive-approval Any potentially destructive/impactful action needs explicit approval with justification approval gate + scope policy

Planner never bypasses the level; tool knowledge mission_rules.approval_level (07 §15) is the floor, and profile level is the ceiling.

6. Risk Models

6.1 Formula Framework

Risk is deterministic:

risk_score = Σ (weight_i × normalized_factor_i)
normalized factors: exploitability, impact, exposure, likelihood, detectability
clamped to [0,10]; severity derived per 08 §5

6.2 Default Models

Model id Basis When
cvss-v3-base-v2 CVSS v3 base + exposure most web/external
cvss-v3-aug-internal CVSS + internal reachability internal pentest
ad-privilege-path privilege path + domain impact AD assessment
cloud-iam-blast IAM blast radius + data exposure cloud
image-and-runtime image severity + runtime posture container/k8s
mobile-data-exposure data exposure + platform mobile
continuous-trend delta + trend weighting continuous

Custom models are plugins (ai-strategy/custom risk model) per 05.

7. Expected Outputs Contract

Each profile declares expected_outputs; the Mission Engine validates at completion:

Failure to meet the output contract → mission marked completed-with-warnings (or failed if a mandatory artifact is absent).

8. Adding / Modifying Profiles

9. References