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