Sharing what you find: STIX, TAXII, Sigma, YARA and Snort

Why this matters

CompTIA name five formats in this objective, and the reason they are examinable is the same reason SCAP was in lesson thirty-one: without shared representations, intelligence cannot move between organisations or between tools. A detection written in one platform's query language is useful to whoever runs that platform and nobody else.

The material divides cleanly. STIX and TAXII are how threat information is described and transported between organisations. Sigma, YARA and Snort are how detections are expressed — for logs, for files, and for network traffic respectively. Knowing which format addresses which layer is most of what the exam asks.

The lesson also covers the part that is judgement rather than syntax: what you must remove before intelligence leaves your organisation, and why an indicator's shelf life determines how much it is worth sharing at all.

The lesson

Indicators versus behaviours, and the shelf life of each

The most useful idea in this objective, because it determines what is worth collecting, sharing and detecting on.

Indicators are specific observable artefacts: a file hash, an IP address, a domain, a URL, a registry key, a certificate. They are precise, easy to match, and produce high-confidence detections when they hit.

Behaviours are what an attacker does: the technique, the sequence, the pattern of activity. They are harder to express and harder to match, and they survive changes in infrastructure and tooling.

The difference is cost to the attacker, and it is usually drawn as a hierarchy. Changing a file hash costs nothing — recompile. Changing an address or a domain costs a little. Changing tooling costs more. Changing technique and tradecraft costs a great deal, because it requires the operator to work differently.

The consequences:

• Indicators expire quickly. An address used last month is probably no longer in use and may now be a legitimate service — which is why lesson forty-six insisted every indicator carries an expiry, and why blocking on stale indicators causes self-inflicted outages.
• Behavioural detections last. A rule matching the technique catches the next campaign using it, and the next tool implementing it.
• Indicators are still worth having, because they are cheap, immediate and high-confidence, and they are what lets you answer "were we affected by this" retrospectively in minutes.

The practical position: use indicators for rapid triage and retrospective search; invest detection engineering effort in behaviours. A programme whose detection strategy is entirely indicator feeds is permanently one recompile behind.

STIX as the structure and TAXII as the transport, with a worked exchange

STIX — Structured Threat Information Expression — is a language for describing threat intelligence. It is not a list of indicators; it is a graph of objects and the relationships between them.

The object types that matter: indicator (a pattern that detects something), malware, threat actor, attack pattern (which maps to ATT&CK techniques), campaign, intrusion set, observed data (what was actually seen), vulnerability, course of action (a response), and identity. Relationship objects connect them — this indicator indicates that malware, which is used by that actor, who targets this sector.

That structure is the advantage over a list. A flat indicator list tells you an address is bad. A STIX bundle tells you the address is command-and-control infrastructure for a named malware family used by an actor targeting your sector, with the techniques they use and a recommended response — which is enough to make a decision rather than only a block.

TAXII — Trusted Automated Exchange of Intelligence Information — is the transport protocol for moving STIX content. It defines servers with collections that clients poll or subscribe to, and channels for publish-subscribe distribution, with authentication and access control so that sharing can be restricted to a defined group.

A worked exchange, to make the two concrete. Your team investigates an intrusion and identifies a malicious binary, the domain it contacted, and the persistence technique used. You express that as STIX: an indicator for the file hash, an indicator for the domain, observed-data recording what you saw, an attack-pattern reference for the technique, and relationships tying them together — with confidence and a validity period on each indicator. You publish it to your sector organisation's TAXII collection. Their members' platforms poll that collection, ingest the bundle, distribute the indicators to their tools, and query their own history for matches. A peer discovers they were touched by the same infrastructure three weeks ago.

The distinction to hold: STIX is the language, TAXII is the delivery. They are used together and they are not the same thing, and that is the question this objective asks.

Sigma rules as vendor-neutral detection logic that ports between SIEMs

Sigma is a generic signature format for log-based detections. A rule describes, in YAML, the log source and the conditions that constitute a detection, independent of any particular SIEM's query language. A converter translates it into the target platform's syntax.

Why it matters: detection logic has historically been locked to a platform. A rule written in one product's language could not be shared with an organisation using another, and a migration meant rewriting every detection. Sigma makes detection logic portable, which means public repositories of community rules are usable by everyone, and it makes detections reviewable as text by people who do not know the target platform's syntax.

A Sigma rule carries more than logic: a title and description, the log source it applies to, the detection conditions, false positive notes recording what legitimately triggers it, a severity, and ATT&CK technique tags — which is what lets a rule set be mapped to the coverage map from lesson forty-two automatically.

The limits, and they are the practical ones:

• Conversion is imperfect. Platforms differ in field names, capability and performance, so a converted rule may need adjustment and may not be expressible at all.
• Field mapping is yours to supply. Sigma names a field; your platform has its own schema. This is lesson forty-one's normalisation work, and an estate without consistent normalisation cannot use community rules well.
• A rule that runs is not a rule that works. Community rules must be validated against your data and tuned, and importing a large rule set unvalidated produces the alert flood lesson forty-two warned about.

The professional use: treat community Sigma rules as a starting point and a coverage check — what does the community detect that we do not — rather than as a detection library to install wholesale.

YARA for file and memory identification, Snort for network signatures

Two more formats operating at different layers.

YARA describes patterns that identify files, by byte sequences, strings and conditions combining them. Rules are used by malware analysis tools, endpoint platforms, email security, and forensic tooling, and they run against files on disk, files in transit and process memory — which is the important one, since packed or encrypted malware is unrecognisable on disk and identifiable in memory once unpacked.

Its uses: identifying malware families rather than individual samples, classifying an unknown sample, hunting across an estate for files matching a family's characteristics, and triaging large collections. A well-written YARA rule matches a family's characteristic strings and structures rather than one sample's hash, which makes it a behavioural detection at the file level and gives it a much longer shelf life than a hash.

Snort rules describe network traffic patterns — protocol, direction, ports, payload content, and conditions — and are used by network intrusion detection and prevention systems. The format is widely supported beyond its origin, which makes it a de facto standard for network signatures.

Its limits are structural and worth stating because they determine where it still helps: encrypted traffic is opaque to payload inspection, which is most traffic now. Network signature detection has therefore shifted toward metadata — certificate characteristics, handshake fingerprints, timing and volume patterns, and DNS — rather than payload content. It remains valuable for unencrypted internal protocols, for DNS, and for the traffic you do terminate and inspect.

The three-format picture to carry into an exam: Sigma for logs, YARA for files and memory, Snort for network traffic. A scenario naming the layer names the format.

Publishing safely: what must be stripped before an indicator leaves the organisation

The judgement half of the objective, and it is the part that stops a sharing programme before it starts if it is not resolved.

What must not leave, and each has caused real problems:

• Internal addresses, hostnames and network structure. An indicator record frequently carries the internal host that saw it, which is reconnaissance about your estate.
• Usernames and personal data, including in file paths — a path under a user's profile directory contains a name.
• Your own infrastructure as indicators. Sharing an address that is actually yours, or a hash of a legitimate internal tool, causes peers to block or flag you.
• Business-sensitive context — which system, which customer, which project — and anything revealing a specific business impact.
• Material under legal constraint: an ongoing investigation, a regulatory process, a contractual confidentiality obligation.
• Detection capability detail, where revealing exactly how you detected something tells an adversary what to avoid. This is a genuine trade against the value of sharing the method.

The mechanisms that make it manageable:

• A sanitisation step in the sharing process, ideally automated for the mechanical parts — internal ranges, name patterns, path normalisation — with human review before publication.
• Traffic Light Protocol markings, which are the standard way of stating how far a piece of intelligence may be redistributed, and which most sharing communities enforce socially.
• Defined authority to share. Who may publish on behalf of the organisation, with legal and communications aware — the RACI from lesson three applied here.
• Share behaviours more freely than context. A technique and a detection approach can usually be shared with little risk; the specific incident narrative usually cannot.

The closing argument, because sharing is easy to decline and the cost of declining is invisible: the intelligence that is most useful to you came from someone who chose to publish it. A sector sharing arrangement in which everyone consumes and nobody contributes degrades to a commercial feed with extra meetings. Contributing sanitised indicators and behavioural detections from your own incidents is what keeps the arrangement worth belonging to — and it is also the artefact your own incident reviews produce anyway, which is the subject of the last two lessons.