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

Previous issues:
Part 1 of 8 - Introducting Security Policies

Note: The text in this series contains the outline of a training workshop I provided on the subject of "Information Security Policy Development". It is the purpose to improve this framework and allow it to evolve into a more complete documented version of the presentation.


PART 2 - CRITICAL SUCCESS FACTORS FOR SECURITY POLICIES
In the second installment of "What you need to know about Security Policies", I will discuss the purpose, critical success factors of security policies and look at some classification for the different "types" of security policies.


Purpose of Security Policies
Primary Purpose: To inform

• To inform users, staff, and managers of essential requirements for protecting various assets.
• Assets include people, hardware, and software resources, and data assets.
• The policy should specify the mechanisms through which these requirements can be met.

Secondary Purpose: Baseline for improvement

• To provide a baseline from which to acquire, configure, and audit information systems and networka for compliance with the policy.
• To allows for the subsequent development of operational procedures, the establishment of access control rules and various application, system, network, and physical controls and parameters.

Security Policy Goals

• To translate, clarify and communicate management’s position on security as defined in high-level security principles.
• The security policies act as a bridge between these management objectives and specific security requirements.

Benefits of Security Policies
Policies are needed because…

• Policies prevent, or help to manage “the rush to handle information security”
• It is mistakenly believed that security can be handled completely via purchased products and services.
• Management failing to properly delegating responsibility for determining:
  (a) Which risks to accept
  (b) which risks to transfer to others
  (c) which to mitigate through additional controls
  
• Information is a critical information asset.
  Management has fiduciary duty to protect and preserve it.
• Policy development and review allow management the time to consider unique circumstances and appropriate responses.
• Security training and awareness cannot be effective without a security policy.
  

Policies are beneficial because…

• They the least expensive means of control to execute (although they can sometimes be the most difficult to implement). Policy controls cost only the time and effort the management teams spends to create, approve, and communicate them
• Employees need to spend some time integrating the policies into their daily activities.
• Participation in the policy design process is highly beneficial to staff, since it will increase their understanding of the value of information, the risks – and overall reduce the likelihood of a potential security breach through "human-factor" mistakes.

Common Policy Misconceptions
Misconception 1: “Policies are the foundation of an effective Information Security program”

• Not quite. Developing information security policies should be your second step.
  Your first priority is to develop a way to quantify and evaluate risk. You need to know what you are protecting and how much it's worth before you can decide how to protect it.
  

Misconception 2: "The goal of a security policy is to secure the network / computer / information”

• No, the primary goal is to secure the business. Securing the network is easy, but it's not the main goal of a security policy.
• The goal of network security is to protect information and business requirements, using methods that reduce risk.
• Policies describe what you must secure, and the ways you secure them, to support your business or mission.
  
  Firewalls, Intrusion Detection Systems (IDS), anti-virus (AV), backup and restore strategies, locked doors, and system administration checklists are all some of the things you might use.

Misconception 3: Fear sells.

• It may be tempting to use fear as a sales tool. Policies should not be primarily associated with enforcement penalties, and the dire consequences of breaching a policy clause. Keep the security conversation calm and business-focused. Building support for and compliance with policies can be hard.
  

Misconception 4: "Security policies can be written a few days.“

• Perhaps they can, but they are likely to be ineffective. In the long term, they can do more damage than good.
• The opposite is true: Security policy design often requires weeks of testing, meetings and data analysis
  

Misconception 5: "Security policies must be long and complex."

• Security axiom: “Complexity and security are inversely proportional.”
• Complex policies are usually ignored; simple policies might live.
• Just because you put lots of time and effort into writing policies, don't assume your coworkers can or will do the same
  

Misconception 6: If you build it, they will come.

• Right after you post the new corporate information security policies on the company intranet, you notice that your inbox has 843 new messages--all from angry, anxious and confused colleagues who see your "masterpiece" as more of a "disasterpiece."

• New information security policies shouldn't be a surprise to staff and the organization. You need to include representatives from the business units from the start. Write draft policies and ask people how the policies will affect the way their departments do business.
  

Misconception 7: "Security policies have to be nearly perfect, or 100% complete."

• No. Good enough security now is better than perfect security never.
  General George S. Patton said, “A good plan, violently executed right now, is far better than a perfect plan executed next week.”
• It is perfectly fine to build security policies in parts, refining each part separately in the ongoing process of security policy development.
  

Misconception 8: "Security policies only have to be written once."

• Again, Not true. Your organization’s business requires will change.
• Threats to your business will change.
• Vulnerabilities in your organization, processes, systems and resources will change.
• The risks you are willing to take will change.
• Regulations and legislation requirements will change.
  

Therefore, your policies will change.

Critical Success Factors for Security Policies

• Policies must be documented
  Policies must be documented, distributed, and communicated.
  
• Policies must be implementable
  They implementable through system administration procedures, publishing of acceptable use guidelines, or other appropriate methods.
  
• Policies must be enforceable
  They must be enforceable with security tools, where appropriate, and with sanctions, where actual prevention is not technically feasible.
  Unenforceable (and unenforced) policy creates contempt. If policy cannot be enforced via technology, detection of non-compliance via audit and control procedures is an absolute minimum requirement.
  
• Policies must define responsibility
  They must clearly define the areas of responsibility for the users, administrators, and management.
  
• Policies must be flexible
  For a security policy to be viable for the long term, a security policy should be independent of specific hardware and software decisions, as specific systems choices change rapidly.
  
• Policies must be legal
  Policy should never conflict with law. Policy must be able to stand up in court, if challenged.
  
• Policies must be supported
  Policy must be properly supported and administered.
  
• Policies must have the intent to reduce risks
  Policies should not be developed merely to satisfy audit requirements.

Why Some Security Policies Fail
• Security is (perceived to be) a barrier to progress

“Human nature begets desire—for more information, for greater access,
for faster response. Imagine waiting for a traffic light. Obviously, the light exists for safety, but if the intersection is vacant, the light’s “protection” is annoying and wastes time.

Our patience has a limit, and we at some point proceed through the red light,
under the assumption that the light is broken, or the guise that the wait time
was unacceptable.

Every network user reaches a “red light” limit with compliance as well.
At some level of annoyance, we conclude that compliance is ultimately
not in our own self-interest.

Policy plans, rarely measured by impact on users and the business
process, can lead—at least—to a false sense of security. Worse,
disparate compliance can result in a security breach.
If you give up on the red light just as another car approaches on the green…”

- Control Data “Why Security Policies Fail” (Control Data, 1999)

Failure to manage people’s negative perception about security policies.

People view policies as:

• an impediment to productivity
• measures to control behaviour
• People have different views about the need for security controls.
• People fear policies will be difficult to follow and implement.
• Policies affect everyone within the organization. (Control Data, 1999)
  

Other reasons why corporate information security policies fail include...
1. Security is a Learned Behavior

• Self-preservation is instinctual behavior; securing assets is not.
  It is a higher-level function that must be learned and occasionally reinforced.
• Management must be taught the value of information assets, the risks associated with these assets, and the appropriate protection policies.
  

2. Expect the Unexpected

• The more complex a policy or process is to accommodate these users, the more likely it is to fail.
• A good security officer expects failures and disasters, and constantly checks the radar for signs of “bad weather.”

3. There Is No Perfect Mousetrap

• You can never be finished. Securing assets is a continuous process.
• Every process and policy should undergo regular health checkups in good weather and in bad.
• Technology is rapidly changing; systems become outdated, and security either fail or lose effectiveness over time.
• Threats will always exist and adapt.
• Policy and procedures must also grow and change to remain effective. (Control Data, 1999)

Issue-Specific Security Policies
Issue-Specific Security Policy policies are typically limited to the system (or systems) affected and may change with changes in the system, its functionality, or its vulnerabilities.

It contain sets of security rules that applies to specific domains (application, business unit, geography, etc.) and which must be adhered to by all persons accessing these specific domains.

In general,

• Issue-specific policies are formalized as written documents and is readily identifiable as policy.
• Issue-specific policies addresses issues of current relevance and concern to the agency.
• Issue-specific policy statements are likely to be limited, particular, and rapidly changing. Their promulgation may be triggered by a computer security incident.

Examples of Issue-Specific policies:

• Password Policy
• 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)
• Responding to security incidents.

An Issue-Specific policy will usually be subject to various generic policies — referencing these generic policies (rather than respecifying it) enables scalability and flexibility.

Systems-specific policies (SysSPs)
Systems-specific policies frequently do not look like other types of policy.
They are often created to function as standards or procedures to be used when configuring or maintaining systems, and can be separated into two general groups:

• management guidance and
• technical specifications

or they may be combined into a single policy document.

Management Guidance SysSPs
Created by management to:
- guide the implementation and configuration of technology, and
- address the behavior of people in the organization.

Technical Specifications SysSPs
Used to translate management intent for a technical control into an enforceable technical procedure.

There are two general methods of implementing such technical controls:
Access Control Lists
Access control lists (ACLs) include the user access lists, matrices, and capability tables that
govern the rights and privileges of users.

Configuration Rules
Specific configuration for security systems to guide the execution of the system.

This concludes the second part of this eight part series on Understanding Information Security Policies. In the next issue, part 3 I will discuss the various policies types what you should know about the actual development of security policies.

Regards,

Ciske

References:
Mattord, H. J. Whitman,M.E. (2004) Teaching Information Security Policy
- Proceedings of the 8th Colloquium for Information Systems Security Education



Next issues in the series "What you need to know about Security Policies" :
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 of 8 - Policy Structure and Approach

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

A common challenge for information security management professionals, is the development, execution and maintenance of corporate information security policies. I have developed and deployed many security policies over the past decade, and accumulated several "information security policy gems", which I will share with you in the following couple of posts.

Note: The text in this series contains the outline of a training workshop I provided on the subject of "Information Security Policy Development". It is the purpose to improve this framework and allow it to evolve into a more complete documented version of the presentation.

INTRODUCTION TO SECURITY POLICIES

For many security professionals, and security officers who are inexperienced in the development of security policies it can be a challenge to know how to go about structuring a security project, and to know how to define the scope of the policy. In this series, I will cover many aspects of corpotate information security policy development projects.

Section 1 - Introduction to Policy Projects

• Developing a Project Plan
• Objectives, Scope, Participants & Resources

Section 2 – Understanding Information Security Policies

• Fundamental Concepts: Policies, Standards & Procedures

Section 3 – Principles of Security Policy Development

• Development Approach
• Risk Analysis Methods for Policy Development
• Policy Sources and Templates
• The Art of Policy Writing

Section 4 – Security Policy Implementation

• Policy Dissemination & Communication
• Security Awareness

Section 5 – Policies Management

• Policy Maintenance
• Change Management
• Scheduled Policy Reviews

In the policy development literature, the few books that have been written specificaly on information security policy development, does not offer significant insight and guidance on the development of a comprehensive policy development project plan, not much of best-practice development techniques. I will elaborate my views on this, as well as other interesting topics such as the "policy communication project plan", and my thoughts on policy management (maintenance and change control).

Structuring a Corporate Security Policy Project

Perhaps the most important success factors of security policy projects are knowing how to structure the project, knowing how to define the scope, and following a well-designed development and execution plan. These steps lay the foundation for the communication and future management of the policies. I will explain these concepts.

Security Policy projects are complicated. The development and implementation of information security policies usually more complicated than expected. It requires a high-level as well as a detailed understanding of the business.

You will not succeed if you restrict your analysis to the I.T. business environment. It is essential that you also obtain a thorough understanding of all the business activities, particularly any activities and business practices that contribute to risk. Often, you are required to spearhead changing perceptions about risks and information security throughout the organization.



Organization wide involvement is vital

• Policies should never be developed alone, in seclusion.
• Development demand the correct mixture of experience, skill and knowledge.

SECTION 2 - UNDERSTANDING INFORMATION SECURITY POLICIES

SECTION OVERVIEW:

2.1 Understanding Security Policies
• Defining “Security Policy”
• Key criteria (legal, etc.)
• Difference between policies, standards & procedures

2.2 Policy Types
• Enterprise
• Issue-Specific
• System-Specific

In this sestion, I will cover the following:

2.1 Understanding Security Policies
2.1.1 Defining “Security Policy”
2.1.2 Difference between policies, standards & procedures
2.1.3 Purpose of Security Policies
2.1.4 Benefits of Security Policies
2.1.5 Common Policy Misconceptions
2.1.6 Critical Success factors of Security Policies
2.1.7 Why some policies fail
2.1.8 Key criteria (legal, etc.)

Defining “Security Policy”
In its simplist definition,k security policies can be defined as a combination of several things; such as management instructions, plans, rules etc.

• Management instructions
  It is the formal documentation of management decisions about information security, and the primary way in which management's expectations for security are translated into specific, measurable, and testable goals and objectives.
  

• A Plan
  Policies is plan, or course of action, intended to influence and determine decisions, actions, and other matters.
  

• Rules
  Policies are a set of rules that dictates acceptable and unacceptable behaviour within an organization.
  

• Policies are mandatory
  Opposed to standards and guidelines which are not necessarily mandatory.
  

• General statements - not specific
  Policies are more general than standards and procedures.
  

• Independent
  Policies are product and vendor independent
  

• Include Penalties
  Policies must also specify the penalties for unacceptable behaviour, and define an appeal process.
  

What a policy is NOT:

• The security policy defines what business and security goals and objectives management desires, but not how these solutions are engineered and implemented.
• Policies are not detailed statements explaining how controls should be implemented or management..
  For example: Information security policies are not systems settings for firewalls and other system components.
• Policies do not included detailed, step-by-step technical standards and procedures.
  

Difference between policies, standards & procedures

Security Policies:

• Security policies embody management’s overall security expectations, goals and objectives.
• To be practical and implementable, policies must be further defined by standards, guidelines, and procedures.
• While the policies should not often change, the various standards and procedures do often change.
  

For example:
A policy can be an organization’s prohibiting the viewing of inappropriate Web sites at the workplace. To execute this policy, the organization must implement a set of standards that clarify and define exactly what is inappropriate in the workplace and to what degree the organization will act to stop the inappropriate use.

Security Standards:

• Security Standards are directives derived from generic or specific policy, designed to structure and guide the implementation of the policy.
• Standards are more detailed statements of what must be done to comply with policy, and provide specific interpretation of policies.
• Standards that provide more measurable (“auditable”) guidance in each policy area.
  

For example:

A standard might specify that user names must be unique, and passwords must contain a minimum of six characters with at least one non-alphabetical character. Standards also cover both non-technical and technical requirements. An effective policy framework would include technical security standards to provide detailed system hardening and configuration requirements (as standards) for various system and network infrastructure and applications.

Security Procedures:

• Security procedures also provide specific interpretation of policies and the standards.
• It instruct users, customers, technicians, management, and others on how to implement the policies.
• Procedure documents are environment-specific and is needed for each technology used by the business.
• It specifies in detail how the Security Standards are to be implemented by that technology.
  

Security Guidelines:

• Guidelines are documented best practices and recommendations for addressing the security needs of domains or resources not covered by formal policy.
• Often, these are “standards in waiting” in the process of being developed and ratified.
• They are not requirements to be met, but are strongly recommended.
  

This concludes part one of this eight part series on Understanding Information Security Policies.
In the next installment, part 2, I will discuss the various policies types what you should know about the actual development of security policies.

Regards,

Ciske
CISKE@INFOSECRISKS.COM

References:
Mattord, H. J. Whitman,M.E. (2004) Teaching Information Security Policy
- Proceedings of the 8th Colloquium for Information Systems Security Education


Next issues in this series "What you need to know about 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 of 8 - Policy Structure and Approach