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.

Phase 2: Threat Modeling

Goal: Enumerate threats this source can observe, mapped to MITRE ATT&CK.

Work through three threat categories systematically:

Category A: Abuse of the monitored system

What can an attacker do through the system this source monitors?

Category B: Compromise of the source itself

What does it look like when the source system is the target?

• Admin account takeover on the source platform
• Audit log tampering or deletion
• Security configuration changes (weakened settings)
• API key or token compromise
• Integration or connector manipulation

Category C: Lateral movement and escalation

What cross-system activity is visible through this source?

• Privilege escalation (new admin grants, role changes)
• Cross-tenant or cross-account activity
• Service account abuse
• Access to new resources or scopes not previously seen

For each threat scenario, document:

Present the threat model to the user as a ranked table. Rank by severity and likelihood. Discuss and refine before proceeding to log validation.

STOP — Get user approval on the threat model before querying live data.

Phase 3: Log Validation

Goal: Confirm which threats from Phase 2 are actually detectable in the live data.

For each threat scenario, run exploratory CQL queries using mcp__crowdstrike__ngsiem_query:

Step 1: Event type discovery

Map what the source actually emits:

<scope_filter>
| groupBy([event.type, event.action, event.category], limit=50)

Step 2: Per-scenario validation

For each threat scenario from Phase 2:

a) Do the required event types exist?

<scope_filter> event.type="<expected_type>"
| count()

b) What's the volume? (informs threshold decisions)

<scope_filter> event.type="<expected_type>"
| bucket(span=1d)
| count()

c) What fields are available? (informs detection logic)

<scope_filter> event.type="<expected_type>"
| head(10)

d) What does "normal" look like? (informs baselines)

<scope_filter> event.type="<expected_type>"
| groupBy([<key_field>], function=count())
| sort(_count, order=desc)
| head(20)

Step 3: Feasibility classification

For each threat scenario, classify:

Present results. For each scenario, show: classification, event types found, key fields available, daily volume estimate, and any surprising observations.

STOP — Discuss findings with user. Prune not-detectable scenarios. Decide on partial detections.

Phase 4: Detection Backlog & Handoff

Goal: Produce a prioritized detection backlog and hand off selected detections to authoring skills.

Build the backlog

For each validated threat scenario, create a backlog entry:

ADS Skeleton for Each Detection

For each detection in the backlog, generate a skeleton ads: block to include in the handoff document:

ads:
  goal: "<derived from the threat model's attack description>"
  mitre_attack:
    - "<from the MITRE mapping in the threat model>"
  blind_spots:
    - "TBD — populate after first triage"
  validation:
    - "TBD — populate after first triage"
  ads_created: "YYYY-MM-DD"
  ads_author: "source-threat-modeling"

Include this skeleton in each handoff document under a ### ADS Metadata section, after the Context table and before the Key Event Types section.

Skill routing

Present the backlog

Show the full backlog as a prioritized table. User selects which detections to pursue.

Generate handoff documents

For each selected detection, write a handoff doc to docs/handoffs/.

Filename: YYYY-MM-DD-threat-model-to-<target-skill>-<brief-description>.md

Template:

# Handoff: Source Threat Modeling → <Target Skill>

## Objective

Author a detection for: <threat scenario one-liner>

## Source

- **Produced by:** source-threat-modeling skill
- **Date:** <today>
- **Target skill:** <behavioral-detections | cql-patterns | logscale-security-queries>

## Context

| Field | Value |
|---|---|
| Data source | <source name> |
| CQL scope filter | `<filter>` |
| Source role | <identity / network / cloud / app / endpoint> |
| Threat scenario | <description> |
| MITRE technique | <ID> — <name> |
| MITRE tactic | <tactic> |
| Detection approach | <simple / threshold / behavioral> |
| Estimated severity | <Critical / High / Medium / Low> |

### ADS Metadata

Include in the detection template's `ads:` block:

```yaml
ads:
  goal: "<one-sentence detection goal from threat scenario>"
  mitre_attack:
    - "<Tactic / Technique (ID)>"
  blind_spots:
    - "TBD — populate after first triage"
  validation:
    - "TBD — populate after first triage"
  ads_created: "<today>"
  ads_author: "source-threat-modeling"

Key Event Types

• <event.type> —

Key Fields

• <field> — <what it contains, example values>

Volume Notes

<daily volume estimate and baseline observations from Phase 3>

Decisions Made

These have been reviewed and approved by the user. The receiving skill should NOT re-ask:

• <decision 1>
• <decision 2>

Constraints

• 120s NGSIEM query timeout — keep correlation windows reasonable
• <relevant enrichment functions from detection-tuning, if applicable>

Artifacts

• <paths to any files created during this session, or "None">

**Tell the user:** "Handoff doc written to `<path>`. Invoke the `<target-skill>` skill and point it at this file to begin authoring."

---

## Reference: Common Source Types

| Source Category | Examples | Typical Threat Focus |
|---|---|---|
| Identity Provider | Okta, EntraID, Ping, Auth0 | Credential attacks, MFA bypass, admin takeover, privilege escalation |
| Cloud Infrastructure | AWS CloudTrail, GCP Audit, Azure Activity | Resource abuse, IAM escalation, config tampering, data access |
| Network Security | Cisco ASA, Palo Alto, Zscaler, Akamai | C2 comms, lateral movement, exfiltration, scanning |
| Source Code / DevOps | GitHub, GitLab, Bitbucket | Code theft, secret exposure, pipeline compromise, access changes |
| SaaS Applications | Salesforce, Workday, ServiceNow | Data exfiltration, privilege abuse, config changes |
| Endpoint | CrowdStrike EDR, Carbon Black, SentinelOne | Malware, LOLBins, persistence, credential dumping |
| Email / Collaboration | M365, Google Workspace | Phishing, BEC, forwarding rules, delegation abuse |

This table is a starting point for Phase 2 — reason about threats specific to the actual product, not just the category.