While many organizations are creating security policies, few will implement their policies properly. Fewer still will be able to ensure that all personnel understand the implications of the policy and their related responsibilities. When creating or revising a security policy, there are many considerations, issues and tenets that must be taken into account in order to ensure that the policy will be efficient, effective and usable.
A security policy is a high level statement of intent. It should allow management to make their intent known and understood by all areas of an organization. As such, a security policy will reference common business practices and their related requirements. A policy is not a list of actions required to secure a server, explicit instructions how to engage in electronic commerce, or instructions on how to perform a specific job function; this is the domain of sub-policies and reference documents. Many people make the common mistake of including too much detail in a policy and not segmenting or partitioning the content or details for standards, procedures, baselines and guidelines into individual documents.
One of the most important considerations when creating a policy or a reference document is that it must be distributed to all of the personnel who will, as a result of the policy or reference document, have any portion of their regular business activities impacted or be given responsibilities beyond what they were aware of. This leads into the issue of understanding, as senior management, IT management, system administrators, sales and marketing personnel and administrative personnel will all have different views of security, each with different capabilities to both understand and relate security issues to their functions. A policy must be structured and written such that any persons within the organization will be able to determine how it relates to them and will be able to find and utilize all of the reference documents that apply to them.
When creating reference documents, keep in mind that different resources and business groups will require different types and levels of detail. Referencing an industry standard or best practice will require that the reference document be interpreted for relevance to a particular business group. Referencing a set of procedures will usually only apply to a very narrow set of activities or a small group of personnel. Referencing a baseline for one security mechanism will not necessarily pertain to the requirements of another. Referencing a security guideline that can be interpreted to apply to many different areas, business practices, or technical activities should be very carefully scrutinized, as most guidelines are written with a specific scenario in mind.
The overall resource requirements for the generation or revision of a security policy can be quite significant. It is unreasonable to expect or require that one individual be responsible for maintaining or having all of the knowledge that is required to be included in a policy. A working group with a diverse set of skills and knowledge should handle an organization's security policy. This working group should be ultimately responsible to the CSO (Chief Security Officer), and it is the CSO's -- or senior management's -- responsibility to approve and accredit the security policy for application and implementation within the organization.
Please watch for future tips of the week, in which I will discuss more security issues. In later policy tips, I will provide further details and recommendations for ensuring that specific areas of your security policies are conformant to industry best practice, effectively implemented and applicable to your personnel.
May your information be as secure as a floppy disk in the heart of a volcano.
About the author
Jeffrey Posluns is the founder of SecuritySage, a leading-edge information security and privacy consulting firm. Prior to SecuritySage, Jeffrey founded and co-founded several e-commerce and security initiatives, where he served as President and/or Chief Technology Officer. He is looked to as an authority to speak on information security and privacy related issues and trends at conferences, in law enforcement forums, and in the media. He is a regular speaker at industry conferences organised by such groups as the Information Systems Audit and Control Association (ISACA), and the Association of Certified Fraud Examiners (ACFE). Jeffrey is also a trainer for the Certified Information Systems Security Professional (CISSP) certification course.
