If Security is Deployed And Users Don’t Accept It, Are You Protected?

If security is deployed and users don’t accept it, are you protected? Well, are you? This is perhaps the most important question to ask when establishing a data security policy and choosing tools to maintain the confidentiality of your corporate data.

Surprisingly this question is often overlooked or not considered at all. How could that be? I can think of two reasons. First, most of us like to think we can outwit hackers and employee malfea sance with cutting edge and sexy (yes, sexy) technology. Nothing is sexier than security tools employing the use of technology acronyms, like AES and DMZ and IPsec and PKI. Heck, I’m getting pumped just writing about them. The more, the better, right? And the bigger the number you can attach to the acronym, the better. “256” seems to be a good one.

Technical considerations generally consume the purchase decision--for good reason. Admitting to your executive team that “we’ve selected a tool that was cutting edge in 2002--it has some known (but mostly obscure) vulnerabilities and should be fully deployed next year” seems a bit career limiting, don’t you agree?

The second reason user acceptance is not considered is, well, ignorance. I hate to be so blunt but there you have it. Most of us continue to think we can control user behavior with reasonable, unobtrusive demands outlined in the form of SECURITY POLICY.

We can’t.

I’ll tell you why shortly, but before I do, let’s examine the paraphrased words of nearly every corporate spokesman when explaining a data breach to the press. These quotes are so consistent that I’m beginning to believe there exists a press relations manifesto entitled “CYA: What to tell the press when you’ve experienced a data breach.” OK, maybe I’m a bit of a conspiracist, but pay close attention the next time you read about a data breach in the media  – you’ll see what I mean. The statement almost always goes something like this:

1. “We at (company name) hold the confidentiality of our customer/client data in the highest regard and regret the need to inform those affected clients that their data may have been exposed.” How noble.
2. “Our employee violated clearly stated data security policy.” Throw the employee under the bus – the company has done its part. This is sometimes bolstered with:
   a.    “We require all employees to undertake rigorous data security training.” Darned employee!
   And to show that the company is really serious, they may add:
   b.    (Company name) has reprimanded (or terminated) the employee for this egregious violation of security policy. See how serious the company is?
3. “This employee violated our policy that clearly states:” Below are some popular choices:
   a.    Employees must not download sensitive data on PCs/laptops
   b.    Employees are not to write down password or login credentials
   c.    Employees are not to share password or login credentials
   d.    Employees are not to di sable the software for any reason
   e.    Employees must download and install software (or patch or updates or…)
4. “We at (company name) take this sort of breach very seriously and effective immediately, (company name) is going to enforce better even more stringent employee security policy.”
   Wait a minute! Didn’t the spokesman just say (in item #1) that the user violated security policy? So the proposed solution is to impose even stronger and more burdensome security policies? Coercion, threats and browbeating employees into security policy submission will not work. At least not consistently nor under all circumstances. Let me be fair--most of the time--maybe even 99.99 percent of the time--security that relies on users’ adherence to policy will be sufficient. But this is a game of inches; a game of odds. Sooner or later your user will take a short-cut, overlook a procedure or make his own risk assessment and decide it’s OK to “take the chance.” It is at this very moment that the odds for a breach go through the roof.
   Why would a user take such a chance? The answer is really quite simple but not only do we not want to admit it, we’re not likely to consider it in our decision making. Here it is--the big secret: People are inherently selfish. It’s that simple. I know this to be true and I’m betting you do too, but I feel compelled to cite an “industry expert,” namely Plato, who reasoned this some 400 years BC! Good enough for me.
   People are selfish. Sure, some more than others. Our users--our employees--are people too and are concerned primarily with their own self-interests.
   Still with me? It’s time for truth #2: Security and productivity are almost always mutually exclusive objectives. Improved security comes at the expense of personal productivity. It stands to reason then that an employee motivated by productivity will eventually be faced with a trade-off. “Should I maximize my productivity (complete my audit, close the deal, or finish my project) or shall I take every precaution to ensure the security of someone else’s data?” That “someone else,” is going to be a person the employee cares less about than himself. (Back to truth #1.)  Not a tough decision.

Consider these recently publicized admissions of employee/user error leading to a breach of data security:

• User wrote down her login password and affixed it to the stolen laptop
• User was not supposed to possess the data on a pc
• User was not allowed to put data on a pc, nor remove it from the building
• It was the employee’s responsibility to encrypt laptop data
• User fell victim to phish attack and volunteered login credentials
• Transportation of media through common carrier (against policy)
• Laptop stolen from employee’s unlocked car
• USB flash device used for data transportation used (against policy) and stolen

At first glance many of the above examples seem to be nothing more than simple, bone-headed errors. But give them careful consideration. Why would a user write down a password and possibly affix it to the computer? Many companies follow a password policy which includes complex passwords that change frequently. Let’s assume the user is an outside salesperson already late for a presentation to a prospect. A failure to remember a new complex password while in the field would be catastrophic, wouldn’t it? This is especially true if the employee can’t count on instantaneous help desk support. Clearly this could adversely affect the employee’s productivity. It could hit her where it hurts.

Each of the above instances can likely be traced to a shortcut or choice made in the employee’s interest of doing her job better, faster or more efficiently--by definition, a selfish act. Remember, these are not bad people. They are just like you and me. And they’re generally doing exactly what their employer wants them to do. The employer certainly wants them working productively--better, faster and more efficiently, right? Point is, we must not blame or find fault in our users. They’re providing the value that is sought by their employer and they’re slaves to good ole’ human behavior.

It is critical for us to recognize these truths when devising security strategy and selecting tools for the protection of confidential business data. Here are two extremely simple rules that must be adhered to:

1. Security must not rely on the user for deployment or efficacy.  Instead, business decision-makers need this control.  The employee/user doesn’t own a vote.
2. Security must not come at the expense of productivity.  If it does, your user/employee will find a way to undermine, circumvent or remove the measure. 

There are plenty of good tools available for the protection of your sensitive data, whether they be network data on servers behind a firewall or network data duplicated at the perimeter--on PCs and laptops. Controlling and securing this data is the responsibility of the business decision makers and risk managers.

Relying on user compliance for data security is risky business.

Cam Roberson is director of marketing for Beachhead Solutions and can be reached at This e-mail address is being protected from spambots. You need JavaScript enabled to view it .