Interview question
You receive TLP:RED intelligence in a trust group indicating a specific vulnerability is being exploited against your sector. Your organisation is exposed. What do you do?
A handling scenario with a deliberate conflict between an obligation and an urgent need to act. Inventing permission is the failure mode.
What a strong answer covers
- States the TLP:RED restriction correctly — limited to the individuals present in the specific exchange, no onward sharing.
- Recognises the genuine conflict between the handling obligation and the duty to protect the organisation.
- Does not reason its way into an exception unilaterally.
- Goes back to the originator to request permission to act or a downgraded version — the correct first move.
- Considers whether action can be taken without revealing the source, e.g. patching as part of routine work.
- Notes that a detection or block visible to the adversary could itself disclose the intelligence.
- Recognises that breaching TLP ends sharing relationships permanently and costs future intelligence.
- Escalates internally through the right people if the originator cannot be reached in time.
- Notes TLP is a trust agreement, not a technical control.
Expert answer
TLP:RED means the information stays with the individuals in that specific exchange. Not my team, not my manager, not my organisation — the people in the room. So on the face of it I cannot even tell my own patching team.
That is a real conflict, and pretending it is not is the wrong start. I have an obligation to the sharing community and a duty to protect my organisation, and they point in opposite directions here.
The correct first move is to go back to the originator, quickly, and ask. Specifically: can I act on this internally, and can I have a downgraded version — TLP:AMBER+STRICT, or just the vulnerability and the fact of exploitation without the sourcing and the victim detail — that I can take to my own people. In my experience originators say yes to this far more often than analysts expect, because they shared it precisely so recipients would be safer. What they are protecting is usually the source and the victim, not the technical fact.
While waiting, I would look at what I can do that does not depend on the intelligence. If the vulnerability is one we should be patching anyway, accelerating it through normal vulnerability management is legitimate — the action is justified by our own exposure, not by the restricted material. That is a genuinely different thing from disclosing.
The subtlety worth raising is that an action can disclose. Deploying a narrow detection or block that only makes sense if you knew this specific thing can tell the adversary what you know, and can tell other recipients where the leak came from. So the mitigation should look like routine hygiene, not like a targeted response.
If the originator cannot be reached and the exposure is severe, I escalate internally — to my own management and, depending on the group's rules, to the group's coordinator — and I make the decision visible and documented rather than taking it alone in a chat window.
What I would not do is decide unilaterally that this case is special. TLP is a trust agreement, not a technical control; it works only because people honour it when it is inconvenient. Breaching it ends the relationship, and the intelligence I would lose access to afterwards is worth more than one early warning.
Mistakes that cost candidates points
- Sharing internally on the reasoning that the organisation matters more.
- Not contacting the originator to request permission or a downgrade.
- Ignoring that a targeted mitigation can itself disclose the intelligence.
- Stating the TLP:RED restriction incorrectly, e.g. as organisation-wide.
- Refusing to act at all and leaving the organisation exposed without escalating.
You have read the answer, which is the easy part. Answer it in your own words and get graded against this same rubric, with the follow-up probe an interviewer would ask next.
Go deeper
Related questions
- In STIX, what is the difference between a cyber-observable object and an indicator? And what does TAXII do that STIX does not?
- The SOC escalates: a finance team member's account authenticated successfully from an IP in a country the company has no presence in, at 03:00 local time. MFA was satisfied. No alerts have fired since. What do you do, and what do you tell the SOC lead?
- A vendor publishes a report claiming an intrusion set is actively targeting your sector, with 200 indicators appended. Your CISO forwards it and asks "are we affected?" Walk me through your response.
- Ransomware has been deployed across part of your estate. A known family was used, a ransom note was left, but no data exfiltration has been observed despite C2 being active for six days beforehand. What are your hypotheses, and how would you test them?
- The incident is contained. You have 10 minutes with the board next week. The technical picture is still incomplete and attribution is unresolved. What do you present?