skip to content

Half your health-sector ISAC cannot consume a TAXII feed at all. How do you make sharing produce value?

level: principalimportance: nice to knowfreq 30%

answer

  1. publish twice, for two audiences
  2. put content where the controls are
  3. over-marking is the silent killer
  4. count actions taken, not objects published
  5. the smallest member sees it first

basics

~20 s

Publish on two tracks: machine-readable STIX for members with platforms, and a short note naming a few blockable values and one action for members without. Measure actions taken, not objects published, and keep default markings loose enough that members still submit.

solid answer

~40 s

Distribution has to match consumption. A 4,000-bed system with an intel team wants a TAXII collection or MISP feed into its own platform; a clinic with one IT manager wants a one-page note with five values, an explicit action and a named contact, plus the same content sent to whichever managed provider actually runs its mail filtering. Design that split deliberately rather than publishing once and blaming non-consumers. Then fix the two things that quietly kill communities: over-marking, where everything goes out TLP:RED so nothing can be used, countered with an AMBER or GREEN default and an anonymised submission route; and measuring output, where success is reported as objects published. Ask instead how many members blocked something. Accept asymmetric contribution: the clinic is often the sector's first sighting.

go deeper

for a junior

Understand that a sharing community's members have very unequal tooling, and that intelligence only counts when the receiving side can act on it. Recall what an ISAC is and who its members are.

for a middle

Be able to describe concretely what a member with no platform can consume: a short note with values and an explicit action, or a list their managed provider applies on their behalf.

for a senior

Show you would instrument the community's effect rather than its output, and that you would route content to whoever actually operates the control, including a member's outsourced provider.

for a principal

Own the tradeoffs: default markings against submission rates, enforcement against chilling effects, asymmetric contribution against member resentment, and a defensible answer to what the community has changed in a year.

## The problem is not the format A sector ISAC has members separated by two orders of magnitude in capability. One member has a threat-intel team, an OpenCTI instance and connectors; another has one IT manager who also owns printers, and whose mail security is operated by a regional managed provider. Publishing STIX over TAXII and declaring the job done means roughly half the community receives nothing usable, while the same half is the part of the sector an adversary reusing one phishing kit will actually land in. A business-email-compromise crew works a sector precisely because the small members share suppliers, billing intermediaries and staff with the large ones. ## Two tracks, published on purpose **Machine track.** A TAXII collection or MISP feed carrying properly modelled STIX: indicators with patterns and expiry, related to a malware or infrastructure object so the receiving analyst knows why the value is there, marked object by object. Members with platforms want relationships and stable ids so their own graph accumulates. **Human track.** A short note, in the format the recipient can act on today: what is happening in one paragraph, five or ten values worth blocking, the specific action ("block these sender domains; search consent grants for these application identifiers; enforce this setting"), and who to contact. Send it as mail, not as a portal login they will not use. Where a member is served by a managed provider, get the provider into the community as a member in their own right; that single move often does more for the small-member half than any format decision, because it puts the content where the controls actually are. A third track worth funding if the community can: a shared blocklist the small members' providers can subscribe to directly, so consumption requires no human at all. ## The two failure modes that kill communities quietly **Over-marking.** When the default handling is TLP:RED, nothing can be operationalised and the feed becomes theatre. Push the default to AMBER or GREEN, reserve RED for content that identifies a victim, and offer an **anonymised submission route** through the coordinator so a member can report being targeted without admitting it in their own name. The single largest brake on sector sharing is not tooling; it is that a member fears the submission becomes a disclosure story. **Measuring output instead of effect.** Object counts and feed volumes are the metrics that get reported and the ones that mean least. Better questions: how many members applied something in the last quarter; how long between a submission and the first other member confirming a sighting; did a small member's report give a large member early warning. A community that published 40,000 objects and changed nobody's controls has failed, and the metric will not say so. ## Asymmetric contribution is fine, and worth saying out loud Large members occasionally resent that small members mostly consume. Frame the exchange honestly: the sector's risk is shared through shared suppliers and shared staff mobility, so raising the weakest members' floor is the large member's own control. In return, the small members' submissions have a property the large ones' do not — they are often the first sighting, because they are hit first and have no filtering layer to absorb it. ## Enforcement without a chilling effect Communities do need consequences for handling violations, up to suspending an organisation's sharing privileges. The tension is real: heavy enforcement makes everyone over-mark and submit less, which is the same damage arriving by a different road. A workable balance is a documented process, proportionate first response focused on the mechanism that failed rather than the individual, and transparency to the membership about what happened — because the members' confidence depends on believing violations are handled, not on believing they never occur. ## What to say when asked to justify the spend The honest case is not "we ingested N indicators". It is that the community produced early warning a member acted on before the campaign reached them, and that the sector's smallest members — the ones with no detection capability of their own — received an action they could take. If neither of those is true after a year, the format was never the problem.

  • Members default everything they submit to TLP:RED. What do you change?
    Set the community default to AMBER or GREEN and require a reason for RED, then remove the incentive behind it: offer anonymised submission through the coordinator so a member can warn the sector without their name attached. Most over-marking is fear of disclosure, not genuine sensitivity, and until that fear is addressed a policy change alone just moves it to a different label.
  • How would you measure whether the community is worth its cost?
    Count actions, not artefacts: members who applied something in the quarter, time from a first submission to another member's confirming sighting, and cases where a submission preceded a member's own detection. Object volume, feed uptime and member headcount are all easy to report and all compatible with a community that changed nothing.
  • One member leaked a TLP:RED submission. Do you suspend their sharing privileges?
    Usually a proportionate first response beats suspension: require the mechanism that failed to be fixed, restrict them to receive-only if it was systemic, and tell the membership what happened. Heavy-handed enforcement teaches everyone to over-mark and submit less, which damages the community by the same route the leak did. Reserve suspension for repeated or wilful violations.

saying these in an interview costs you the question

  • Answers with a format choice when the problem is consumption
  • Treats members without platforms as non-participants
  • Reports object volume as evidence the community works
  • Leaves defaults at TLP:RED and wonders why nothing is used
  • Ignores the managed providers who actually operate the small members' controls

context