The devil is in the details: The importance of tight processes to strong information security

Have you ever pulled a policy or procedure down from the internet, changed a few things and called it your own? If not, you are probably one of a small minority. Most of us have done this from time to time, and building on the work of another (assuming of course that it is not copyrighted) is a good way to start, as long as you make the proper adjustments to meet your specific needs.

Therein, however, lies the problem. 

The issue of useless policies and procedures often begins with an audit finding about the lack of such documentation, sending folks scrambling to get something in place. Many organizations, particularly smaller ones, have no experience with writing policies, so they figure that something is better than nothing. 

Policies, procedures and guidelines together form the processes that make an organization function. Good processes help to ensure that you are ready to address occurring problems quickly and consistently, which is particularly important when addressing information security issues.

According to Dawn Marie Hutchinson of Optiv, on a recent episode of the Down the Security Rabbithole podcast, policies are a risk mitigation tool. The better and more applicable the policies, the more risk that is mitigated. As such, a policy that you download and change the name on likely mitigates no risk at all.

It all starts with policies

Policies are the key element of your process documentation. They define how you will conduct your business from an information security and privacy perspective.

Policies do not have to be long. In fact, the more succinct the better, so long as they cover the required details. In my experience, they should be quite granular — single policies that cover a variety of topics are hard to maintain and follow. 

Policies are usually augmented by procedures. A procedure defines the specific steps you will follow in the implementation of the related policy, and by their nature should be very detailed. If a procedure is well written, someone familiar with your organization but not a particular function should be able to follow the procedure and complete the function. 

Policies and procedures often reference guidelines, which provide parameters related to how functions will be carried out. They are not used in all cases, but are beneficial in certain circumstances.

Let’s use passwords as an example. You should have a policy that requires the use of strong passwords, imposes limits on passwords for accounts with elevated privileges, and ensures other related requirements. The related procedure will define the specific steps the IT function will follow to control and oversee passwords. A guideline for the password function will state the specific requirements for passwords, including length, complexity and how often they must be changed. 

Getting your processes in order

For organizations with poor processes, nothing seems to work quite right. A crisis of any size seems to confound the team. Many organizations in this boat will tend to throw money at the problem by way of purchasing tools, which solves nothing and adds more confusion. 

If your policies are weak or nonexistent, or your processes are not helping you get the job done, the following are some suggestions for getting them in order:

Built process first, and then add tools to augment. As I noted above, introducing complex tools to an organization without good processes will only add confusion. In such cases, these tools usually end up on the shelf. Get your processes running smoothly, and then add tools to strengthen the operation. 

Never build policies to justify tools. A policy should define how your organization functions, and should be the same whether you use people, automation or some combination of the two. A good policy should define what is to be done — not what tools are used to get there.

More people requires tighter processes. Instead of throwing money at a process problem via tool purchases, many organizations try to hire their way out. They hire more people, assuming that more hands will make for fewer problems. Quite to the contrary, adding more people requires tighter processes, particularly given the need to coordinate activities among the team, and to ensure that everyone understands how tasks get divided. For organizations with inadequate processes and many people, it has been my experience that tasks often fall through the cracks, because everyone is expecting someone else to handle those tasks. 

Test your processes. The only way to know whether your processes work is to put them to the test. Desktop simulations can help, but I prefer a test that nobody is expecting. Some time ago, I notified an entire information security team about a vulnerability in an effort to assess how well the team would follow the defined process. 

Communicate and use processes. It still surprises me to find organizations that develop good processes, put them in a book and never look at them again. I suspect more than one of the policies or procedures I was paid well by a customer to write never actually got used. Processes do not work by osmosis. You must publish them, train your team to follow them and make sure they get followed.

Tell your customers. A good way to ensure accountability for having and following good processes is to make your customers, internal and external, aware of them. If a customer knows a policy or procedure and finds you not following it, they will usually not hesitate to tell you. 

Bottom line: Tools and people are important to the success of an organization, but are not a substitute for strong processes.