Part 1 of 8 - Introduction to Security Policies
Part 2 of 8 - Critical Success Factors
Part 3 of 8 - Policy Development
Part 4 of 8 - Risk Assessment for Security Policies
Part 5 of 8 - Sample Security Policies and Templates
PART 6 - POLICY STRUCTURE AND APROACH
Overview
This installment provides an overview of:
- Deciding your Development Approach
- Suggestions for improving your policy documentation layout
- structuring your policies (components of Enterprise vs. Issue-specific policies)
DEVELOPMENT APPROACH
Fundamental Principles:
A first attempt at developing and introducing a corporate security policy should be kept simple and short. One reason for lowering the bar, rather than raising it too high, is because people change more slowly than technologies. It is recommended that you take baby steps toward your first enterprise-wide adoption.
- Focus on what is unique about a policy and include scope and applicability; objectives; rules; enforcement and verification.
- Don't spend too much time on the development recyclable elements, such as definitions, roles and responsibilities and violations reporting. Define the policies once, and re-use it (cut and paste to other policies).
- Be generous with your review cycle, and put a lot of effort in reviewing the policy. Pay a lot of attention to the initial step, which is conducting a risk assessment.
- Once you've written a policy, first have the security group review it. Next, have IT specialists examine the document, and finally, senior management should weigh in.
The development of security policies can be approached in different ways; typically "Top-down" or "Bottom-up".
Top-Down Approach
- Use ISO/IEC 17799 as framework for the development of the policy.
ISO17799, in common with most methodologies originally designed for industrial and business contexts, is a "top-down" approach based on management controls. - There are obvious advantages in conforming to a standard which is widely recognised.
For example:
The requirement for users of personal data, under the European Data Protection Act,
to have in place a security framework which will give adequate protection to personal data throughout the lifecycle of those data (i.e. from collection to destruction).
Bottom-Up Approach
- The "bottom-up" approach to developing security policies requires that much of the initiative for the detailed implementation should come from the practitioners themselves (individual departments and employees).
- This approach may sometimes be easier to achieve in practice.
For example: A the large, traditionally-structured organization where a great deal of responsibility is delegated to individual departments (as opposed to a security department that attempts to bring about change towards a culture of security).
Adapted from source: Charles Cresson Wood (2004) InfoSecurity Infrastructure Inc.
POLICY DOCUMENT LAYOUT
Modular Structure vs. Singular Structure
Modular Structure
Barman suggests: “rather than trying to write one policy document, write individual documents and call them chapters of your information security policy.”
- This is a modular approach, with only one level of granularity.
- A modular structure provides a balance between issue orientation and policy management. The policies created via this approach are individual modules, each created and updated by individual persons responsible for a specific issue.
These individuals persons report to a central policy administration group that incorporates these specific issues into an overall policy.
Balance Privileges and Responsibilities
When developing a policy, you should attempt to obtain balance between privileges and responsibilities:
Side 1: Policies which are too restrictive are unlikely to be successful
Side 2: Policy which is too lax will leave the organisation open to abuse.
Policies Define Acceptable Behaviour
On the human front, the policy must define what behaviour is and is not allowed, by whom and in what circumstances. A policy must contain and define the following:
- Purpose (What needs to be done, what needs to be protected).
- Place (Where it needs it to be done).
- Time (When it needs it to be done).
- Organizing (Who needs to do it).
- Method (How it needs to be done – by referencing standards and procedure documents).
Level of Detail
An early decision to be taken in drafting a security policy is the level of detail it should contain. It is strongly recommended that organization with a new set of policies should adopt a structure with a short, easily understood high-level policy document – intended to be read and accepted by all employees – supported by a number of more specific documents.
COMPONENTS OF AN ENTERPRISE SECURITY POLICY
Though the specific content of an Enterprise Information Security Policy (EISP) vary from organization to organization, most EISP’s include:
Endorsement
You must include a written endorsement of the Chief Executive Officer.
Statement of Purpose
Answers the question “What is this policy for?” and provides a framework for the reader to understand the intent of the document.
It should assure the reader that the purpose of the policy is not to provide a legal foundation for persecution or prosecution, but to provide a common understanding of the purposes for which an employee can and cannot use the information, and information technology
The value of information
Discussion of the new and critical role of information- An overview of the corporate philosophy of security
Security Role
Information on the structure of the information security organization and individuals that fulfill the information security role.Security Risks
Review security risks in a high-level way.
Responsibilities
a.) Fully articulated responsibilities for security that are shared by
all members of the organization- With reference to an Acceptable Use Policy that
contain statements of what to do, and what not to do.
b.) Fully articulated responsibilities for security that are unique to each role within the
organization.
References
Cross references to other more specific security policy, standards
and guidance documents.
Components of an Issue-Specific Security Policy
Some examples of Issue-Specific policies include:
• Electronic mail
• Use of the Internet and the World Wide Web
• Home use of company-owned computer equipment
• Use of personal equipment on company networks
• Use of telecommunications technologies (fax, phone)
In the next edition, I will discuss "Policy Statement Formulation".
Regards,
Ciske
