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