Consider this scenario: A multi-national company is revamping its network defenses on a worldwide basis. It locates the relevant internal information systems specialists around the world and engages them in a dialog on how to increase the organization's network security. The enhanced security they seek includes content filtering, intrusion detection and other capabilities not yet deployed.
The budget for the project does not include sufficient resources to handle organizational issues, such as the establishment of a single manager in charge of network security across the organization. Instead, technical staff specifies, selects and deploys hardware and software, thinking that through these system components information security will be achieved. Staff training, documentation, organizational communications channels and other non-technical factors are postponed until the end of the project, and some are then dropped entirely in order to make a deadline and keep resource consumption down.
Although certain managers receive their bonus for bringing in the project on-time and on-budget, the actual level of security delivered is, as a result, significantly lower than it should be. This is due to a lack of effort to integrate business needs with new security functionality and because the organization's ability to effectively manage these new systems is questionable.
MORE BEST PRACTICES FOR WRITING SECURITY POLICIES:
When organizations decide to write a policy after a security system is deployed, they are missing an opportunity to use the policy-writing process as a way to get consensus amongst a variety of different managers about the functionality of these security systems. The very act of writing a policy begs questions such as the impact on the business, the interfaces with related systems, the degree to which there must be end-user involvement and training, as well as the technical capabilities that must be available in order to properly manage the security systems.
When a policy is written before deployment, the policy can direct staff to select hardware and software that genuinely meets collectively-determined business needs. Also, political issues and disagreements about what should be done will be immediately highlighted, and hopefully resolved, all before any money is spent on the involved system. This can help prevent the organization from committing itself to purchasing, leasing, renting or outsourcing certain security capabilities only later to find that these same capabilities are in some way objectionable and inappropriate for the organization in question.
As an example, consider a content management system that can, among other things, examine and log the nature of the Internet material being sent and received by specific workers. If a particular worker is distributing unauthorized copies of copyrighted software, the content management system will note this. At first this sounds good, but the functionality may be a problem for existing privacy policies and laws, depending on the organization and country involved. Before technical staff proceeds to acquire and install such a system, it is important that privacy policies and laws be examined, and that approval is obtained. Then a draft policy about a content management system can be prepared.
In terms of keeping costs down and project timelines short when deploying a significantly modified or new security system, it is best to write policies early. Here are the benefits of doing so:
- Policies help to define the scope of a system, help to clarify the objectives of a system and help to get alignment from all those concerned with the involved system.
- Writing policies prior to deployment forces people to look at issues such as necessary changes in business operations.
- This approach also forces people to communicate their ideas in concrete and explicit terms, particularly when it comes to the business and operational impacts of a new or significantly modified system.
- Writing policies before deployment may also make it clear that project budgets are insufficient, that desired project timelines are overly-optimistic, and/or that technical staff plans are at odds with business reality.
These days most people wouldn't think of building a house without a blueprint and other plans like a permit from a local government authority, but many people still continue to build information systems (which by the way are even more complex) without the benefit of planning documents such as policies.
When you're developing a project plan for the next major security system upgrade, or perhaps the deployment of an entirely new system, be sure to include sufficient time in the early stages of the project to develop policies. Architectures, procedures and configuration standards come later, in part because they are a function of the hardware and software selected. But policies should be vendor neutral and technology agnostic. Policies should talk about necessary control capabilities, affected business processes and required worker interactions with the involved systems. Thus, the overview that policies provide should be one of several early planning tools in every major information security project.
About the author
Charles Cresson Wood, CISSP, CISA, CISM, is an independent information security consultant based in Sausalito, Calif. He specializes in the development of information security documents including policies, standards, procedures and job descriptions. He is also the author of the book and CD-ROM entitled Information Security Policies Made Easy.
