In my previous securit tip on IT security policies, I explored the many reasons administrators should strive to
design security policies that require a minimum amount of change over time. I also discussed several strategies that you can utilize to help achieve this goal.
Unfortunately, change is inevitable. No matter how well you design your policy, the time will come when it no longer successfully balances the business requirements of your organization with the security measures necessary to protect your infrastructure and data against the evolving threat landscape. It's critical that you have a well-designed process in place to handle change in an organized fashion when the time to change arrives.
Let's take a brief look at a five-step process designed to help your organization approach change in a formal, yet flexible fashion. The questions below should help stimulate your brainstorming process as you develop your own change control policy.
Step one: Change request submission. What's the process that individuals in your organization should follow to submit a request for a change in the organization's security policy? Is this process separate and distinct from the process used to request a temporary or permanent waiver of the policy when an exception is warranted?
Step two: Change request review. Who must review requested security policy changes? Is there a certain level of approval required within the requestor's business unit prior to formal consideration of the change request? When the change comes up for formal review, who serves on the committee that evaluates the request? Does it consist of both technical and business unit representatives? Is management represented on the committee?
Step three: Change request approval. What is necessary for final approval of a change request? Does a majority vote of the committee have decision-making power? Is there a representative in senior management that has the final say on all committee recommendations?
Step four: Change request implementation. Once the committee approves a change request, who is responsible for ensuring its proper implementation? Does the committee follow up with the appropriate functional area to ensure that the change took place and that there were no unintended consequences of the change?
Step five: Change request feedback. Your job isn't finished after the change implementation is complete. Take the time to review the change request and determine what aspect of your security policy made it necessary in the first place. Are there portions of the policy that are too specific or don't address current business needs? You may be able to stem the tide of future change requests through this type of analysis.
Take the time now to formalize this change control procedure or a similar process based upon your organization's requirements. The effort required to put these steps in writing may very well save you from significant administrative headaches down the road.
About the author
Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the About.com Guide to Databases.
IT SECURITY POLICY MANAGEMENT
Introduction: IT security policy management
Defining IT security policy roles
Planning for an effective IT security policy
Setting up an IT security policy
Implementing a group IT security policy
Managing change in IT security policies
IT security policy management: Manual vs. automated tools