Writing the Report

# RoE FIRST. Authorised use only. The report is for the client to harden against,
# not a public brag sheet. Redact + secure handling are non-negotiable.

# ===== Report structure =====
# 1. Executive summary    (1 page; non-technical readers)
#    - Scope + dates + tester(s)
#    - Findings by severity (e.g. 1 critical, 3 high, 6 medium, 8 low)
#    - Top 3-5 recommended actions
# 2. Engagement details
#    - Scope (in / out), authorisation reference, test windows
#    - Methodology (PTES, OWASP WSTG, MITRE ATT&CK)
#    - Limitations
# 3. Findings (one section per)
#    - Title (clear + searchable)
#    - Severity (CVSS 3.1 + reasoning) + ATT&CK IDs
#    - Affected asset(s) + scope
#    - Description (what + why it matters)
#    - Evidence (screenshots, packet captures, log lines — redacted)
#    - Reproduction steps (LAB ONLY; no live exploits)
#    - Recommendation (specific fix or mitigation)
#    - Verification steps (how the client tests the fix)
# 4. Methodology + tools
# 5. Appendices (raw artefacts, scope tables, glossary)

# ===== Severity =====
# Use CVSS 3.1 with explicit vectors:
#   CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N -> 9.8 (Critical)
# Include the REASONING, not just the number. Context matters.

# Severity heuristics:
# Critical  exploitable remotely with low effort + high data exposure / control
# High      exploitable with limited prerequisites + significant impact
# Medium    requires elevated context or limited impact
# Low       limited exposure / mostly informational
# Info      hardening recommendation without an exploit path

# ===== Evidence =====
# - Always include timestamps in ISO 8601 UTC
# - Always include source IP / user / tooling used
# - Redact PII / sensitive data; use placeholders if needed
# - Encrypted storage in transit + at rest
# - Retention policy documented; deletion after agreed window

# ===== Reproduction steps =====
# Reproducible IN THE LAB, not on the client's prod system without explicit OK.
# Document parameters needed for a clean replay (env, account, payload).
# Avoid 'magic' inputs; specify exact request + response shapes.

# ===== Recommendation =====
# Pair every offensive finding with:
# - A SPECIFIC code / config / policy change
# - A DETECTION rule (Sigma, EDR, Wazuh) when applicable
# - A test that locks in the fix as a regression check

# ===== Verification steps =====
# - 'After the fix, send the same request; expect 403 with body X.'
# - 'Run the regression test in CI; ensure status remains green.'
# - 'Verify the new detection rule fires on the lab replay.'

# ===== Tone =====
# - Factual, not theatrical
# - Avoid 'we owned everything'; describe impact dispassionately
# - Praise good controls you found
# - Note constraints honestly (we did not test X because Y)

# ===== Delivery =====
# - Encrypted PDF or signed Markdown
# - Authenticated portal or password-protected via separate channel
# - Track receipt + sign-off
# - Schedule a debrief; live questions answered

# ===== Storage + retention =====
# - Encrypted at rest with per-engagement keys
# - Access logs for who viewed the report
# - Deletion or transfer to client per the RoE
# - No raw artefacts cached in personal cloud drives

# ===== After delivery =====
# - Verification round: confirm fixes work
# - Schedule a retest window
# - Update the engagement closure document
# - Capture lessons (was scope too narrow? alerts noisy?) for next RoE

# ===== Patterns to internalise =====
# - Write report headers FIRST; that exposes scope gaps early
# - Severity with vector + reasoning, never just a number
# - Every finding pairs with detection + hardening
# - Reproduction in the lab; do not exploit prod outside RoE

# ===== Pitfalls =====
# - Sharing findings publicly without client approval
# - Leaving raw artefacts on personal devices
# - Skipping verification steps -> clients fix the symptom, not the cause
# - 'Critical' findings without compensating context -> alert fatigue

# A useful finding contains:
#   - Title + CVSS + risk
#   - Affected asset(s) and scope context
#   - Reproduction steps (so a dev can verify locally)
#   - Evidence (screenshots, request/response — redact secrets)
#   - Impact in plain language
#   - Remediation suggestion + standards refs (OWASP / CWE)