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)

```

1. 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:

| 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?

 event.type=""
| count()

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

 event.type=""
| bucket(span=1d)
| count()

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

 event.type=""
| head(10)

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

 event.type=""
| groupBy([], 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:

ads:
  goal: ""
  mitre_attack:
    - ""
  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--.md

Template:

# Handoff: Source Threat Modeling → 

## Objective

Author a detection for: 

## Source

- **Produced by:** source-threat-modeling skill
- **Date:** 
- **Target skill:** 

## Context

| Field | Value |
|---|---|
| Data source |  |
| CQL scope filter | `` |
| Source role |  |
| Threat scenario |  |
| MITRE technique |  —  |
| MITRE tactic |  |
| Detection approach |  |
| Estimated severity |  |

### ADS Metadata

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

```yaml
ads:
  goal: ""
  mitre_attack:
    - ""
  blind_spots:
    - "TBD — populate after first triage"
  validation:
    - "TBD — populate after first triage"
  ads_created: ""
  ads_author: "source-threat-modeling"

Key Event Types

• `` —

Key Fields

• `` —

Volume Notes

Decisions Made

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

Constraints

• 120s NGSIEM query timeout — keep correlation windows reasonable

Artifacts

**Tell the user:** "Handoff doc written to ``. Invoke the `` 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.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [willwebster5](https://github.com/willwebster5)
- **Source:** [willwebster5/agent-skills](https://github.com/willwebster5/agent-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.