Floodlight

Full description

Floodlight builds an initial security-visibility posture from three quick inputs — company name, industry and region, and the shape of the environment. The output is an ATT&CK Tactic Coverage map: tactic by tactic, where you can see an attacker and where you're blind, weighted by what adversaries actually use and grounded in DeTT&CT, the CTID Top ATT&CK Techniques, and MITRE ATT&CK v18. The thesis is simple — the first step to security is visibility — so Floodlight builds the visibility plan first. It runs disconnected: no MCP server, no data leaves the room. Trigger phrases: "floodlight", "run floodlight", "build my security posture", "where am I blind", "visibility assessment", "security visibility map", "what should I be logging".

Why "Floodlight"

You can't lift in the dark, and you can't defend what you can't see. A floodlight doesn't catch the intruder for you — it removes the place they were counting on to hide. That's the whole posture in one image: before you buy another tool or write another detection, you flood light across the room and find out which corners are already lit and which are black.

Floodlight is a starting overview, not a CISO. It does not grade your program, benchmark you against peers, or claim to know what targets your specific company. It shows you, honestly, where your telemetry would let you watch an attacker move — and where it wouldn't — so the next dollar and the next hour go to the darkest corner first.

What this is NOT

State this plainly if the user expects more. Floodlight does not:

• Replace a CISO, a detection-engineering program, or a real risk assessment.
• Benchmark the org against peers or assign a maturity grade. (Guessing a benchmark wrong is worse than omitting it.)
• Claim confident attribution — "APT-X is targeting you." It reasons from sector and region ("organizations like yours are most often hit by…"), not named certainty.
• Audit the live environment. It works from what the user tells it plus public research. Everything it assumes is shown, labeled, and editable.

The honesty is the product. A modest, correct map beats a confident, wrong one.

INTAKE Mode (Step 0 — run once)

Keep this short. Fewer questions means more people finish. Three inputs, that's it. Infer what you can and let the user correct with one tap.

1. Company name. Required. From the name alone, infer the likely industry and region and say so — don't make them type it.
2. Industry & region — confirm the inference. "Looks like fintech, US — right?" One-tap correct. This sets sector-based adversary research and applicable regulations.
3. Environment shape. Cloud-first / hybrid / on-prem, plus two yes/no gates:
   • Run OT/ICS? (gates whether you note ATT&CK for ICS as out of scope.)
   • Build or deploy AI/ML? (gates whether you note MITRE ATLAS as adjacent.)

Design principle — context vs. current state. Intake questions set context: what an org of this shape should be able to see. They do not ask "what do you have today?" item by item — that's captured in the report, where the user toggles each log source on or off and the map recolors live. Don't drag current-state interrogation into intake.

What NOT to ask: report format or length (fixed), framework choice (fixed — ATT&CK v18 + the bundled catalog), or a tool inventory (that's the in-report toggles). Never ask more than two clarifying questions in one turn.

After collecting the three: confirm in one line and move to Research.

The two layers — baked vs. live

Trust is make-or-break for this skill, so the two halves of the data are sourced differently and must never be confused.

Baked framework layer — floodlight-catalog.json (do not invent). Tactics, choke points, log sources, the specific fields and event types each source provides, retention-by-regulation, and the technique→source mappings are a curated, version-stamped catalog. Read floodlight-catalog.json from this folder and use its IDs verbatim. Never invent an event ID, field name, technique ID, or retention figure — if it isn't in the catalog, leave it out. This is what keeps the report from hallucinating a plausible-sounding-but-wrong detection.

Live company layer — researched at runtime and cited. Sector/region adversaries, verified public breaches, and applicable regulations are gathered live and attributed. You assemble this into FLOODLIGHT_DATA (schema below). No uncited breach claims, ever.

RESEARCH Phase (Step 1)

Before searching, output one line in chat: "🔦 Mapping the threat landscape for [Company] — [industry], [region]. One minute."

Run these batches concurrently. Replace [SECTOR], [REGION], [COMPANY], and use [DATE] = 18 months prior to today for breach recency.

Map each adversary's techniques to catalog technique IDs. When research says a group leans on phishing, valid-account abuse, or AiTM token theft, find the matching T#### IDs in floodlight-catalog.json and put those IDs in adversaries[].techniques. The renderer uses them to boost the weighting on tactics those adversaries actually hit. If you can't map a described behavior to a catalog technique, drop it rather than invent an ID.

Attribution humility. Prefer "organizations in [sector] are most frequently hit by [group/behavior]" over "[group] is attacking you." Rank adversaries 1–5 by relevance to the sector/region, not by certainty about this one company.

Regulations must be the catalog's IDs only — currently: pci, hipaa, m2131 (federal only — don't apply to private orgs), nerc, soc2, gdpr. Include only what plausibly applies to this org's sector/region. Name the detection-vs-data-minimization tension when gdpr is included.

FLOODLIGHT_DATA schema

Build this object during synthesis. Only the company-specific layer lives here — the framework comes from the catalog. Every field optional unless marked required; the renderer degrades gracefully on anything omitted. Rich-text tokens **bold** and _italic_ are supported in deck, adversaryDeck, why, otherPriorities[].body, and assumptions[].

{
  "meta": {
    "company":   "Northwind Mutual",          // required
    "industry":  "Regional insurance",         // required
    "region":    "US (Midwest)",               // required
    "deck":      "A visibility-first read of where Northwind can watch an attacker move — and where the room is dark.",
    "subtitle":  "Hybrid · no OT · deploys ML underwriting",   // optional eyebrow line
    "generated": "13 Jun 2026"                 // date only, from system context
  },

  "applicableSources": [
    "cloud_signin", "identity_audit", "process_creation", "powershell_logs",
    "windows_auth", "email_security", "network_flow", "dns_query", "edr_endpoint"
  ],
  // OPTIONAL. Log-source IDs (from the catalog) that this org *should* have given its
  // shape. Omit to default to every crown-jewel source. Trim on-prem-only sources for a
  // cloud-first shop; keep the identity/cloud/email core for everyone.

  "currentState": {
    "enabledSources": ["cloud_signin", "email_security", "edr_endpoint"]
    // What they say they have TODAY. Default to a conservative few or empty — the user
    // toggles the rest up in the report and the map recolors live.
  },

  "adversaryDeck": "Mid-market insurers are squarely in the eCrime ransomware lane, with identity-first intrusions leading.",

  "adversaries": [
    {
      "rank": 1,                                // 1 = most relevant to this sector/region
      "name": "Ransomware affiliates (eCrime)",
      "motivation": "Financial",
      "why": "Insurance carriers hold dense PII and pay to restore operations — a top eCrime target in 2025–26.",
      "techniques": ["T1566", "T1078.004", "T1539", "T1486"],   // catalog technique IDs
      "citation": "Red Canary Threat Detection Report 2025",
      "citationUrl": "https://redcanary.com/threat-detection-report/"
    }
  ],

  "otherPriorities": [
    { "title": "Recent sector incident", "body": "A peer carrier disclosed a ransomware event in Q1 2026 — **identity** was the entry point." }
  ],

  "regulations": ["pci", "hipaa", "gdpr"],      // catalog IDs only

  "assumptions": [
    "Hybrid environment, cloud-first identity (Entra/Okta). No OT/ICS.",
    "Deploys ML for underwriting — ATLAS is adjacent but out of scope for this map.",
    "No verified public breach found for Northwind itself; sector data used as proxy."
  ]
}

Field reference

Assumptions are not optional in spirit. Every guess you made — environment shape, proxy data, scope calls — goes in assumptions[]. They drive the analysis and the user corrects them and re-runs. Showing your work is how a disconnected skill earns trust.

RENDER Phase (Step 2)

Every Floodlight posture is built locally from the bundled floodlight-template.html and floodlight-catalog.json. No MCP server, no network call, no font tool. One path.

a) Write the assembled FLOODLIGHT_DATA object to a temp file as JSON:
      [workspace]/floodlight-data.json
   Write it with a file tool or heredoc. Do not escape anything yourself —
   the inject script handles </script> escaping.

b) Run the bundled injection script (note: FOUR arguments — data, catalog,
   template, output):
      python3 [skill_dir]/scripts/inject.py \
        floodlight-data.json \
        [skill_dir]/floodlight-catalog.json \
        [skill_dir]/floodlight-template.html \
        floodlight-posture.html
   The script validates both JSON inputs, escapes </script> sequences, and
   replaces __FLOODLIGHT_DATA__ and __FLOODLIGHT_CATALOG__. It prints
   "[inject] OK" on success and a specific error (invalid JSON / missing
   placeholder) on failure. Fix the data and re-run if it fails.

c) FALLBACK — no shell available (e.g. a chat-only environment):
   Do the same steps with file tools directly:
     1. Read [skill_dir]/floodlight-template.html and
        [skill_dir]/floodlight-catalog.json.
     2. In BOTH the data JSON and the catalog JSON, replace every "</script>"
        (case-insensitive) with "<\/script>".
     3. Replace the literal token __FLOODLIGHT_CATALOG__ with the escaped
        catalog JSON, and __FLOODLIGHT_DATA__ with the escaped data JSON.
        Literal string swaps — do not use regex replacement, and do not alter
        any other template content.
     4. Write the result to floodlight-posture.html.

d) Surface floodlight-posture.html to the user with the environment's file
   presentation mechanism. The file is fully self-contained: open it in any
   browser, toggle sources on the page, export to HTML or print to PDF. Fonts
   load from the Google Fonts CDN when reachable and fall back to system fonts
   on locked-down networks.

Summary line

After rendering, output one summary line in chat:

"[N] tactics mapped · [N] choke points · [N] dark / [N] partial / [N] lit · top gap: [tactic]"

Then one sentence: the single darkest, highest-leverage corner — the red choke-point tactic the user should close first. Nothing else in chat. The posture is the artifact; don't duplicate it.

Editorial rules

• Visibility first, always. The recommendation is what to see, not what to buy. Never name a vendor product as the answer.
• No invented framework facts. Event IDs, fields, technique IDs, retention figures — catalog or nothing.
• No uncited live claims. Every breach, adversary, or regulation assertion carries a source. Sector proxies are labeled as proxies in assumptions[].
• No benchmarking, no maturity grade. State where they can and can't see. Don't score them against an invented peer set.
• Attribution humility. Sector/region targeting language, not confident named attribution.
• Choke points lead. When ranking what to fix, a red cell that is also a choke point outranks a red cell that isn't — catch them where they can't avoid you.
• Assumptions are visible and editable. Surface every inference; invite correction.
• Redundancy over single-source coverage. A tactic covered by one log source that EDR-killers or log-clearing can destroy is partial, not done. The weighting already rewards depth — your prose should too.

Version history