Prime Factors Blog

Human Errors and Data Protection

Posted by Jeff Cherrington on Jun 20, 2014 12:00:00 PM

An article in this month’s issue of Security Magazine points to a juicy tidbit in a recent IBM paper. Their X-Force Threat Intelligence Quarterly report for Q1 of this year contains several interesting items – register to receive a copy of the report here. It touches on a wide swath of security topics, including malware, mobile threats, and exploits – useful reading. The juicy tidbit Security Magazine lifted out is the report states that “95% of Successful Security Attacks are the Result of Human Error”.

This is really no news to anyone who works with technology and data protection professionals in particular. The security tools and applications available, for the very largest part, actually work when they are correctly applied. The entertaining scenes of “master hackers” access heavily encrypted data with only a few minutes effort common in television, games, and movies notwithstanding, strong encryption using long & random encryption keys are effective means of protecting data. It is selection of the latter element, encryption keys, where human error creeps in.

[For the crypto geeks in the crowd, there are potential issues from keys when random number generation is weak, and the whole RSA-NSA assumed scandal leaves some key generation suspect. That’s a topic covered in some future posts.]

There are many ways to generate encryption keys and one of the least useful is leaving selection up to users. There are bales of research showing both that user selection of passwords (standing in as a proxy for encryption keys here) is fraught with weakness. First, the majority of users will not, unless absolutely not select long/strong values for data protection passwords/keys. Mark Burnett did a frequency analysis of body of 6M unique user ID/password pairs publically available to develop the list of the 10,000 most frequently used passwords.   (Please note that some users appear to favor vulgarity in their password selection – please be forewarned if you look into the details of the article.) The alarming summary of the frequency analysis showed:

·         4.7% of users have the password password;

·         8.5% have the passwords password or 123456;

·         9.8% have the passwords password, 123456 or 12345678;

·         14% have a password from the top 10 passwords

·         40% have a password from the top 100 passwords

·         79% have a password from the top 500 passwords

From an attack surface point of view, this would indicate that dictionary attacks of passwords don’t need the complete Webster’s unabridged, or even the Funk and Wagnall’s – a list of only 500 passwords are likely to give a hacker access to almost 80% of systems.

This can be mitigated to a degree by ensuring password hardening rules are in place, and many applications and bespoke systems do so. However, the human predilection to short and simple, authoritatively documented in George Miller’s paper “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information”, presses things in the opposite direction. Users, willfully or unconsciously, resist use of long non-sense strings of characters or bits and, even in situations where length and complexity is enforced, find ways to make passwords simpler and easier to remember and enter. Even when strong passwords are imposed on users, even trivial social engineering gain access to them. (Another favorite topic for a future post.)

From this, it is plain that allowing users to select encryption keys to protect sensitive or regulated data has a very high likelihood of resulting in breached data, sooner or later. Best practices, then, removes key selection responsibility from the user and automates it. Automation is not subject to the “magic number 7” nor temperamentally resistant to difficult chores – rules can be specified and applied consistently, and the risk of human error removed.

If automating selection and secure distribution of encryption keys, symmetric or asymmetric, to your applications is a concern, learn more about a free fully supported evaluation of EncryptRIGHT and its automated key lifecycle management capabilities.