Endpoint

1/25/2017
10:30 AM
Andrew Howard
Andrew Howard
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Security Training 101: Stop Blaming The User

To err is human, so it makes sense to quit pointing fingers and start protecting the organization from users -- and vice versa.

We've all seen them: the "don't take the bait" anti-phishing posters plastered throughout most enterprises. As companies struggle with the various forms of malicious email, from spearphishing to whaling, I've noticed security leaders have begun to emphasize monitoring and deterring human, email-related mistakes. In that vein, companies are inserting language into employee agreements regarding cybersecurity hygiene and creating policies that punish lax security habits.

I believe it's time that we, as cybersecurity professionals, take a step back and reconsider our approach to user error. After all, to err is human, and our energies would be better served not on assessing blame but on protecting the organization from users — and users from themselves. 

A user-education program is of preeminent importance. Every modern control framework, from ISO to the NIST Cybersecurity Framework, requires user education. The problem I see in today's standard corporate information security program is that user education is the first and only line of defense against many threats. For example, many companies don't allow personally identifiable information to be transferred unencrypted, but have no data-loss prevention technology to prevent it. Frankly, this is irresponsible. When a Social Security number is accidently put in an email, the user gets blamed — not the information security group. This training-only strategy also creates an environment in which every user has to do the right thing, every time, without failure.

Users Make Mistakes: Be Prepared for It
Several months ago, I witnessed a Fortune 250 CISO dress down his director of governance, risk, and compliance because a recent audit found sensitive information on a shared resource not designed for that purpose. Immediately, the CISO and the director discussed implementing new information-classification training requirements for users and a scanning program to find any mistakes by other users, who would also need more training. This line of thinking appears to be common in less-sophisticated enterprises. No discussion of preventive techniques, only detection and blame.

A common methodology for user interface experience testing is to pretend the user is drunk. The thought is, if a drunk user can navigate your application, a sober one can easily do the same. The same methodology should apply to cybersecurity. In the security professional community, we have failed by counting on users to constantly do the right thing. Our focus must not be on eliminating human errors but on preventing them in the first place.

As a consultant, I have reviewed hundreds of presentations for boards of directors throughout my career. Many CISOs struggle with establishing board-appropriate metrics: they wonder about the right level of reporting detail to include and how much board members will understand. But I can always count on the phishing test PowerPoint slide to appear during a presentation. "How many clicks this quarter versus last quarter? How many repeat offenders, even after training? After we introduced training, the click rate dropped from 44% to 32%." It's amazing how similar these slides are across different companies, regardless of the industry.

Typically, I see companies with pre-training click rates in the 20% to 30% range improve significantly after several quarters of effort. The absolute best training programs I've seen, at security-conscious companies, produce results in the 2% to 3% range. Although remarkable, even this level is too high when it takes just one administrator to fall for a scam. After all, 2% of 50,000 users is still 1,000 users.

In my opinion, the phishing test click-rate is a terrible metric for reporting. It assumes the user is responsible for phishing-related issues and takes the focus off of developing reliable, technical controls.

I would much rather see companies move the focus to detection, and instead track their phishing reportrate or how many users reported a test phishing email to the security group. Improving the number of users who report phishing emails creates a large "human sensor" network to support the information security operations center. Recently, I worked with a company that has seen great results, with fewer incidents, using this model. The approach also has the added benefit of enabling the information security market to work with carrots — rewarding users who report — versus "using a stick" to punish those who click through.

Ultimately, user errors should be classified into two categories: (1) mistakes anyone can make, and (2) mistakes no one should make. Training programs and detection techniques should be focused on the second category. As a community, we should focus on preventing the first, and to accomplish that, we must move beyond blaming users and accept accountability as security's gatekeepers. 

Related Content:

Andrew Howard is Chief Technology Officer for Kudelski Security, trusted cybersecurity innovator for the world's most security-conscious organizations. Prior to joining Kudelski Security, he led the applied cybersecurity research and development portfolio at the Georgia Tech ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Evgen777
100%
0%
Evgen777,
User Rank: Apprentice
2/21/2017 | 7:39:41 AM
http://192-168-1-1.one/">192.168.1.1
Thanks for the insights!
WebAuthn, FIDO2 Infuse Browsers, Platforms with Strong Authentication
John Fontana, Standards & Identity Analyst, Yubico,  9/19/2018
Turn the NIST Cybersecurity Framework into Reality: 5 Steps
Mukul Kumar & Anupam Sahai, CISO & VP of Cyber Practice and VP Product Management, Cavirin Systems,  9/20/2018
NSS Labs Files Antitrust Suit Against Symantec, CrowdStrike, ESET, AMTSO
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "I'm not sure I like this top down management approach!"
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-17407
PUBLISHED: 2018-09-23
An issue was discovered in t1_check_unusual_charstring functions in writet1.c files in TeX Live before 2018-09-21. A buffer overflow in the handling of Type 1 fonts allows arbitrary code execution when a malicious font is loaded by one of the vulnerable tools: pdflatex, pdftex, dvips, or luatex.
CVE-2018-17358
PUBLISHED: 2018-09-23
An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. An invalid memory access exists in _bfd_stab_section_find_nearest_line in syms.c. Attackers could leverage this vulnerability to cause a denial of service (application crash) via a ...
CVE-2018-17359
PUBLISHED: 2018-09-23
An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. An invalid memory access exists in bfd_zalloc in opncls.c. Attackers could leverage this vulnerability to cause a denial of service (application crash) via a crafted ELF file.
CVE-2018-17360
PUBLISHED: 2018-09-23
An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. a heap-based buffer over-read in bfd_getl32 in libbfd.c allows an attacker to cause a denial of service through a crafted PE file. This vulnerability can be triggered by the executa...
CVE-2018-17361
PUBLISHED: 2018-09-23
Multiple XSS vulnerabilities in WeaselCMS v0.3.6 allow remote attackers to inject arbitrary web script or HTML via the PATH_INFO to index.php because $_SERVER['PHP_SELF'] is mishandled.