Before
- Copy raw logs
- Mix facts and conclusions
- Share one report widely
- Lose correction history
Module 15 of 17
Reporting and Safe Intelligence Sharing
Communicate evidence, uncertainty, and toy observables with STIX 2.1 and TLP 2.0.
Start here
Learning objectives
- Write separate executive, technical, and engineering-remediation views of the same synthetic incident.
- Distinguish an observation, indicator, assessment, and attribution claim.
- Model harmless fictional observables in a minimal STIX 2.1 bundle.
- Distinguish native STIX 2.1 TLP marking definitions from FIRST Traffic Light Protocol 2.0 handling metadata.
- Remove secrets, personal data, customer data, and unsupported claims before sharing.
After
- Minimize and sanitize
- Label claim types
- Select audience and marking
- Track versions and corrections
One Incident, Different Decisions
An executive needs business impact, confidence, decisions, owners, and the next update time. A responder needs evidence identifiers, timeline, scope, collection gaps, and containment status. A developer needs the failed trust boundary, affected versions, remediation acceptance criteria, and how to prevent recurrence. Copying one dense report to every audience serves none of them.
Keep a common fact base and produce audience-specific views. State what happened, what is known, what is assessed, what remains unknown, and what decision is requested. Use exact times with zones and stable artifact identifiers. Avoid dramatic language and family attribution unsupported by evidence.
A good report remains useful after the incident. It allows a reviewer to trace each important claim to evidence, understand why an action was taken, and confirm whether follow-up controls were completed.
Observation Is Not Attribution
An observable is a technical fact such as a hash, fictional domain, file path category, signer identity, or event relationship. An indicator combines observations into a pattern that may support detection. An assessment interprets evidence with stated confidence. Attribution connects activity to an actor or source and requires much stronger evidence than a matching tool, string, or infrastructure pattern.
Use confidence language consistently. Explain the basis and the important alternatives. Avoid numeric precision unless the organization has a defined method for producing it. “Moderate confidence because two independent synthetic sources agree, with endpoint collection missing for one host” is more useful than an unexplained score.
Do not publish sensitive observables merely because they are technical. Internal hostnames, user identities, customer URLs, private repository paths, signing identifiers, and investigation links can expose systems and people.
STIX 2.1 as a Structured Exchange
Structured Threat Information Expression 2.1 defines objects and relationships for sharing cyber threat information. In this course, learners use only toy data: reserved TEST-NET addresses, .invalid domains, fictional identities, course-created hashes, and timestamps from the synthetic scenario. The bundle contains no live indicator and should never be imported into a production blocking system.
Model only what the receiver needs. Use stable object identifiers, valid timestamps, descriptions that preserve uncertainty, and relationships that are supported by the evidence. Validate the bundle against STIX 2.1 before sharing it. Keep the separate distribution decision visible rather than assuming that valid JSON, or even a conforming bundle, is necessarily a responsible intelligence package.
STIX improves structure; it does not create truth. The producer remains responsible for provenance, confidence, legal authority, privacy, marking, and correction. The consumer remains responsible for validation and local response policy.
STIX 2.1 and FIRST TLP 2.0 Are Not the Same Vocabulary
Native STIX 2.1 defines four predefined TLP marking-definition objects: TLP:WHITE, TLP:GREEN, TLP:AMBER, and TLP:RED. The STIX 2.1 specification requires producers to use those predefined instances and says that other TLP marking-definition instances must not be created. Those objects reflect the vocabulary available when STIX 2.1 was standardized.
FIRST Traffic Light Protocol 2.0 uses TLP:CLEAR, TLP:GREEN, TLP:AMBER, and TLP:RED, and adds TLP:AMBER+STRICT when distribution must remain within the recipient organization. TLP:CLEAR replaced the earlier TLP:WHITE label, but that does not make TLP:CLEAR or TLP:AMBER+STRICT a predefined native STIX 2.1 TLP marking-definition. Do not invent either value as a STIX 2.1 object with a definition_type of tlp.
For the course lab, validate the minimal STIX 2.1 bundle on its own and keep the FIRST TLP 2.0 decision as external handling metadata in the report manifest and sharing log. If an exchange community supports a documented STIX extension or information exchange policy, record the exact profile and recipient compatibility, then validate that representation separately from core STIX conformance. Never assume a receiving platform interprets a local extension.
TLP is not a data-classification system, a legal agreement, or permission to share information you do not have the right to disclose. The most restrictive marking does not repair an unauthorized disclosure. Confirm ownership, contracts, privacy requirements, regulatory obligations, and approved recipients first.
Track what was shared, by whom, under which marking, to which approved audience, and when corrections or revocations were issued. If a synthetic package is updated, provide a clear version and reason so receivers do not keep acting on superseded context.
Safe Publication Checklist
Before sharing, confirm that the package contains no credentials, tokens, personal data, customer data, confidential code, internal-only links, unnecessary raw logs, unsafe attachments, or live suspicious artifacts. Replace scenario identifiers with fictional values and keep a documented mapping only when an authorized internal workflow requires it.
Verify every observable, timestamp, hash, relationship, confidence statement, and TLP marking. State the intended defensive use and expiry or review date. Provide a correction channel. Moderate discussion spaces so users cannot upload samples or post active malicious links.
Suggested Study Plan (4 hours)
The published duration includes active practice, not video playback alone. Complete each block with the course-owned evidence and retain the stated deliverable so another reviewer can reproduce your reasoning.
| Study block | Time | Required evidence |
|---|---|---|
| Guided lesson and primary-source review | 36 minutes | Annotated notes that separate observations, hypotheses, limits, and version-sensitive facts. |
| Worked evidence walkthroughs | 30 minutes | Reproduce the lesson's tables or decision flow and challenge at least two assumptions. |
| Independent practice rounds | 30 minutes | Apply the method to two alternate records in the sanitized evidence pack and compare the conclusions. |
| Required lab | 2 hours | An executive update, technical report, separately validated STIX 2.1 toy bundle, external FIRST TLP 2.0 handling record, compatibility note, and sharing audit entry. |
| Knowledge check and review | 24 minutes | Answer the evidence check, review the rubric, and record one production follow-up. |
Evidence Check
Question: Can a team publish customer-related indicators under TLP:RED if only named recipients receive them?
Reveal the defensive reasoning
Not automatically. TLP describes distribution boundaries; it does not grant ownership, consent, contractual authority, or legal permission. The team must first confirm that sharing is authorized and necessary, minimize and sanitize the information, select approved recipients and channels, and then apply the correct TLP marking.
Primary References
Use these primary sources for the current standard or tool behavior. The course records framework versions so mappings can be reviewed when upstream guidance changes.
Real world
Where this shows up
- Briefing product leadership on impact and next decisions
- Handing evidence and remediation criteria to an application team
- Sharing sanitized toy observables in an authorized training community
- Maintaining a correction and version trail for distributed intelligence
Production notes
Keep these close
- Validate core STIX 2.1 syntax and semantics separately from any external FIRST TLP 2.0 handling record or documented extension profile.
- Use reserved example values in documentation and training; never invent a live-looking indicator.
- Apply access control and retention to reports, bundles, raw evidence, and recipient logs.
- Define who can approve external sharing, change a TLP marking, or issue a correction.
Common mistakes
What usually breaks
- Using a matching observable as proof of attribution
- Sending the same dense report to every audience
- Encoding TLP:CLEAR or TLP:AMBER+STRICT as a native STIX 2.1 TLP marking-definition
- Assuming TLP grants permission to disclose protected information
- Sharing unnecessary logs, identities, paths, links, or attachments
Security risks
Threats to watch
- Reports can expose customer data, employee data, internal architecture, or active investigations.
- Consumers can turn an unverified indicator into an inappropriate block.
- Incorrect marking can cause uncontrolled distribution or prevent necessary action.
- A sample-upload feature or unmoderated link field can become an unsafe distribution channel.
Tradeoffs
Design choices you should be able to defend
Rich raw evidence package
Pros
- Gives receivers more context
- Supports independent analysis
Cons
- Higher privacy and disclosure risk
- Harder to verify, minimize, and control
Minimal structured package
Pros
- Easier to validate and distribute safely
- Makes claim types and relationships explicit
Cons
- Can omit context a specialist needs
- Requires a correction and follow-up channel
Narrative report only
Pros
- Accessible to a broader audience
- Supports business explanation
Cons
- Harder to automate
- Observables and relationships may be ambiguous
Think like an engineer
Questions to answer before shipping
- What decision should this audience be able to make after reading the report?
- Which sentence is an assessment rather than a directly observed fact?
- Can the receiver verify the provenance and version of every shared observable?
- What information can be removed without reducing defensive value?
Key terms
Vocabulary used in this module
STIX 2.1
An OASIS standard for representing and exchanging structured cyber threat information.
TLP 2.0
The FIRST Traffic Light Protocol vocabulary for communicating information-sharing boundaries.
Observable
A directly observed technical fact such as a hash, address, domain, or file property.
Indicator
A pattern or analytic intended to identify activity of defensive interest.
Attribution
An assessment connecting activity to an actor or source, requiring evidence beyond a matching observable.
Exercises
Practice inside the lesson
Create a Sanitized STIX 2.1 Toy Intelligence Package
Produce audience-specific reports and a minimal validated STIX 2.1 bundle using only fictional observables, then document the separate FIRST TLP 2.0 handling decision.
- Confirm the fixture manifest: all identities are fictional, addresses use reserved documentation ranges, domains end in .invalid, and hashes identify course-created inert text.
- Separate the evidence cards into direct observations, indicators, assessments, unknowns, and unsupported attribution claims.
- Write a one-page executive update containing impact, confidence, decisions, owners, and next update time.
- Write a technical note with evidence IDs, timeline, collection gaps, containment status, and remediation acceptance criteria.
- Model only the required toy observables and relationships in a minimal STIX 2.1 bundle; preserve uncertainty in descriptions and confidence fields without inventing TLP 2.0 marking-definition objects.
- Validate core STIX 2.1 syntax and semantics offline, and record the validator version and result separately from the handling decision.
- Choose and justify FIRST TLP 2.0 handling for the classroom scenario in an external report manifest and sharing log; do not treat TLP as disclosure authority.
- Record recipient and tooling compatibility. If a documented extension or information exchange policy is proposed, name its profile and validate it separately from the core bundle.
- Run the sanitization checklist and record the approved audience, package version, review date, correction channel, and sharing log entry.
Expected evidence
An executive update, technical report, separately validated STIX 2.1 toy bundle, external FIRST TLP 2.0 handling record, compatibility note, and sharing audit entry.
Assessment criteria
- Each important claim is labeled as observation, indicator, assessment, unknown, or unsupported attribution.
- The executive and technical reports use the same facts while answering different audience needs.
- The STIX bundle contains only course-created fictional observables and valid evidence-supported relationships, and passes a separately recorded STIX 2.1 validation.
- The FIRST TLP 2.0 decision is external handling metadata; TLP:CLEAR and TLP:AMBER+STRICT are not created as native STIX 2.1 TLP marking-definition objects.
- Any proposed extension or information exchange policy names its profile, recipient compatibility, and separate validation result.
- The FIRST TLP 2.0 handling decision follows the official definitions and is not presented as legal authorization.
- Sanitization removes secrets, personal or customer data, unsafe artifacts, internal links, and unnecessary raw evidence.
Course-owned resources
Teardown
- Delete temporary validator output and working bundle copies.
- Retain only the sanitized validated bundle, reports, compatibility note, and fictional sharing record.
Recap
Key takeaways
- A shared fact base should support different executive, responder, and developer decisions.
- Observables, indicators, assessments, and attribution are different claim types.
- STIX 2.1 structures information but does not guarantee that the information is true or safe to share.
- Native STIX 2.1 TLP marking definitions do not directly represent FIRST TLP 2.0 CLEAR or AMBER+STRICT.
- TLP 2.0 describes distribution boundaries; it does not replace authorization, privacy, or legal review.
Related resources