Many of us in the cyber security field came up through IT administration roles. We are often troubleshooters at heart. We look at a problem and try to figure out what the cause is to get things back up and running. In the security world, these are useful traits… When responding to a security incident, we are generally inhibited by the “fog of war” – we have incomplete information about what is happening and are forced to hypothesize about potential causes, sources, actors, and so on. As we learn more about the situation, our hypotheses are refined until we know who did what, where, and how.
These skills are vital, but the can also cause problems for your organization if you are not careful. Sometimes a security incident turns out to be a breach where data is stolen or destroyed, and that can lead to legal actions – either by government agencies or by customers, employees, or others that may be impacted by the incident. The things we write, particularly in emails, text messages, and so on, may be discoverable in court, and our words used against our organizations. Investigative activities performed over email, for example, may include speculation about the cause or extent of the incident, and that may turn out to be wrong, or at least an incomplete picture of the situation. If I’m working with a team to investigate a compromised server we just learned about, I might be inclined to email an update saying “You know, I’ll bet that server team forgot to patch Apache Struts again. That team is very understaffed and keeps missing patches.” Hopefully, it’s not hard to see how that statement could be used as evidence that we not only knew about the problem, we actually caused it through our actions.
At the same time, we need to communicate during incidents, and we necessarily need to hypothesize about the causes. But, we can do so without running ourselves and our organizations up the flag pole. Here are some recommendations:
- Speak to your organization’s legal counsel about this topic, and if possible, set some ground rules for how to manage communications during an incident. Rules vary by jurisdiction, and I am not a lawyer in any of them, so you should see the advice of an expert in your area
- Do not make legal conclusions in written communications. For example, do not write “we just violated HIPAA by sending that file to the wrong person.” There is a lot of nuance in law that we in IT land may not understand. Instead, communicate what is known without a conclusion. In this example, a better statement would be “We appear to have sent a file containing PHI to the wrong person.” I am sensitive to the fact that making the harsh statement can be more motivational than the factual statement, but keep in mind that it may end up being your words printed in a media article or presented in court about the breach.
- Keep communication clear, concise, and free of emotion and speculation. This can be difficult to do in an incident situation, where time is short, tension is high, and we may be tempted to release some inter-office drama. But this is not the time or place for such things. For example, do not write “I don’t know who started it, but Jerry has already managed to opened a malicious attachment and caused an outbreak four times this month, so I’ll bet it’s him. His management team just doesn’t care, though, because they love his hair.” Instead, say “The infection appears to have originated from a workstation. We will prioritize investigating sources we’ve seen in the recent past.”
- If and when you do need to hypothesize and speculate about causes, do so on a phone call where the issue can be discussed and resolved without leaving a potentially ugly paper trail of incorrect speculation.
- Above all else, we must act ethically. The intent of this post is not to provide guidance on how to hide incidents, but rather to ensure that any reviews of the incident are not contaminated with office politics, incorrect speculation, hyperbole, and IT people declaring the organization “guilty” of some bad act.