If you follow the advice of serious security professionals in formulating security policy documents, you'll find that you wind up with a veritable library of documents for vendor, remote access, acceptable use, physical security and other policies (see the collection of recommended items and examples available through the SANS Security Policy Project, for instance). This raises two interesting questions:
- How should this collection of documents be maintained?
- When should individual documents be updated?
If there's any area of security policy where the "do as I say, not as I do" principle comes into fullest play, it's in the difference between what prudent security practices dictate should be done as compared to what day-to-day exigencies determine will actually happen. Best security practices specify that as various elements of the environment change, so should the documents that deal with relevant security policy. Included among the nearly infinite number of events that should lead to policy document dates, you'll find these typical items:
- Patches, fixes or updates to operating systems, software or boundary devices.
- Business changes including moves, mergers, acquisitions or divestitures.
- Migration from one platform or implementation to another, particularly where boundary devices or Internet services may be concerned.
- Changes in vendor or customer relationships where remote or intranet access may be affected.
I could go on for a long time in this vein, but you should have the idea firmly fixed by now that when circumstances and relationships change, security policy documents are supposed to follow suit.
What usually happens, however, is that while environments do change, policy documents don't always track such changes in real time. Because outsiders (whether they belong to, or otherwise work for an organization) will often turn to security policy documents first when dealing with security matters, such divergence can cause real problems!
Though the solution is painful and can be expensive in terms of time, resources and effort, the only workable solution is to require regular periodic reviews of policy documents as they compare to "security on the ground." Better still are software and systems management tools that manage security elements along with others and are smart enough to recognize that security policy changes may be required when certain elements or relationships change in an organization's environment. At a minimum, an e-mail reminder to "review and update remote access policy" might be generated when administrators start making sweeping changes, introduce new servers or provide access to a new customer or partner, to give just one minor example.
If an automated linkage between security policy documents and security policy manifestations isn't easy to create or maintain, regular reviews become essential. Typical frequencies for such reviews vary from two weeks to quarterly, depending on the size and complexity of operations involved. Generally, however, if an organization is big enough to afford in-house or contract security professionals, more frequent reviews help security policy do its intended job -- this is, of mapping organizational risk assessments and mitigations, along with policy and procedures designed to protect key assets -- better than less frequent ones.
Please feel free to e-mail me with feedback, comments or questions at etittel@iLearning.com.
About the author
Ed Tittel is VP of Content Services at iLearning, a CapStar company, and is based in Austin, Texas. As the creator of the Exam Cram series, Ed's worked on numerous titles on Microsoft, Novell, CompTIA and security certifications, including Security+, CISSP and TICSA.
For more information, visit these resources:
