By Lois Garcia – Technical Consultant
Entering the security field after having built my career in technical operations, I’ve most often been on the “receiving end” of security policies. It’s frustrating to think that I’ve completed a project, only to have security issues kick it back into the queue. It’s equally frustrating for a security professional to be asked to approve a completed project, only to find that security policy wasn’t followed. Our own government’s Office of Personnel Management was breached in 2015, and the FBI reported as many as 18 million records were compromised in attacks going back to June 2014. LifeLock, a company providing identity theft protection, was found by the FTC to have failed to uphold minimum security standards handling their clients’ personal data.
Security policies exist to enable a business to function successfully. Just as everyone on the highway relies on other drivers’ competence, as well as on their own safe driving, so, too is it in each individual’s self-interest that we all take a strong stance on security. Yet, security policies aren’t followed. Why is that? Where is the disconnect between security and other business units?
I’ve put together this list to help create a dialogue between security, ops, and other teams. I hope to spark some conversations, or even (constructive) arguments, about security policy.
1. The policy exists solely to protect the company’s legal standing in the case of an incident.
In these environments, following policy is often rejected in favor of moving quickly. Many justifications are made.
To disregard the deeper meaning and intent of the policy is to take a short-sighted view. An organization without respect for its security policy risks losing its reputation, both internally and externally. More tangible losses will follow.
2. There is a policy, but no one understands it, except the person who wrote it and who has since left the company.
Also, see #1. A well-written security policy is a detailed document, not a sequel to “War and Peace”.
Even if the policy is well-written, without attention to the practices and procedures for implementation, the security policy is just failed rhetoric.
3. They have never seen or don’t remember having read the security policy.
If the only time the security policy is in evidence is in the pile of paperwork signed by a new hire, it is not likely to have a significant impact. Again, see #1. The average employee is certainly not likely to be aware of all the specifics of all the security policies. They might not know that a comprehensive security policy exists. (It does, doesn’t it?) The only sign of a security policy is often an onerous password policy, with poorly implemented password synchronization and expiration notifications, making lockouts common.
I remember finding by chance one company’s security policy on their intranet, and not being able to find it again after they upgraded their wiki platform software. If a search for “security policy” does not turn up the document, it might as well not exist.
4. Managers are aware of the policy, but their managers do not prioritize or reward a strong security posture, and the disregard trickles down.
One way of conveying the message to ignore security policy is to deflect or ignore questions about security, noting that the next software release or quarter sales earnings are a more important area of concern. There might be assurances of addressing security concerns “next quarter”, or when a security team is hired.
A common misunderstanding of a strong security posture pushes the responsibility for security wholly on technology, or on the security team. For example, I’ve heard, “We’re behind a firewall. We don’t need to worry about security.” The concept of defense in depth is not always known outside of the security team. It’s also not yet widely understood that attacks are a question of “when”, not “if”.
5. People are aware that they are in violation of the security policy, but they believe the policy does not apply to them due to their elevated status or intelligence.
The person that has been with the company since it was a five-person team is sometimes hostile to having their freedoms curtailed in the name of security. The person with access to the most sensitive information may very well have the authority to disregard security policy. A highly political organization will have power dynamics that can get in the way of a good security posture. Security teams struggle for headcount and support and often have to battle egos to achieve security goals.
6. People are aware that they are in violation of the security policy, but they think the policy is stupid.
Security practices that are “bolted on”, after insecure habits are ingrained, often collide with this attitude. This is not a lost cause. Maybe the rule does need to be reconsidered or adapted. Maybe the user can be made to understand the principles involved. An atmosphere of mutual respect will lead to the most satisfying resolution. Taking the hard-line approach is not always productive if the long term goal is truly a more secure computing environment.
7. Following the policy gets in the way of getting work done.
Goes hand in hand with #6. A good security policy exists to enable a business to execute safely, not to stop its flow. If how to follow the policy and still get work done isn’t made clear, the policy won’t be followed consistently. People have deadlines. Education is key.
8. They forget what is and isn’t allowed by a security policy.
If security isn’t on people’s radar, it will tend to be forgotten when the next shiny new technology comes along. Is the policy something seen only once at the time of hire, or possibly not at all (see #3)? Are security policy tenets being distributed frequently, before problems arise? Even with a well-written policy, not all knowledge will permeate the organization through osmosis. How easy is it for people to access the policy, or to get answers to questions about it, when in doubt?
9. The security policy is out of sync with the current environment.
This happens frequently when organizations merge. It is also common for technologies to be introduced to a company without security oversight. Security is known as “the department of ‘No’”. This leads to “asking forgiveness rather than permission”. As the business environment evolves, security policies will tend to lose relevance without committed review and revision.
And now, the best reason of all…
10. There is no security policy.
“We’re too small to have a security policy.” “We don’t have time to write a security policy.”
That’s too bad. The speed of the cloud means a security hole can be deployed and magnified at a scale unheard of in the pure hardware days. It’s much easier to take a strong security stance before the environment is full of the dark corners and back alleys of abandoned VMs, stolen or hijacked laptops, offshore teams, terminated employees, services running under terminated employees’ accounts, and the like.
We are entering an age when cyber threats are the greatest threats to critical infrastructure, and our most personal data is no longer treated as our own. Security must be a thread running throughout the fabric of the organization.