GitHub - spectrum-sec/delta-tradecraft · GitHub

/" data-turbo-transient="true" />

Skip to content

Type / to search

Sign in<br>Sign upAppearance settings

You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

{{ message }}

Uh oh!

There was an error while loading. Please reload this page.

spectrum-sec

delta-tradecraft

Public

Notifications<br>You must be signed in to change notification settings

Fork

Star

main

BranchesTags

Go to file

CodeOpen more actions menu

Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit

History<br>1 Commit<br>1 Commit

.github/workflows

.github/workflows

packs

packs

CODE_OF_CONDUCT.md

CODE_OF_CONDUCT.md

CONTRIBUTING.md

CONTRIBUTING.md

DELTA_TRADECRAFT_TEMPLATE.yaml

DELTA_TRADECRAFT_TEMPLATE.yaml

LICENSE

LICENSE

README.md

README.md

SCHEMA.md

SCHEMA.md

SECURITY.md

SECURITY.md

View all files

Repository files navigation

Delta Tradecraft

An open format for what a detection engineer needs to know before writing a detection.

A Tradecraft object is one vendor-independent YAML file about one adversary behavior: how the<br>behavior manifests in the attacked technology, where evidence of it can exist, what that evidence<br>can prove, and which detection strategies are viable. It sits above rule languages (Sigma, SPL,<br>KQL) and below or alongside ATT&CK. ATT&CK names a technique. A rule is one query for one<br>product in one estate. Everything between those two is the actual work, and this repository is<br>where it goes instead of an engineer's head or a dead wiki page.

Who it is for. Detection engineers deciding whether a behavior is worth a rule and what that<br>rule may honestly claim; agents generating detections that need grounding they cannot invent;<br>anyone who must say "we cover that" and be right.

The shape of an object

An object has thirteen blocks in this order. The first four say what the behavior is, the middle four<br>say how the attacked technology and the threat work, and the last five say what you can do<br>about it.

Block<br>Answers

identity<br>Which object is this, and what has it been called before

classification<br>What kind of behavior, on what attack surface

behavior<br>What the adversary does, in one sentence and then in full

manifestation<br>Is it possible , is it observable , is it detectable , and under what scope

attack_surface_context<br>How the attacked technology works, and where the trust boundary is

threat_research<br>Actor, campaign, victim, capability, framework mappings

visibility<br>Every telemetry source that could witness it, with what each can and cannot prove

detection<br>Strategies, logic, benign twins, blind spots, what an alert may conclude

detector_requirements<br>What a detector must be capable of, independent of product

missing_context<br>What is unverified, what is assumed, and which assumptions would change a verdict

missing_states<br>What to do when a required input is absent

alert_evidence_contract<br>What the alert must carry, and what it must not be titled

evidence<br>What the source establishes, what it does not, and the references

An object is complete when it explains six things: what the threat is doing, how it works, how the<br>behavior is observed, how the attacked technology works, the materially distinct ways it can be<br>detected, and the detector technologies each of those ways needs.

SCHEMA.md defines every field, its legal values, and common authoring mistakes.

What this format is for

A negative is a result. detectable: no is a legitimate, publishable conclusion, and an object<br>that reaches it carries the evidence for the negative rather than quietly omitting itself. Knowing a<br>behavior cannot be seen is worth more than a rule that creates the appearance of coverage.

Each strategy states its minimum evidence and the strongest conclusion that evidence supports.<br>alert_evidence_contract.unsupported_title names the headline the alert must never carry. A blocked<br>request must be described as a blocked attempt. It cannot be reported as a successful fetch.

Attribute each field and each inferred claim in prose. Every telemetry field records the event<br>vocabulary, the tier at which it is emitted, and whether a vendor schema attests it or the author<br>inferred it. That distinction usually decides whether a behavior is detectable at all.

Omitting validation means the strategy was not exercised. Nothing in the format lets an object<br>imply it was tested when it was not, and nothing gates publication on a lab result. An unvalidated<br>strategy is publishable. So is a withdrawn one: validation.status carries validation-withdrawn<br>for exactly that. Both have to say which they are. Expect objects in this repository whose strategies<br>have never been executed anywhere. Every pack states its own validation position at the top of its<br>README. Read that before you quote...