You forwarded a member's TLP:RED submission to a vendor. What does TLP:RED forbid, and what now?

## What the designations actually mean The Traffic Light Protocol is a set of handling designations applied by the **originator**. The current version defines five: - **TLP:RED** — not for disclosure outside the specific exchange, meeting or conversation in which it was disclosed. Not organisation-wide. If three people were on the call, three people have it. - **TLP:AMBER** — may be shared with the recipient's organisation *and its clients* on a need-to-know basis to protect them. - **TLP:AMBER+STRICT** — the same, minus the clients: the recipient's organisation only. - **TLP:GREEN** — may be shared within the community and with partner organisations, but not through publicly accessible channels. - **TLP:CLEAR** — no restrictions on disclosure. Two properties matter more than the colour names. First, **only the originator can change the marking**. A recipient who decides that something "is really only AMBER" has broken the protocol regardless of how sensible the judgement was. Second, **TLP is a social control, not a technical one**. Nothing in a STIX bundle, a MISP instance or a TAXII collection prevents a copy; markings ride along as metadata and are honoured because the community agrees to honour them. That is exactly why breaching one is expensive: what you spent is the willingness of members to submit. ## Why this particular breach hurts a sharing community Members submit under TLP:RED precisely when the content would embarrass or endanger them: they are being actively targeted, the submission implies they were successfully phished, or the detail would identify a victim. A crew reusing one phishing kit across a whole sector, with an OAuth mail-read grant to a look-alike third-party application as its persistence, is exactly this shape — the useful detail (the consent-app identifier, the sending patterns, the reply-to conventions) is also the detail that says who was hit. When a RED submission leaks, the member does not usually complain loudly. They quietly stop submitting, and so do the members they talk to. The community's content thins out over a quarter and nobody can point at a cause. That is the actual failure mode, and it is why the response is a trust-repair exercise rather than a data-recovery one. ## What to do, in order 1. **Stop the spread.** Recall the mail where the platform supports it, and remove the object from your own instance. Note that in STIX you do not really delete: the convention is to publish a new version with `revoked` set true, and any consumer who already pulled the object still holds their copy. A TAXII server may support removing an object from a collection, but that never reaches what has already been polled. Assume the copy is permanent and plan around that rather than pretending it is gone. 2. **Contain at the vendor.** Ask, in writing, for deletion and for confirmation of who inside the vendor saw it. You want a named list, because the originator will ask. 3. **Tell the originator first, and yourself.** Before the coordinator, before your own leadership's messaging goes out, before the vendor mentions it. Say what was sent, to whom, when, what you have asked for, and what you are changing. A member who hears it from you keeps a relationship; a member who discovers it does not. 4. **Tell the community coordinator.** Sharing communities generally have a documented process for handling violations, and using it beats being subject to it. 5. **Negotiate a legitimate route if the need was real.** If the vendor genuinely needed the content to build coverage, ask the originator to re-release it — usually as TLP:AMBER+STRICT so it is confined to your organisation, or as a derived product that carries the *behaviour* without the victim-identifying detail. Sharing the technique with none of the attribution is very often enough for a vendor to act, and originators say yes to it far more readily. 6. **Fix the mechanism, not the person.** Most of these are process failures: an analyst forwards a case that contains a pasted RED extract, an automation exports a whole MISP event to a vendor connector, or a distribution level was set to a sharing group by default. Enforce marking at the point of export: block connector pushes for objects above a marking threshold, keep RED material out of the case system entirely, and make the mark visible in the mail subject rather than only in a footer. ## Consequences you should expect and accept A community can suspend an organisation's sharing privileges, downgrade it to receive-only, or remove it. Arguing that the leak was harmless is the wrong move, because the harm was never about the bytes. The right posture is to name the mechanism that allowed it, show the control you added, and let the community decide. ## Common wrong answers - "TLP:RED means internal use only." That is closer to AMBER+STRICT. - "We re-marked it AMBER before forwarding." Recipients cannot re-mark. - "The platform should have blocked it." Nothing enforces TLP by default; that is the control you are adding now, not a defence. - "We deleted it, so it is contained." Deletion does not reach copies already pulled or read.