Be easy to understand.
It's important that security policies meet the requirements of the intended audience, which typically is a general-use audience. All too often, policies, standards and procedures are written by subject matter experts, and the material is written at a college-level when it should be geared for average reading and comprehension. For example, a security policy that says, "Timely patching is critical to maintain the operational availability, confidentiality and the integrity of IT systems," is more easily understood than saying, "Hotfix Checker is a command line tool written to assess the patch status for Windows NT 4.0 and Windows 2000, and Internet Explorer 5.01 and later." Be applicable.
When creating policy, some writers will research another organization's security policy, such as an acceptable-use Internet policy, and copy that document verbatim. However, it's important to ensure that what gets written meets the specific security needs of your organization. (For example, your organization may require restrictions on file downloads.) Be enforceable.
Don't write a self-defeating policy. A policy may state, "Use of the company-provided
- e-mail system is for business purposes only." For most organizations, this rule may in fact be the policy, but almost every e-mail client on the network is used daily for personal messages. What might make a better policy is one that says "Company-provided e-mail is to be used for management-approved functions only," which provides some latitude, yet still meets the business need.
Be phased in.
It may be necessary to allow the organization to read and digest the policy before it becomes effective. Many organizations publish a security policy, and then require each business unit to submit a compliance plan within a specific number of days after publication. This approach is a good strategy. It provides the business unit managers a period of time to review the policy, determine where their organization may be deficient, and then submit a timetable for compliance. It builds in allowance time for purchasing and deploying technologies, and training users. These compliance plans can also be kept on file and made available to the audit staff. Be proactive.
State what can be done and what's expected of the employees, rather than making pronouncements -- "Thou shalt not … !" For example, a policy could say, "This computer system is designated for access only by authorized financial system users. Unauthorized access attempts will be investigated and appropriate action, up to, and including prosecution, will be taken." Avoid absolutes.
Never say "never." Be diplomatic and understand the politically correct way to say things. When discussing sanctions for noncompliance, it's limiting to say, "Employees violating this security policy will be subject to dismissal without warning." Rather, a kinder, gentler approach could add leeway. For example, "Employees found in noncompliance with this security policy will be deemed in violation of the Employee Standards of Conduct, which requires an investigation and appropriate disciplinary action to be taken, up to, and including dismissal." Be doable.
Can the organization and/or its employees still meet business objectives if the policy is implemented? Many organizations think they have written the "ultimate" security policy, only to find out that its restrictions place the business mission at risk. You should remember that, while some controls (i.e., two-factor authentication, running and updated firewall software) can help the organization reach an acceptable level of risk, a 100% security program requirement could mean zero percent productivity. Whenever controls or policy impact the business objectives or mission of the organization, the controls and policy will always lose; security policies exist to support the business, not the other way around.
The bottom line in policy creation is to keep it simple. The number one selling newspaper in the United States is USA Today. Why? Because the articles are brief and the language is clear and concise. When creating policies, use the newspaper's model of "McNews" to appeal to the masses and meet your organization's policy objectives. Save your longer, complex arguments for your network security doctorial thesis.
About the author
Tom Peltier has been an information security professional for more than 25 years. He has written books on information security policies and contributed to several books on CISSP preparation, and computer and data security.
- You shouldn't be developing your organization's security policies by yourself. Find out who should be sharing the responsibility in this tip.
- Learn what components should be included in each of your Tier-1 Policy statements.
- Thomas offers an overview of Tier-1 Policies, beginning with this tip.
This was first published in October 2004