Managers often think about compliance in terms of policies. There is something concrete, achievable and finite about them. And they are required by laws and regulations for protecting information and systems. But too often managers think of policies as a finish line for compliance. Need to be compliant? Then write a bunch of new policies and move on to the next project. And while managers may know in the backs of their minds that a set of security policies may not be enough, they also believe that they are at least a step in the right direction. That misunderstanding has created a lot of problems for our clients.
Policies that are not integrated into the organization create real liabilities. In fact, I often argue that Arthur Andersen fell in large part because of its inconsistent enforcement of their work papers destruction policy. If they were consistent in enforcing the rule, including their destruction of Enron work papers, their document destruction party would not have led to a charge of obstruction of justice.
In this two-part posting I will be describing two common ways that policies can hurt your organization. In this first posting, we will be discussing the liabilities that organizations create when they write policies that are not followed. In the second posting we will discuss how a common style of policy writing can create a breach-prone environment.
In the information security world we encounter many “security policies for sale.” These may be off-the-shelf products, integrated into GRC (governance, risk and compliance) applications, or packages that are sold by laws firms and consultancies. The organizations that provide these security policies often ensure their customers that if they have a library of information security policies in place, they are well on their way to regulatory compliance. But having assessed, audited and cleaned up after many of these policies, I have too often seen increased liabilities rather than improved compliance.
It is comforting for a manager to know that they have policies in place, especially new policies that are implemented where there were none before. But if policies were purchased or developed as an end in themselves – not having been integrated into procedures, audits and performance reviews – then they are only superficial, and they introduce new hazards.
Let’s consider acceptable use policies. These common policies are instructions for people to act in a certain way while using technical systems. If an acceptable use policy is not enforced in some way, through training or audit, for instance, then it will be ignored. Now imagine that a disgruntled employee violates that policy by sending inflammatory or harassing emails, or playing inappropriate media at their desk. They should be disciplined and perhaps fired. But firing is a careful process in most organizations, and if you want to use your acceptable use policy to build your case against the employee, then you will get resistance, at least from HR and perhaps from the disgruntled employee. They both are right to ask why you are enforcing the policy only in their case and not in other cases.
Now let’s consider the impact this has on protection of personal information. Your organization has a policy, provided to you by a GRC application, consultancy or law firm that requires encryption of data stored on removable devices. Often this policy is circulated but without a process in place to actually enforce or oversee compliance with this rule. In fact, it may be that people in IT know that it is not practical to enforce that rule. Against this background, an employee reports that they lost a USB pen drive with thousands of PII (personally identifiable information) records on it. As part of the legal disclosure process, your state’s attorney general’s office asks to see your policies and finds that you were not enforcing them. And here’s where it gets tricky. They assert that since you have the policy, management must have determined that encryption was a reasonable control, but the reasonable control was not enforced. That means that the organization was negligent by not enforcing something that they defined, by policy, as reasonable.
Even in a more common scenario, consider the process of information security and compliance audits. When an auditor conducts their audit, one of the first things they ask to see is your policies. Then they check to see if people, technologies and facilities adhere to those policies. If your policies are superficial – if they were written, purchased and adopted without being integrated into the organization – then your audits will not go well.
So how do you make sure that your policies efforts are worthwhile, and that your policies actually help and not hurt your security and compliance efforts?
- Absolutely consider policies that reflect best practices, whether you buy them from professionals or develop them using information security standards and laws as a guide. If for every security obligation you have there are policy clauses that cover them, then you are off to a good start (not finished, mind you).
- Be sure that the policy clauses reflect what you actually do. When designing policies you are stating what you believe to be reasonable cyber security controls and processes. Make sure that you can actually accomplish those controls and processes by reviewing them with the management and personnel who will have to carry out the policies.
- Ensure that procedures, training materials, job descriptions and performance reviews reference the policies and require adherence.
- If you have an internal audit function, make sure that auditors conduct both a “design level” audit (are policies and controls sufficiently designed) and an “effectiveness level” audit (are controls and procedures effective). They should be informing management of whether the policies are being followed and enforced.
- And for Pete’s sake, enforce your policies. If you are not consistent with policy enforcement, then you will have regrets on those occasions that you need to enforce them most.
In the second part of this blog posting I will be discussing how overzealous policies can create a breach-prone environment. I’ll give you a hint as to how: When security conflicts with business, business trumps security every time.
