source-threat-modeling

Source Threat Modeling

Turn a data source into detection coverage. This skill reasons about what threats are relevant to a source type, validates which are detectable in your actual log data, and produces a prioritized detection backlog. It does NOT write detections — it hands off to authoring skills (behavioral-detections, cql-patterns, logscale-security-queries) via handoff documents.

Orchestrator, not author. This skill decides what to detect. Existing skills decide how to write it.

When to Use This Skill

• A new data source is connected to NGSIEM and has no OOTB detection templates
• You want to assess detection coverage gaps for an existing source
• You need a structured threat model before building bespoke detections
• You're onboarding a source type you haven't worked with before

Handoff Input

This skill can be invoked directly or via a handoff document. If a handoff doc is provided, read it first and skip questions already answered.

---

Phase 1: Source Identification

Goal: Establish what source we're working with and how to query it.

Ask the user:

1. What product/vendor is the data source? (e.g., Okta, GitHub audit logs, Cisco ASA, Zscaler)
2. What log types are being ingested? (authentication, admin activity, network flow, API audit, etc.)
3. What is the NGSIEM scope filter?
   • e.g., #Vendor="okta", #repo="some_repo", #event.module="some_module"
   • If the user doesn't know, help discover it:

     * | groupBy([@repo, #Vendor, #event.module], limit=20)
     

4. What role does this source play in the environment? (identity provider, network perimeter, cloud infrastructure, application-level, endpoint, email/collaboration)

Check for existing coverage:

• Scan resources/detections/ for any rules already targeting this source
• Note what's covered so we don't duplicate

Output: A CQL scope filter and source profile that constrains all subsequent work.

STOP — Confirm the scope filter and source profile with the user before proceeding to threat modeling.