Human Error in Cybersecurity
Why blaming people for incidents is self-defeating
“Human Error” is a favorite go-to when explaining a cybersecurity incident. Those pesky people! Even I have been known to say that our security jobs would be much easier if we worked with dolphins, instead.
And I was only half joking. Even the revered (for good reason) 2022 Verizon DBIR notes that:
The human element continues to drive breaches. This year 82% of breaches involved the human element. Whether it is the Use of stolen credentials, Phishing, Misuse, or simply an Error, people continue to play a very large role in incidents and breaches alike.
The environments we work in are complex systems. Humans don’t work alone — they interact with computers, teams, cultures, assumptions and history. They are making decisions by the nano-second, and are part of an ecosystem of risk that they rarely control. Why, then, when there is a cyber incident, do we insist on finding a singular cause, or a list of independent and disconnected causes? Why is it appropriate to name some poor schmuck (the intern, the contractor, the finance person, even the CISO) as the primary or only reason for all this pain?
We’re not the only profession to do this. In her book “Engineering a Safer World: Systems Thinking Applied to Safety” Nancy G. Leveson notes “the less that is known about an [aircraft] accident, the most likely it will be attributed to operator error”. There are many studies on the impact of human error on patient safety in medical practices. We have all made our own non-security mistakes at work and elsewhere, and been reprimanded, or even fired, for it.
If humans are part of an “ecosystem”, and if we security professionals are all about “defense in depth”, then shouldn’t our environment be managed so that human error is mitigated so that it is not the “cause” of a cyber incident?
I blame our focus on “root cause analysis” and sequential “kill chain analysis” for some of this. As Leveson notes, if we are looking for an “event” that initiates a failure, then “if the problem is in the system design, there is no proximal event to explain the error, only a flawed decision during system design”.
Let’s look at phishing as an example. We train our employees to spot a phish, and hopefully report that phish. When they fail to do this, and their credentials are compromised, or malware is activated, we blame the event on “human error”. But what else happened (or not):
- How did the fraudulent email even make it to the employee’s inbox? Where were the email security controls, and how effective were they?
- What was the business process that assumed the employee needed email to do their job in the first place, or used email as a transport for documents and other attachments?
- What was the organizational culture? Had it failed to invest in alternatives to email, or chosen to spend resources on things effective controls?
- How good was that awareness training anyway?
- How good was general onboarding processes, and education on how to use the technology?
- How effective were the detection/monitoring controls?
- Etc.
- Etc.
- Etc.
What would our post-breach analysis report look like if we were not allowed to use “human error” as one of the factors? We don’t allow “computer error” to be used, so why are humans any different?
(BTW, I still advocate for training and awareness programs — they do show value as a manual workaround to mitigate design, configuration and process errors. But they won’t eliminate human error — we are, after all, imperfect and fallible).
We are continuing to use “human error” as a scapegoat, to make up for our own organizational and political deficiencies — and our employees know it. If we’re going to advance the importance and seriousness of security as a business issue, we need to acknowledge that “human error” is only possible when we have poor systems design, and that any failure of that design is an organizational problem. Retaliation, in the form of discipline (even if that takes the form of training) isn’t worth the resource expenditure. Instead, we need to double-down on changing the environment in which people work, and how our controls interact with that work stream, eliminating the option to “make a mistake”.
May it be so.
