CTAS study materials
CTAS study resources

Sharing Malware Config Data Across a Health ISAC

CTAS · Put your knowledge to work in context.

All case studies

Sharing Malware Config Data Across a Health ISAC

A national health-sector ISAC with eight member organizations is handling a malware-configuration corpus seized during an incident response. The corpus contains 1,200 victim URLs, 300 plaintext credentials, and 40 internal hostnames. The sharing agreement marks the material TLP:AMBER, and the malware vendor's contract prohibits redistribution outside the ISAC. One member, based in the EU, asks for the full dataset for its SOC. A national law-enforcement agency sends an informal request for all credentials to support a criminal investigation. Separately, a researcher offers to sell a dark-web forum scrape containing 5,000 credential pairs from the same campaign. The ISAC's analyst wants to publish YARA rules and indicators to help members detect the malware. The board wants a decision before the next member call on Friday.

1. What can the ISAC share with the EU member, and under what conditions? Address TLP:AMBER and the vendor contract.

Read the worked answer

TLP:AMBER permits sharing within the defined community, but it does not override the vendor contract. The EU member is inside the ISAC, so TLP alone may allow sharing, but the contract prohibits redistribution outside the ISAC. The full corpus contains plaintext credentials and victim URLs, which are sensitive personal data and create legal risk under GDPR and breach-notification rules. I would not share the full dataset by default.

A defensible approach is to share a minimized detection package: YARA rules, hashes, sanitized network indicators, and handling caveats. Victim URLs and internal hostnames should be redacted or shared only on a need-to-know basis with a documented purpose. Credentials should not be shared at all unless there is a lawful basis and a secure process for notifying victims. The EU member should sign or confirm the existing data-processing and confidentiality terms, and the ISAC should obtain vendor permission before any redistribution that the contract restricts. If permission is refused, the ISAC can still share independently derived rules that do not reproduce the vendor's proprietary data. I would document the legal review and the minimization decision.

2. How should the ISAC respond to the law-enforcement request and the researcher's offer?

Read the worked answer

The law-enforcement request is informal, so I would not hand over credentials. I would route it to counsel, ask for a formal legal process, preserve the data, and provide only what is legally required. Credentials can expose victims and third parties; blanket disclosure may be disproportionate. I would seek clarification on scope, legal basis, and confidentiality, and document the chain of custody.

The researcher's offer raises provenance and ethics issues. Purchasing stolen credentials could create legal exposure, fund criminal activity, and violate the ISAC's policies. I would decline to purchase. If the researcher provides data free of charge with lawful provenance, I would assess whether it is necessary, minimize it, and avoid storing credentials unless there is a clear victim-notification or investigative purpose. I would also check whether the data was obtained through unauthorized access. The board should hear that the ISAC is not buying criminal data and is not informally disclosing victim secrets; it is following a documented legal and ethical process. That protects member trust and the ISAC's reputation.

3. What should the analyst publish to members to maximize detection value while respecting legal and ethical constraints?

Read the worked answer

I would publish a detection package rather than the raw corpus. It should include YARA rules for the malware family, file hashes, sanitized network indicators with confidence and expiration, and hunting guidance for the malware's behaviors. The package should carry TLP:AMBER, handling caveats, source provenance, and a clear statement that it excludes credentials and victim-identifying data. If victim URLs are needed for detection, I would provide patterns or hashed values rather than full URLs.

The analyst should also include a victim-notification note so members can check their own exposure without receiving other members' data. I would avoid publishing indicators that could cause false positives in clinical environments, and I would label confidence. Before release, counsel should review the package against the sharing agreement and the vendor contract. The board decision on Friday should be to release the minimized package to members, handle the EU request through the documented process, refer the law-enforcement request to counsel, and decline the purchase. That maximizes detection value while keeping the ISAC within legal and ethical bounds.