When
Annually at a minimum; more often if you find them out of date during the year.
What
Policies interpret and tailor laws that apply to your organization; serving as a written record for good practices you want to emphasize and enforce in your organization, whether or not there are legal implications.
Why
Policies are general; procedures are specific. You need both: Policies tell you why to do something and standard operating procedures tell you how. In a mature organization, captured repeatable processes enable efficient improvement (see http://www.sei.cmu.edu for examples). For many organizations, policies detail the administrative part of loss prevention -- how to protect what from whom, etc. When designing a system, or upgrading one, the organization should look to the policy. It's especially helpful when an organization has to respond to larger issues, such as mandates from the Health Insurance Portability and Accountability Act, the Sarbanes-Oxley Act and the Federal Information Systems Management Act. How can your policy meet national requirements, for example "…ensure that the agency Chief Information Officer, in coordination with other senior agency officials, reports annually to the agency head on the effectiveness of the agency information security program, including progress of remedial actions…" if it doesn't address these requirements at a local level first? Also, you need procedures for those policy requirements you execute often, to teach new people, and procedures for exception-handling, because you execute them so rarely you forget the details.
Strategy
One large policy document is often used, but a shorter general one followed by topical policies is much easier to update. The top of each mini-policy should show scope, applicable systems, references, effective date, if it supersedes any other policy/procedure, whose authority the policy falls under and a point of contact for questions or future actions. A consequences section should explain the threat or reason for the policy, any legal ramifications if violated and impact if organizational, but not legal policy, is violated. When updating, also note when ideas and practices aren't applicable due to convention or technology. Make it available: Give a copy to each new person as they sign for an account or join the organization; or, distribute it electronically each time there is a significant update to the policy, and don't forget those signed acknowledgements! Set the example: Use what you have asked others to put into practice -- people don't miss much, and they'll notice if you aren't practicing what you preach. Walk around your area and take a look at how people are using, or not using, the policy. This will give you insight into trends, potential problems areas, ideas for training, etc.
More information
More often than not, I look at the references from SANS first. NIST also has many references, and entering "security policy template" in a search engine will bring up a good selection to model yours on. If an organization has posted theirs to a Web site, see what you like and what's useful about it, then incorporate it into yours.
About the author
Shelley Bard, CISSP, is a senior security network engineer with Verizon Federal Network Systems (FNS). An infosecurity professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia. Please e-mail any comments to securityplanner@infosecuritymag.com
Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.
Last week: Training yourself and your IT staff
Next week: Banners in support of system monitoring
