What you should know about Security Policies (Part 6 of 8)

Previous issues:
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

What you need to know about Security Policies (Part 5 of 8)

Previous issues in this series:
Part 1 of 8 - Introducting 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 - SAMPLE SECURITY POLICIES AND TEMPLATES
Overview
This installment of the "What you need to know about Security Policies", provides an overview of some essential considerations when obtaining source material for your own development of security policies. I provide a souple of suggestions for policy resource material, and discuss the use of policy templates.

Security policies should be based on several sources, which can include:
1. International Information Security Standards
a.) ISO/IEC 17799:2005
b.) NIST standards
c.) The I.T. Baseline Protection Manual
This standard is particularly useful as reference for the development of security procedures and guidelines.

2. RFC’s
a.) The Site Security Handbook - RFC2196.

3. Information Security Principles
a.) OECD - Organisation for Economic Co-operation and Development - http://www.oecd.org/
b.) GAISP - The Generally Accepted Information Security Principles (http://www.issa.org/)

4. Security Policy Books
Security Policy Books such as:
a.) Information Security Policies Made Easy by Charles Cresson Wood (“ISPME”), and others - as discussed below.

5. Sample Security Policies
Sample security policies available on the Internet, such as “The SANS Security Policy Project” - a reference which should be used with due care.

INFORMATION SECURITY PRINCIPLES
Security principles are used to define a foundation upon which security policies can be further defined.Organizations should evaluate and review these security principles before and after the development and elaboration of security policies. This will help define and satisfy management's expectations for security, and fundamental business requirements - during the development and management of the security policies. Sources: Organization for Economic Cooperation and Development (OECD)Generally accepted information security principles (GAISP ver 3.0 - ISSA)

PERVASIVE PRINCIPLES

1 - Accountability Principle
2 - Awareness Principle
3 - Ethics Principle
4 - Multidisciplinary Principle
5 - Proportionality Principle
6 - Integration Principle
7 - Timeliness Principle
8 - Assessment Principle
9 - Equity Principle Obtaining Security Policies

BROAD FUNCTIONAL PRINCIPLES

1 - Information Security Policy
2 - Education and Awareness
3 - Accountability
4 - Information Management
5 - Environmental Management
6 - Personnel Qualifications
7 - System Integrity
8 - Information Systems Life Cycle
9 - Access Control
10 - Operational Continuity and Contingency Planning
11 - Information Risk Management
12 - Network and Infrastructure Security
13 - Legal, Regulatory, and Contractual Requirements of Information Security
14 - Ethical Practices Obtaining Security Policies

INFORMATION SECURITY POLICY BOOKS
The following is a list of the most popular books written on information security policies, currently available:

Information Security Policies, Procedures, and
Standards: Guidelines for Effective Information Security Management
by Thomas R. Peltier
Paperback: 297 pages Publisher: AUERBACH; 1 edition (December 20, 2001)
ISBN-13: 978-0849311376

Writing Information Security Policies by Scott Barman
Paperback: 214 pages
Publisher: Sams; 1ST edition (November 9, 2001)
ISBN-13: 978-1578702640

Information Security Policies and Procedures: A Practitioner's Reference, Second Edition (Hardcover) by Thomas R. Peltier
Hardcover: 448 pages Publisher: AUERBACH; 2 edition (May 20, 2004)
ISBN-13: 978-0849319587

Information Security Policies Made Easy, Version 10 by Charles Cresson Wood
Hardcover: 739 pages Publisher: Information Shield (May 2005)
ISBN-13: 978-1881585138

Description:
This book Can be used as a framework for the creation of a comprehensive set of information security policies.Version 10 of ISPME contains more than 1350 pre-written security policies. The book includes a CD-ROM that includes every policy - in HTML, Word, and PDF formats The policies are divided into 10 separate domains that are mapped to the ISO-17799 standard.

Note: While it may be tempting to immediately start cutting and pasting policies together, it is crucial to understand both

what the policies do and what you want to accomplish with them before you begin.

SAMPLE SECURITY POLICIES
Common sources for obtaining sample information security policies include:

Internet SANS
Policies from the SANS Institute, Security Policy Project
A website dedicted to "SysAdmin, Audit, Network, Security"
Internet: http://www.sans.org/resources/policies/

RU Secure
The Security Policies & Standards Group, Deepdale, Preston, UK.
Internet: http://www.information-security-policies-and-standards.com/.

THE USE OF TEMPLATE POLICIES
Disadvantages of using Policy Samples and Templates
Given the time constraints we all tend to work under these days it is very, tempting to adopt template policies rather than research and write your own. A policy quickly delivered - may achieve short term gain for your organization but, in the long term, may well not be broad and deep enough to properly protect your organization’s information assets from the wide range of potential threats.

Advantages of developing your own policies
The benefit of researching and writing your own policy is that the very act of doing so increases your knowledge of what your organization is about, how things work, who does what, what the I.T. infrastructure is, how it may evolve. You may well find that many assumptions you thought to be correct are indeed not so.

POLICY COMPLIANCE TO SECURITY STANDARDS
Policy Focus
Policies should be focused on addresses information security risks. At best your information security policy should deal solely with information security. This may sound “rather obvious”, however some organizations require their security policies to encompass what may loosely be describe as behavioral, or moral policy. For example: issues such as sexual and ethnic harassment issues may be important in their own right, they are not directly relevant to information security.

ISO/IEC17799:2005 Code of Practice for Information Security on Security Policies:
Clause 5 - Security policy 5.1 Information security policy

Objective:
To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations. Management should set a clear policy direction in line with business objectives and demonstrate support for, and commitment to, information security through the issue and maintenance of an information security policy across the organization.

5.1.1 Information security policy document
Control
An information security policy document should be approved by management, and published and communicated to all employees and relevant external parties.

Implementation guidance
The information security policy document should state management commitment and set out the organization’s approach to managing information security. The policy document should contain statements concerning:

a) a definition of information security, its overall objectives and scope and the importance of security as an enabling mechanism for information sharing (see introduction);

b) a statement of management intent, supporting the goals and principles of information security in line with the business strategy and objectives;

c) a framework for setting control objectives and controls, including the structure of risk assessment and risk management;

d) a brief explanation of the security policies, principles, standards, and compliance requirements

of particular importance to the organization, including:
1) compliance with legislative, regulatory, and contractual requirements;
2) security education, training, and awareness requirements;
3) business continuity management;
4) consequences of information security policy violations;

e) a definition of general and specific responsibilities for information security management, including reporting information security incidents;

f) references to documentation which may support the policy, e.g. more detailed security policies and procedures for specific information systems or security rules users should comply with. This information security policy should be communicated throughout the organization to users in a form that is relevant, accessible and understandable to the intended reader. (Weise, 2001)

References:
Weise, Joel (2001) Developing a Security Policy - SUN
Wood, C.C. (2004) InfoSecurity Infrastructure Inc. RSA

Next in this series:
Part 6 of 8 - Policy Structure and Approach

What You Should Know About Security Policies (Part 4 of 8)

Previous issues:
Part 1 of 8 - Introducting Security Policies
Part 2 of 8 - Critical Success Factors
Part 3 of 8 - Policy Development


PART 4 - RISK ASSESSMENT FOR SECURITY POLICIES
In this installment of "What you need to know about security policies", we cover the following concepts on conducting a risk analysis (RA) for policy development, including the reasons for RA, and Risk assessment and analysis methods.


Reasons for Risk Analysis
Essentially, Risk Analysis it is the process of defining exactly WHAT you are trying to protect, from WHOM you are trying to protect it and most importantly, HOW you are going to protect it. The risk management approach to Information Security involves identifying, assessing, and appropriately mitigating vulnerabilities and threats that can adversely impact the information assets of the organization.

For a in-depth look at risk analysis, refer to my previous posts on "Fundamental Risk Management Concepts".

Apart from the mere identification of risks, there are several significant reasons risk analysis and assessments to be part of your security policy development effort:

• The prioritization of risks.
  Ensure that important matters are addressed, for budgeting and action plans.
• Identify management processes that are lacking or broken.
• To set or reference a baseline.
  Has security improved over time, or does it need more resources?
  
• To confront overly optimistic managers with reality.
• To gather information for security control enhancements to be justified.
• Show compliance against regulations and laws and contracts.
  Generate due diligence evidence to protect against lawsuits.

Indirectly sell information security to senior management.
The appropriate and cost-effective mitigation of risk requires that an organization address security objectives and costs in tandem with business and operational goals.

Blindly applying technology to protect against every conceivable threat is not the smartest way to deal with security. A better way is to identify how much business risk each threat poses — how vulnerable are you really, if a particular threat occurs?

This way of thinking helps you minimize security implementation costs, and provides the flexibility you’ll need to help you evaluate new threats. By considering the business risks, as well as the out-of-pocket expenses and time required to fix each new vulnerability, you’ll be able to make an intelligent business decision about whether it makes sense to mitigate the threat.
Note that your exposure is proportional to how long it takes to fix the problem, multiplied by the level of risk involved. (RSA)

How does risk analysis empower policy writing?
Risk analysis establishes a reference point along spectrum of possible policies.Personal use of organization I.T. resources . (Wood, 2004)


Risk Analysis Methods

For example, one formal approach to risk analysis is:

• OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) - http://www.cert.org/octave/

Asset Identification and Valuation
Assets While the other sections are important, the value of the security policy is ultimately related to the assets it is protecting. As a result, a company must perform an in-depth audit of their resources to determine what constitutes as an asset and more importantly, the value of that asset.

Risk Management and policy development

• Identifying risk priorities
• Policies and the risk treatment plan
• Mapping policies to identified risks
  

In the next installment, Part 5 of 8 - Policy Development Sources of this series on "What you need to know about Security Policies", I will cover "Sample Policies and Templates".

What you need to know about Security Policies (Part 3 of 8)

PART 3 - SECURITY POLICY DEVELOPMENT
This is part three of a eight-part series on the development of corporate Information Security Policies. In part one, we covered the basic concepts on what goes into a security policy development. In part 2, we discussed some of the critical success factors of security policy projects. In this section, we will review the details around what a security policy development project need to be successful.


Security Policy Development
In this post, I will cover the following:

• Forming development committee
• Development models
• Deciding on a Policy Stance

Policy Development Committee

It is seldom useful to try and develop a corporate information security policy by yourself. The following is a suggested ouline of the recommended security policy development project steps.

(adapted from Weise, Joel (2001) Developing a Security Policy - SUN)

See: "Security policies: Don't be an army of one" by Harris Weisman


Identify Committee Members

• Establish a core policy development team
• Organization wide input

Roles and Responsibilities
In general, it is recommended that the following areas participate in this development effort:

• Business management
• Technical management
• Data security
• Risk management
• Systems operations
• Application development
• Network engineering
• Systems administration
• Internal audit
• Legal
• Human resources (Weise, 2001)

Recommended Development Project Outline
The following can be used as a high-level development outline for the development team task list:
1. Identify Organizations and Stakeholders

• Organization structure, security policy owners
• As minimum include departments: security, legal, HR, internal audit, operations.
  

2. Outline Primary Business Objectives

• Important for scoping security policy
• Regulatory requirements may be applicable to one business unit, but not other units.
• Make Security Policy Cost-Effective
  

3. Outline a list of security principles representing management’s goals

• State in a plain and simple fashion, without technical details or jargon, what core values are most important to your organization. (Weise, 2001)

4. Data / asset identification and classification

• Depending on the development model selected (Data-, or Asset-centric)

5. Risk Analysis

• Analysis of assets, threats, vulnerabilities, impacts.
• Analysis of primary security controls required
  

6. Generic Policy Statement

• Formulation of a generic policy statement

7. List of Security Policies is defined

• A sample list of recommended focus areas

8. Drafting of policies

• Formulating the various types of policies

Development Models
There are various security policy development models that can be applied.

Data-Centric Model
The types of data, its ownership and classification is considered. I will briefly discuss two of them.

• Focus on the protection of data and information.
• Identify, classify and catalogue all primary data entities
• Data flow analysis
  - lifecycle: from generation to deletion
  - identify all the trust points (i.e. in transaction processing data flow through web servers, firewalls, paper copies)
  - then, identify placement of logical and physical controls.
  

Control Objectives Model
Policy categories can be patterned by segment controls around broad risk mitigation objectives such as:

• Avoid
• Detect and deter
• Mitigate
• Recover
• Correct

Policy Stance

The policy committee should evaluate and agree on a policy stance. This decision is critical to the planning, Implementation and monitoring of the security policy. It may not be practical to define once stance that applies to all the aspects of the entire policy. Different stances may be applicable to different security environments.

Typically, the stance can be one of the following:

Promiscuous: Everything is permitted.

• In effect, this equates to having no security in place.

Permissive: Everything not explicitly prohibited is permitted.

• This is considered a high-risk stance since the default is ‘to allow’.
• For security to be effective under this stance, your prohibited list & associated configurations must be fully up to date at all times.
  

Prudent: Everything not explicitly permitted is prohibited.

• This is considered the best option for commercial organizations, since the default action is ‘deny’.
• Forgetting to expressly permit something carries minimal risk.
  

Paranoid: Nothing is permitted.

• Whilst this is the option of choice for military, health service and some security service type organization it compromises the ‘Availability’ target and is therefore often not acceptable in a commercial organization.
  

Principle of “least privilege”

• In general, a stance of “least privilege” can be used in most commercial, financial, Internet, and governmental environments.
  

A typical security stance statement may be:

"All data defined as confidential must be protected on a need to know basis only to properly identified and authenticated entities, in all of its forms and on all media, during all phases of its life, from generation to destruction, such that it cannot be compromised, released to any unauthorized entity, or otherwise have its confidentiality or integrity placed at risk.
All processing resources, including all applications, systems, network, hardware and software, are only accessible on a need to know basis, only to properly identified and authenticated entities." (Weise, 2001)

That concludes part 3. In the next edition, part 4, we will look at the role of risk assessments in security policy management.


Regards,

Ciske

References:
Weise, Joel (2001) Developing a Security Policy - SUN


Next in this series:
Part 4 of 8 - Risk Assessment for Security Policies
Part 5 of 8 - Sample Security Policies and Templates
Part 6 of 8 - Policy Structure and Approach