How Do We Know What We Know?
Making Sure You Can Understand What Happened in an Incident.
Another one of those Dan’s New Leaf Posts, meant to inspire thought about IT Governance . . . .
Until I reclined on my front yard, looking at the sky, following the instructions on how not to look directly at an eclipse, I had only known that the moon can block the sun by reading about it, or being taught about it. I had never directly experienced an eclipse.
Since then, I have learned that there are five primary ways to know something is true:
- Direct experience or observation.
- Reading it from text.
- Being told or taught it by another person.
- Logical reasoning.
- Intuition.
Whether one basis can be trusted over another depends on the subject, but in most cases observation is more trustworthy than logical reasoning, etc. For example, in auditing, observation makes a better audit test than reading a report, which is a better test than relying on what a person says, which is better than assuming because a policy says something, it is true.
Meanwhile, some means of learning the truth may be more effective than others. For example, I’ve been told that a hot stove can burn, and it makes logical sense based on other direct experiences I’ve had. So I’ll trust the text on this one, and not put my hand directly on the hot stove. My blister-free hands are glad I’m not relying on my own direct experience; that I am instead relying on the direct experience of others whom I trust. (I just know somebody in the family was dumb enough to touch the darn stove!!)
Information has degrees of integrity. As part of our response process, we gauge the integrity of the information we use to protect ourselves, to monitor technology risk, and to respond to incidents. We regularly ask: “how do we know this is true.” Or, in the case of incident response planning, “how will we know what is true?”
Here’s an example:
On the way into work, you know in your gut something bad is going to happen. That’s intuition. Should you trust it? Maybe, maybe not.
But when you get to the office, by the looks on everyone’s faces, you can deduce that yes, something bad did happen. Logical reasoning. Furthermore, when you ask, “what’s wrong,” and your employees tell you “we can’t access our network,” you have a more trusting understanding of what is going on. Your heart thumps faster as you tell yourself to calm down and assume nothing.
But until you actually log into the system, and start taking a look at various logs, you can’t fully know what is happening.
If the information we are using is derived from our own experience, it is probably safer to trust than information we are just making up. But that’s not always possible.
This is one of the most important reasons you need to utilize a security operations center separate from your network infrastructure. In a breach, you can’t directly experience what happened (i.e. you’re locked out of your network). You must, in that case, rely on what others have directly experienced. If you can at least go to the SIEM (that is managed by somebody else, or, at the very least, on a different network), and get the picture of what happened, you will be in a much better position to respond to the scariest of breaches, as well as (of course) the most common, the one that occurred in our example – ransomware.
Original article by Dan Hadaway CRISC CISA CISM. Founder and Managing Partner, infotex
Dans New Leaf is a fun blog to inspire thought in the area of IT Governance.
