Writing security policies using a taxonomy-based approach

Forget structure-driven policy architecture; we'll show you how to build information security policy artifacts using a taxonomy approach that will help you build global policies in a snap.

This Content Component encountered an error

Today's policy artifact landscape has become much more complex given the regulations they must complement and support. Additionally, the complexity of information systems and technology has increased with the advent of the geo-distributed architecture of cloud computing which requires a global perspective for policy development.

Policies are a system of authoritative artifacts deployed to protect an organization's information assets. Specifically, authoritative artifacts are documents against which an organization executes and operates. Our intent is to provide information security professionals with methods and techniques to drive an aggregate method of policy design and move away from the more individualistic method that has been approached. Aggregation results in policy artifacts that are consumable, extensible and easily sustainable. We will examine how a taxonomy-based approach is used to design policy artifacts. Removed is the unwieldy structure-driven policy architecture that results in redundant, unnecessary and hard to consume artifacts. The migration to a design-driven architecture will reduce the number of policies to design and maintain. Most important, however, they will be written in a manner that is appropriate for the policy consumer.

One of the best uses of taxonomy in the technology world is seen through the development of a data warehouse. Large amounts of information from disparate sources is gathered and organized in a manner to provide an organization with a view of activities, events and behavior when queried and/or analyzed. To render the information in a data warehouse consumable, the information is organized by parent-child relationships in a hierarchal fashion resulting in reports that contain only the information you require to support, make or adjust decisions for the organization. This is the desired outcome for the policies you design and deploy.

DEFINING INFORMATION SECURITY POLICY CONTROLS
Just as technology requires controls to reduce the risk of an existing or potential weakness, policies also require controls. Policy controls set the floor, or baseline, for artifact design. They prevent unnecessary policies, assure policy alignment to the business, verify that written policies have an intended use and provide extensibility of policy in anticipation of events and/or activities that are required which cannot meet a policy requirement and may impact compliance. Policy controls are as follows:

  • Point: The artifact and/or solution covers a particular segment.
  • Enterprise: The artifact and/or solution covers a whole which consists of disparate points.
  • Hybrid: The artifact and/or solution must covers both Point and Enterprise.
  • Context: The setting of the artifact and/or solution which covers circumstances relevant to the operations of the organization.
  • Use Scenario: Can the artifact and/or solution address scenarios that are specific to the organization?
  • Exception: When the information in the artifact is dynamic due to the nature of the technology or audience it addresses; requires flexibility to address legacy technology that is in-scope of a regulation but cannot meet compliance requirements; temporary activities and/or events that negatively impact organization compliance and may introduce security vulnerabilities; and special circumstances for users whose role in an organization requires special consideration that may impact compliance requirements and/or introduce security vulnerabilities.
  • Floor: The baseline from which you set policy with the intention that it can be revised to accommodate an exception; is prescriptive rather than explicit.

For example, a network acceptable use policy is a point artifact solution written for the enterprise as a hybrid to address the enterprise and point segments it must cover. It is used to influence the behavior of the end user.

Policy Sources: The Metadata of Policy Artifacts
Policy metadata can be referenced from a number of entities such as handbooks, and legal and human resources professionals.

JUST AS A DATA WAREHOUSE is driven by the metadata it contains, so too are policy artifacts. In the world of information security policies, we owe the primary source of security policy metadata to Charles Cresson Wood, the author of Information Security Policies Made Easy. How so? Just as a data warehouse schema contains categories of data about data, this book is full of security policies that are about other security policies. The latest version (e.g version 10) has 1,360 pre-written policies covering 200 topics.

The content is rendered in a structured manner which results in a fairly flat mapping of policies. Driven from a taxonomy-based approach, policies may be aggregated to a parent that is aligned to the business. If the business doesn't require the policy, then it won't be presented to the audience layer for consumption.

The book is the primary warehouse entity from which policy metadata can be referenced in a conceptual, logical and physical context to develop a policy artifact.

There are secondary and tertiary sources of metadata for policy artifacts. They are your organization's human resource and legal policies. Do not begin writing any policies until you have read and thoroughly analyzed the aforementioned policies. Why? Typically human resources and legal has invested in building a brand that influences the organization's policies. Adapting your policies to reflect the same brand supports the organization's culture and contributes to the cohesion of your policies when consumed by end users. There also may be content and directives in the aforementioned policies that influence the policies you will write.

For instance, policies typically contain a scope section. This identifies whom a policy is directed toward. Your definition of an employee, contractor or consultant should mirror that of the legal and/or HR department. Information classification is also another area that may be owned by your organization's legal department. If classifications of data have been established by legal, resulting IT security policies around data ownership, data classification and data retention should be written to comply with legal's directive.

As the legal department sets the organization directive to protect against litigation, it should be the secondary source of policy metadata. HR policies are usually developed as a partnership between Legal and HR and can serve as the tertiary metadata policy source.

--Ravila Helen White

DEVELOPING YOUR CONTEXTUAL STRAWMAN
Taxonomy-based policy design begins by using the context control to define the setting of your policies through the identification of your audience, logical boundaries and scope. Setting context is a method for aligning your policies to the business and a control for eliminating unnecessary policies. Additionally, it defines the conceptual layer that will drive the parent-child relationship of taxonomy-based policies. Without establishing the parent-child relationship of your policies, you will likely write policies that are not matched to its intended audience or that are beyond the scope of your environment.

Parent-child relationships are mapped as follows: (1) Audience is legal professionals, external end-users, internal end-users and technology professionals; (2) Logical boundaries are defined from a network domain perspective of extranet, intranet and departmental; and (3) The scope of the policies is point, enterprise and hybrid. These mappings set the base for policy design across the enterprise. They enable the policy manager to determine if a policy is physical (e.g. influences a human) or logical (e.g. enforces the configuration and/or management of technology to influence and/or enforce human behavior).

The concept map below results from applying context to a policy system that has been aligned to an organization's business needs. It provides decision makers with an understanding of relationships, boundaries and intended scope. This concept map becomes the straw man from which you'll develop individual policies.

INTRODUCING THE USE-SCENARIO CONTROL
The design of a straw man must be complete as they serve to guide the use-scenarios for each policy that is designed. Use-scenarios in policy design are important because policies written without use cases often contain inappropriate information for the audience, or add complexity to a simple policy. If the use-scenario is targeted toward humans, then the language and content will reflect actions that are taken by humans. If the target is technology, the content will reflect what actions the technology solution will be configured against to protect authorized users and deter unauthorized users. If you cannot map your policy to a use in your environment and/or consumed by a person or technology, it should not be written.

One of the single most important reasons to understand use-scenarios is to understand policy ownership. Why? Policies are legally binding artifacts that protect an organization's brand and information assets. Additionally, they serve as a protection in the event of litigation. Accurate interpretation and jurisdictional scope are best understood by lawyers, and as such, should be driven out of your organization's legal department. The majority of an organization's policies are owned by the legal department with assurance professionals as the content provider. The exception is usually seen with security policies that govern the technology and staff of the IT department.

By combining the information you've gathered for your straw man and analyzing your use-scenarios at a high-level, a taxonomy schema is developed.

POLICY SCHEMA REPRESENTS POLICY CONCEPTS
Drawing further parallels from data warehousing leads us to the schema. Development of a policy schema is essential as it provides the business with the representation of policy concepts. Defined are the policy system and the relationships between those concepts, target audience, and business function.

A well designed policy schema is the tool for driving artifact maturity. Artifact maturity can be measured by the frequency of updates. The more updates that are required, the less mature your policy system is seen functionally. How so? Updates and additions to policies are typically done to address a gap. Gaps should be the cause of unknown factors that arise in dynamic environments. When a gap where all necessary factors are known occurs, it points to a lack of thorough analysis during the requirements-gathering phase of policy design. The resulting effect is a continuous stream of gaps with updates to address each gap.

Defining a schema provides assurance that the organization will invest only in the artifacts they require. Perhaps the greatest benefit is a schema-enforced consumer focus. Let's face it: policies are not the top priority for end users. The more policies you foist upon them, the greater the chance you have to lose your audience. Likewise, the greater the variety of policies following no specific flow that your organization builds, the greater the chance to confuse the policy consumer because policies may appear arbitrary. When a policy audience is lost, it is difficult to regain their trust and attention. Policy schema design sets the necessary boundaries around scope, policy and domain of influence to eliminate policy mismatch and uncontrolled propagation.

The schema above contains the necessary policies for the organization, defines the scope, and defines audience and boundaries. The schema is overlaid on a legal backplane to indicate overall authority and ownership of the policies.

DEVELOPING POLICY ARTIFACTS
Thus far, we've used a mind map to capture context taxonomy and a schema to capture concept taxonomy to represent our policy system. To actually begin writing policy, a taxonomy chart in the form of a spreadsheet to capture and design component taxonomy. The component taxonomy defines the meta (parent) policy and micro (child) policy. The meta policy is the primary policy you want your readers to adhere to. Micro policies are introduced to further define the target areas the meta policy enforces.

A network acceptable use policy is an enterprise policy meant to influence the physical human behavior of technology. The policy communicates to the user how they are to use the technology they've been entrusted with as well as the scope of support the organization is able to provide for its technology. Below is a component taxonomy chart for a network acceptable use policy. Utilized is the parent/child relationship to aggregate individual policies. The final outcome is a consumable amount of polices for the end user. If the individualistic approach were used, the outcome would be structured policies that are singular in their influence. More policies are required to support a singular influence.

With controls in place, a schema and metadata source, the artifact component taxonomy can be created to drive the final policy artifact. To create a component taxonomy for an internal network acceptable use policy, you should write basic industry policies using the floor control first, and then include any policies that support global, federal and state mandates. Then you should add policies that relate to the technology the company has already invested in, and finally, write exceptions to address future technologies they are considering, but have yet to implement based on the technology roadmap of the organization.

The component taxonomy table below also establishes another crucial element of policies. That is establishing the business view of policies by asking the what we must protect through meta policy followed by answering the where we protect through micro policy.

Network Acceptable Use Policy Component Taxonomy

Meta Policy

1 Appropriate Use

2 Privacy

3 Passwords

4 Records Retention

Micro Policy

1.1Personal Use

2.1 Monitoring

3.1 Complexity

4.1 Electronic Files

1.2 Copyrighted and Third Party Material

2.2 Ownership

3.2 Expiration

4.2 E-mail

1.3 Instant Messengers

2.3 Data

3.3 Sharing

4.3 Personal Data

1.4 Personal E-mail

4.4 Classification

To create a component taxonomy for the IT security policy, you should obtain the IT organization's org-chart to categorize your policies by functionality as the various teams inside of IT require different types of policies. Using the floor control, write basic policies you'd expect of any IT security policy; add policies that relate to the technology the company has already invested in, and finally, write exceptions to address future technologies the organization is considering but has yet to implement based on the technology roadmap of the organization and permit activities that are required which may impact compliance and security.

IT Security Policy Taxonomy

Meta Policy

1 Risk Management

2 Operations Management

3 Applications Management

4 Software Development Management

1.1 Security Testing

2.1 Infrastructure

3.1 Administrative Management

4.1 Secure Coding

1.1.1Vulnerability Assessment

2.1.1 Clock Synchronization

3.2 User Management

4.2 Architectural Review

1.1.2 Penetration Assessment

2.1.2Network Segregation

4.3 Threat Modeling

1.1.3 Wireless Assessment

2.1.3 Firewalling

4.4 Code Review

1.1.4 Client Assessment

2.1.4 Malware Management

4.5 Security Testing

1.1.5 Mobile/PDA Assessment

2.1.5 Data Management

4.5.1 Primary Testing

1.2 Data Exchange

2.1.6 Authentication

4.5.2 Secondary Testing

1.2.1 Security Partners

2.1.7 Account Management

4.5.3 Tertiary Testing

1.2.2 Cloud Service Partners

2.1.8 Naming Conventions

1.2.3 General Partners

2.1.9 Encryption

1.3 Cloud Service Providers

2.1.10 System Hardening

1.3.1 Due Diligence

2.2 Client Services

1.3.2 Warranty

2.2.1Password resets

1.3.3 Indemnification

2.2.2 Software Installation

Now you are ready to populate with the meta data source in a narrative format. These will become the policy artifacts of your organization.

METRICS FOR POLICY ARTIFACTS
Gathering metrics from policy artifacts is one of the most important metrics the information security professional can gather? Why? As mentioned previously, policies are legally binding. If policy is not followed by the consumers of your organization, increased risk is introduced. Awareness of where risk exposure has occurred can help you adjust the manner in which your policies are deployed or influence the manner in which consumers are educated about the policy.

Lack of policy compliance by most users is due to lack of understanding the policy. When this disconnect occurs, you now have a metric that tells you more documentation is needed to guide your users. An FAQ or how-to document may be created to provide deeper understanding and guidance to the consumer. Below are sample metrics to gather around policy artifact effectiveness:

  • Malware breach via electronic mail -- if the organization's enterprise IDS displays trends that the greatest malware breaches are a result of electronic mail misuse, then your users may require further training on actions they should not engage in (e.g. opening attachments from their webmail accounts).
  • Passwords -- obtain a report from the customer service ticketing system that relates to all password help calls. Depending on the trends you see in the report, you can make inferences around the effectiveness of your password policy. For example, if the majority of calls are due to users' inability to reset their passwords and the reason is a lack of following the policy for complexity, users may need further education about what constitutes a strong password.

Are you part of an organization that is just starting and requires policy artifacts? If so, use this guide to start your journey and it will greatly simplify the expected work effort. Does your organization already have policies, but you now realize they should be overhauled? Use this as a guide for taking what you have and re-architecting your policy system. Using taxonomy to drive policy development will ensure your policies are treated as a system whole, rather than disjointed segments. The resources invested can provide you a policy system where updates are rare and result in re-investment of people resources to concentrate on the more dynamic areas that drive the business.

Ravila Helen White is currently an enterprise security architect on assignment at an invention company in Seattle. Prior to that, we was the head of information security at The Bill & Melinda Gates Foundation and drugstore.com Send comments on this article to feedback@infosecuritymag.com.

This was first published in December 2009

Dig deeper on Information Security Policies, Procedures and Guidelines

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close