TLP:AMBER, a Non-Member Partner, and a Journalist's Question

First confirm which TLP version and marking apply, because AMBER and AMBER+STRICT differ in whether sharing outside the recipient organisation is allowed. Under the ISAC agreement, the default is need-to-know within the bank. The non-member fintech partner cannot receive the full TLP:AMBER report without the originator's permission. A derived subset may be shareable only if the originator declassifies it and it contains no customer personal data; the screenshot must not be forwarded. The MSSP is a contracted processor with a need to know, but the bank must verify that the MSSP agreement includes TLP handling, access control, and breach notification; placing the full report in a ticketing system may be acceptable only if access is restricted to the bank's dedicated team.

Law enforcement can generally receive the indicators, but follow the ISAC's rules and legal advice, and ask the originator if the marking requires it. The journalist should receive no confidential report, no screenshot, and no customer details; a general comment or a sanitised advisory may be prepared with communications and legal. Document each decision, the legal basis, and the marking. When in doubt, ask the originator rather than assume.

Build a derived package rather than forwarding the original. Use STIX 2.1 objects in a bundle and, if the partner can consume it, TAXII for transport. Include the domains and IPs with context: first-seen, last-seen, confidence, role (phishing kit hosting versus credential exfiltration), and a handling caveat. Remove customer names, account data, the credential-harvesting screenshot, internal ticket numbers, and any attribution or victim information that is not necessary for blocking. If the originator authorises external sharing, re-mark the subset at the appropriate TLP - likely TLP:CLEAR or TLP:GREEN - and state that it is a derivative work with a source reference.

Add a feedback request: ask the partner to confirm blocks, detections, and false positives. Do not send a bare list of indicators by email; that loses context and cannot be governed. Include an expiry date and a contact for questions. If authorisation is not granted, offer a verbal or high-level warning without the indicators, or ask the ISAC to broker the sharing. The package should be the minimum information needed for the partner to protect itself, not the maximum the bank possesses.

Track the package through its lifecycle: acknowledgement of receipt, confirmation that controls were applied, confirmed blocks or detections, false positives, and time from sharing to protection. Record these against the ISAC report and send a sanitised confirmation back to the originator and ISAC, as the sharing agreement requires. Measure value with a small set of indicators: number of confirmed protective actions, unique detections enabled, reduction in time-to-block, and number of reciprocal reports received. Avoid counting emails sent or indicators distributed; those measure activity, not outcomes.

After 30 and 90 days, review whether the partner used the data and whether the MSSP's ticketing integration preserved the marking. If the partner cannot handle TLP markings, do not send sensitive packages; use a higher-level briefing instead. If law enforcement confirms action, record it only at the level permitted by the agreement. The feedback loop should also improve the bank's own collection: confirmed blocks tell the CTI team which sources produce actionable infrastructure, and false positives reveal context that was missing from the original report.