"Security’s role is to protect our people" - Keil Hubert on how and how not to investigate security incidents

Remember that early reports in most security incidents are potentially misleading thanks to people’s unconscious desire to avoid punishment for any mistakes. Focus on getting all of the facts and mitigating the situation first before deciding upon corrective action. How does your organisation differentiate between blame and attribution when investigating security incidents? Straightaway, consider that these are often two different elements that need to be determined separately. Confusing one with the other is likely to alienate users, increase willful noncompliance, and undermine the security team’s institutional credibility. Let me frame this discussion through an embarrassing personal story (the best kind of story, I think) about the first auto accident that I was ever in. Or “caused,” depending on your perspective (which is entirely the point of this column). This story took place on a hot and lazy summer day. Hot enough that I’d borrowed my father’s truck to drive to the town library rather than hike the two miles like I’d normally do when the weather wasn’t so awful. I’d just finished securing my stack of new books and was starting to back out of my parking spot when I heard a tremendous “KA-WANG!” sound. I was thrown against the steering wheel and my father’s little truck came to an instant halt. I turned off the engine, set the parking brake, and hopped out to see what had happened. Just behind my parking spot, a large 1970-something family sedan was stopped … with both of its driver’s side doors caved in. The car’s driver – an adult lady who seemed disoriented – fumbled ineffectually at her crumpled door. I helped her exit safely from her land yacht’s passenger side. In the 1970s, cars in other countries tended to be small and efficient while  but American cars were still quite large. Back then, if you couldn’t park a helicopter on your car’s bonnet you didn’t drive a car worth having. The lady’s car was still driveable; only her driver’s side doors were wrecked. Staved in all the way to the arm rests. The damage to my father’s truck was limited to its rear bumper. After looking at the scene, we realized that we were both lucky that she hadn’t T-boned me in her rush to reach an open space. Our collision had happened because of three important factors:

1. There had been only one open parking spot left (ours was a very small library) so the lady was driving (at or about) twice the posted speed limit for the car park to get the last spot before someone beat her to it.
2. The lady had been driving the wrong way down a one-way traffic loop because it was the shortest distance from the car park entrance to the open space.
3. The lady needed lots of turning room to fit her gigantic saloon car in the normal-sized open space. As a result, she’d manoeuvred into the spaces of the cars parked opposite the space she wanted.

There was absolutely no question that the lady was at fault for the accident. Her reckless driving had put both of us in unnecessary danger. Given the size and weight differences between our respective vehicles, I felt lucky to be alive. After trading insurance information, I used the library’s phone to call the city police and report the accident. [1] The police wouldn’t investigate since our collision hadn’t happened on a public road. Irked, I jogged home (so as to preserve the crime scene evidence), got a camera and metre stick, and jogged back. I collected enough imagery to show that I’d been inside my own parking space when the lady had recklessly driven through it. That evidence alone should have been more than enough for both insurance companies to place her clearly at fault. Had the police actually visited the accident scene, the lady’s evasive version of events alone might have been enough to convince the authorities to question her version of events. But of course that didn’t happen. The lady’s only statement to the crash investigator was “The boy was backing up and he hit me.” While her statement was technically correct, she left out all of the crucial details and context. Since I was a teenager and the lady was an adult, the insurance company decided that her uncorroborated statement was good enough for them and closed the case. That’s how I got stuck with the repair bill for her staved-in doors. Here’s why this story pertains to us in security: the critical mistake that the car insurance company made in my library crash story is the same sort of mistake that lots of security personnel make when investigating potential incidents. It’s human nature for busy people to want to get minor tasks completed quickly. When a witness offers us a plausible and simple explanation for an incident that allows a job to be closed and forgotten quickly, it’s awfully tempting to accept the statement at face-value and move on. Tempting, but wrong. Speaking of human nature: it’s common to try to minimize blame and to “spread out” blame in order to avoid consequences. A small percentage of people will lie and falsely blame others for their own actions; such people are (thankfully) rare in a professional setting. Most people will tell investigators a carefully-worded true story that paints their actions in the most favourable light, all the while hoping that the investigator won’t realize that they’ve left out crucial details. This isn’t a malicious “lie” as such; at worst it’s more like obfuscation with unintended consequences. This is understandable … and it’s also potentially dangerous for the company. When a person involved in a security incident leaves out crucial contextual details about what happened, it hinders security’s ability to recognize, react to, and mitigate vulnerabilities, threats, and correctable errors. Security either wastes time chasing the wrong actors or doesn’t react at all to something that it can and should fix. What’s worse, security’s institutional credibility can be damaged when people realize that security staff can be duped.  Credibility and trust are crucial for a security department to be effective. If senior leaders get the impression that security engineers can be easily mislead, all of the security department’s programs, processes, and pronouncements will be called into question. So, what do we do about this? Are we supposed to initiate a full, formal investigation into every possible infraction, no matter how small the risk might be? Eh … no. As helpful as that might be, I argue that investigating everything is expensive overkill. Most organisations don’t have the resources to, let alone the political will needed to run down every tiny event. Instead, I recommend that security leaders do two things: first, realize that people have a natural (and completely understandable) motivation to dissemble when asked to discuss an error they might have made or a policy violation that might have been committed. This isn’t an inherently evil act; good people do this too. It’s natural for honest, loyal colleagues to want to avoid getting in trouble. That’s why initial reports are often “lacking essential details.” In turn, this is why all of us working in the security field need to strenuously avoid making spot judgments on incomplete information. Instead of trying to assign blame for an incident, seek to understand the total operational picture first. Worry about pinning responsibility and identifying the “guilty” later. Better yet, leave that part to a neutral and detached senior leader or decision-making body. We’re not the police and don’t want to be the police. Security’s vital role is to protect our people, our organisation, and our mission, not to “punish the evildoer(s).” Lastly, don’t get cranky with people for providing vague initial reports. Just like the wrong-way too-fast wildly-unsafe library aficionado that bent my bumper one blazing hot summer afternoon, most people are initially shy about owning up to an embarrassing mistake. It’s our responsibility as security experts to calmly and thoroughly gather all the facts so that we know what really happened … so we can proceed to fix whatever (or whoever) really needs fixing. [1] No mobile phones in those dark days.