Why STIX 2.1 Bundles Matter for FIMI ISAC Sharing

Threat intelligence sharing across partner networks works best when everyone can ingest, interpret, and act on the data with minimal friction. STIX 2.1 is widely adopted for representing indicators, actors, malware, and observed activity in a structured way. Packaging that intelligence into a STIX Bundle makes it portable and consistent for downstream consumers.

For FIMI ISAC-style sharing, the goal is typically to provide:

• Actionable detection content (indicators, observed data, patterns)
• Context (what it relates to, why it matters, confidence)
• Clear handling guidance (markings, caveats, sharing restrictions)
• Predictable structure so partners can automate ingestion

This guide walks through creating and exporting a STIX 2.1 bundle that is well-formed, shareable, and friendly to partner tooling.

---

Before You Export: Define the Sharing Package

Start by deciding what you are shipping and what you are not. A good bundle is complete enough to act on but minimal enough to safely share.

Step 1: Choose the intelligence scope

Common package types:

• Indicator package: IOCs with patterns and validity windows
• Incident snapshot: observed activity plus context and supporting artifacts
• Campaign brief: higher-level narrative (campaign, actor, malware, TTPs) with limited IOCs
• Detection enrichment: supporting context around a set of detections (observed-data, sightings)

Step 2: Identify the minimum required context

For partner usefulness, include:

• What: indicator / malware / technique / event
• When: first seen, last seen, valid-from / valid-until
• Where: environment or sector context if shareable
• Confidence: your assessment of reliability
• Action: suggested response (block, monitor, hunt)

Step 3: Decide handling constraints early

If the data has restrictions, plan to apply:

• Object marking and/or granular marking (e.g., redact a specific field)
• Clear sharing caveats in descriptive text where appropriate

---

Core STIX 2.1 Objects You’ll Use Most

A bundle can contain many object types, but most sharing packages rely on a few staples.

• bundle: the export container
• identity: who created the intel (your org)
• marking-definition: handling restrictions
• indicator: patterns meant for detection
• observed-data: what you actually saw (with timestamps)
• sighting: “we observed this indicator/malware”
• malware / tool / threat-actor / campaign: context objects
• attack-pattern: tactics/techniques representation
• relationship: how objects connect
• note / report: human-readable narrative and grouping
• external-reference: internal tracking IDs or case references (avoid sensitive references)

Use report when you want to group a set of objects as a single shareable “package” with a narrative. Use note for clarifications or caveats that shouldn’t change the grouping.

---

Step-by-Step: Build a Share-Ready STIX 2.1 Bundle

Step 1: Create your producer identity

Include an identity object for the entity publishing the intel. This is key for attribution, trust, and follow-up.

Practical tips:

• Keep the name consistent across exports.
• Use stable identifiers if your tooling supports it.

Step 2: Apply markings and handling guidance

Create at least one marking-definition and apply it to all relevant objects via object_marking_refs.

Actionable approach:

• Default: mark everything in the bundle with the same handling label.
• Exceptions: use granular markings when a specific field needs tighter control.

Also consider adding a short handling statement in a note (e.g., what partners may do with the data, redistribution rules, and retention expectations), but avoid embedding sensitive policy text if it shouldn’t be broadly shared.

Step 3: Model the indicators (and keep them precise)

For each indicator, create an indicator object with:

• pattern: the detection expression
• pattern_type: typically stix
• valid_from (and optionally valid_until)
• confidence
• description: what it means, what systems it applies to

Keep patterns:

• Specific enough to reduce false positives
• Stable (avoid overly ephemeral values unless time-bounded)
• Compatible with partner tooling expectations

If you include multiple IOCs, consider grouping by purpose (e.g., command-and-control vs. delivery infrastructure) using labels or separate reports.

Step 4: Add observed evidence when appropriate

If you have direct observations, include observed-data. This is especially useful when partners want to understand how you observed something and whether it matches their telemetry.

Include:

• first_observed, last_observed
• number_observed
• Cyber observable objects relevant to the observation

Be careful not to overshare:

• Remove internal hostnames, user IDs, or proprietary paths unless explicitly allowed
• Prefer generalized observables when possible

Step 5: Connect objects with relationships

Relationships turn a collection into intelligence.

Common, practical relationships:

• Indicator indicates malware/tool/campaign
• Malware uses infrastructure (if modeled) or communicates-with (depending on your modeling)
• Observed-data related-to indicator (or use sightings)
• Threat-actor attributed-to campaign (when you have sufficient confidence)

Guidance:

• Use relationship confidence where your tooling supports it.
• Avoid over-asserting attribution. If unsure, relate via a softer construct (e.g., a note explaining hypotheses).

Step 6: Create a report to package the share

A report object is a clean way to bundle the story and references to included objects via object_refs.

A practical report should contain:

• A clear title (e.g., “Phishing Infrastructure and Payload Indicators – August 2026”)
• A summary: what happened, impact, recommended actions
• Time window and scope
• Key indicators and what to do with them
• Any important caveats

Step 7: Validate the bundle structure

Before exporting, ensure the bundle is consistent:

Checklist:

• Every object has a unique id and correct type
• spec_version is 2.1 on STIX objects where applicable
• Timestamps are valid and consistently formatted
• All references resolve (e.g., every ID in object_refs exists in the bundle)
• Markings are applied as intended
• Indicators include pattern_type, pattern, and a validity window

---

Export Hygiene: Make It Easy for Partners to Ingest

Keep the bundle small and purposeful

If you share too much at once, partners struggle to operationalize it. Prefer:

• Multiple focused bundles over one massive bundle
• Clear themes per bundle (one campaign, one incident, one cluster)

Use consistent labels and naming

Labels drive partner filtering and automation.

Examples of useful label categories:

• Confidence tier (low/medium/high) where appropriate
• Functional purpose (phishing, c2, malware-delivery)
• Operational action (block, monitor, hunt)

Avoid labels that leak sensitive internal details (team names, internal case codes) unless your sharing agreement supports it.

Include confidence and timeliness

Professionals will prioritize what you mark as confident and current.

Practical defaults:

• Provide valid_until for short-lived infrastructure indicators.
• Set clear confidence levels and update bundles when confidence changes.

Redact and minimize sensitive fields

If the intelligence came from sensitive sources, strip identifying artifacts and consider replacing with:

• Aggregated or normalized values
• Higher-level descriptions in notes
• Limited observables that remain actionable without exposing sources

---

Common Pitfalls (and How to Avoid Them)

• Broken references: A report references objects not included in the bundle
  Fix: validate object IDs and ensure all referenced objects are present.

• Overbroad indicators: Patterns that match benign traffic
  Fix: scope patterns, add qualifiers, and time-bound where necessary.

• Missing markings: Partners don’t know how to handle or redistribute
  Fix: apply markings consistently and add a handling note.

• Attribution overreach: Strong claims with weak evidence
  Fix: express uncertainty via confidence and narrative notes; relate cautiously.

• Unhelpful descriptions: Indicators without “what to do”
  Fix: add response guidance and detection context in descriptions or the report.

---

Final Pre-Share Checklist

Use this quick checklist right before distribution:

• Bundle includes: identity, marking-definition, report, and the relevant intel objects
• All objects are marked appropriately and consistently
• Indicators have: pattern, pattern_type, valid_from, and (when needed) valid_until
• Relationships connect indicators to context objects where defensible
• Observed-data is sanitized and time-scoped
• Narrative report explains context, impact, recommended actions, and caveats
• Validation confirms IDs, references, timestamps, and STIX 2.1 compliance

A well-formed STIX 2.1 bundle is not just syntactically correct—it is operationally useful, safe to share, and easy to automate across partner networks.