Ten tips for security policy reviews

Writing security policies is no one's idea of a good time, but they are a crucial part of an organization's commitment to security best practices. 



Writing security policies (or any policy for that matter) often serves as penance for crimes committed in a previous life. Unless you are one of those sick, twisted individuals that enjoy them, policies are generally perceived as bigger waste of time than the MTV awards. Policy management is one of the most thankless (yet crucially important) tasks in security. There is no glory in writing, maintaining, and communicating policies. 
The litmus test of the security culture of an organization is who is responsible for policy management. If it’s the summer intern or the junior security analyst, then the company does not take security seriously. Most security policies tend to be released surreptitiously in the middle of the night and are rarely read or understood by those in the organization. They are written purely as a compliance check mark. Policies form the bedrock of your security program and need to be treated as such. Here are my ten tips for extricating the most value during policy reviews.

1. Keep track of the policies in a centralized location
Most companies struggle with policy management as they have countless versions of policies floating throughout the organization. It would be best to have a central repository for all company policies (HR, Legal, IT) as it provides a holistic and unified approach. Depending on the number of policies you have, it would be wise to use a spreadsheet that outlines the policy name, owner, effective date (last reviewed), status (draft or live), and next review date.

2. Review policies annually and/or when business needs change
Having a policy that sits in a filing cabinet collecting dust is useless. Policies need to be reflective of current business needs and requirements. Given the dynamic nature of many industries, policies need to be actively maintained.

3. Communicate policy changes accordingly
Updating the policy without properly communicating it out to the relevant employees is like listening to the radio with the volume off. Advertise it on the company intranet, speak with department heads, tell people you see at the water cooler. Don’t just send an email and call it a day.

4. Write the policy in "plain English" and focus on brevity
We are not lawyers (thankfully) and not trying to trick our co-workers. Keep the policies clean and simple and avoid heavy jargon. Keep it brief and to the point. Please don’t use a thesaurus and change random words in an attempt to sound smart.

5. Check for proper spelling and grammar
Nothing removes legitimacy faster than a poorly worded policy littered with spelling mistakes. You don’t have to be an English major to write security policies, but for the sake of professionalism you still need to abide by the rules of the English language (even if “twerking” has been officially added to the language).

6. Ensure that every policy contains a revision and version information table
Keep track of the version number for each policy.

7. Ask: Does the policy accurately reflect the way the company currently conducts business?
Policies cannot exist in isolation from the business. For example, you cannot ban the use of DropBox in your organization without providing your employees a reasonable alternative, especially if your business requires tools such as DropBox. If you don’t have a monitoring or enforcement mechanism they’ll go around the policy anyway.

8. Ask: Does the policy adequately deal with the issues it is intended to address?
If you created a policy to address potential data loss via mobile devices but failed to include that the device should be locked with a password/PIN, the policy does not fully address the data loss issue. An incomplete policy  is an ineffective policy.



9. Ask: Do any policies need to be created to address new business requirements?
As new business requirements come into being, don’t wait until the next policy review. Security policies, in particular, form administrative controls for certain risks. For example, when USB sticks became widely adopted, many organizations waited years before updating their policies to reflect how USB sticks should be used within their enterprise. By not creating a USB policy to reduce this risk, many organizations exposed themselves to a higher likelihood of data loss.

10. Ask: Do any policies need to be removed as the business requirements are no longer applicable?
Does your company still have policies surrounding the use of floppy diskettes or laser discs? Did your company change business direction? Keeping old, non-applicable policies is akin to going from the beach to work and changing into your business attire but forgetting to remove your flip-flops.

Policies are foundational building blocks. Developing strong policies that are adhered to, available, and understood throughout the organization goes a long way in constructing a robust security program. I guess you’ll have to find some other way to serve your penance.







0 comments: