# Source Threat Modeling

> Threat-model-first detection planning for data sources without OOTB coverage. Analyzes what threats apply to a source type, validates against live log data, and produces a prioritized detection backlog with handoff docs for authoring skills. Use when onboarding a new data source, planning detection coverage for a source without OOTB templates, or assessing what threats a source can detect.

- Skill: `willwebster5/source-threat-modeling` (Agent Skill)
- Install (CLI): `npx skillmds@latest add willwebster5/source-threat-modeling`
- Raw SKILL.md: https://api.skillmd.com/api/skills/willwebster5/source-threat-modeling/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: willwebster5 (https://skillmd.com/u/willwebster5)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/willwebster5/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?

| Source Role | Example Threats |
|---|---|
| Identity provider | Credential stuffing, MFA bypass, session hijacking, account takeover |
| Network perimeter | C2 communication, lateral movement, data exfiltration, port scanning |
| Cloud infrastructure | Resource abuse, privilege escalation, config tampering, data access |
| Application | Injection, unauthorized access, data theft, API abuse |
| Endpoint | Malware execution, LOLBins, persistence mechanisms, credential dumping |
| Email/collaboration | Phishing, BEC, forwarding rules, delegation abuse |

### 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:**

| Field | Description |
|---|---|
| Threat scenario | Plain-language description of the attack |
| MITRE technique | ATT&CK technique ID (e.g., T1621) |
| MITRE tactic | ATT&CK tactic (e.g., Credential Access) |
| Expected event types | What log events would reveal this activity |
| Expected severity | Critical / High / Medium / Low |

**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:

| Classification | Meaning | Action |
|---|---|---|
| **Detectable** | Required events exist, fields available, reasonable volume | Keep — proceed to backlog |
| **Partially detectable** | Some events present but missing key fields or context | Discuss with user — worth pursuing with limitations? |
| **Not detectable** | Required events don't exist in the data | Prune from backlog |
| **Surprising find** | Unexpected patterns worth investigating | Flag for user — potential quick win or live incident |

**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:

| Field | Description |
|---|---|
| **Priority** | 1 (highest) through N — based on severity + feasibility |
| **Threat scenario** | Plain-language description |
| **MITRE mapping** | Technique ID + tactic |
| **Detection approach** | `simple` (single event match), `threshold` (aggregation), `behavioral` (multi-event correlation) |
| **Complexity** | Low (single event) / Medium (aggregation/threshold) / High (multi-event correlation) |
| **Key event types** | From log validation |
| **Key fields** | From log validation |
| **Volume estimate** | Events/day from log validation |
| **Recommended skill** | Which authoring skill should build this |

### ADS Skeleton for Each Detection

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

```yaml
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

| Detection Approach | Route To | Why |
|---|---|---|
| Multi-event attack chains (deny-then-success, create-then-escalate) | `behavioral-detections` | Needs `correlate()` function |
| Threshold/aggregation rules (N events in T time) | `cql-patterns` | Pattern-based aggregation |
| Simple event matching or complex field logic | `logscale-security-queries` | General CQL development |

### 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:**

```markdown
# 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>` — <what it represents>

### 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
- <any source-specific constraints discovered during exploration>
- <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.