Difficulties with Data Protection Strategies

Companies face two important difficulties with data protection: complexity and cost. As the data protection needs of organizations change and grow, the task becomes more complex. With complexity comes the opportunity for mistakes. In regulated environments or public companies, this can be a dangerous problem. Simple errors in judgment or planning can lead to data loss, lawsuits, and fines.

Another problem with many data protection strategies is that all data is assumed to be of equal value. The problems that result from treating all data the same are added expense and wasted time. When unimportant data is dealt with in the same fashion as mission-critical data, valuable resources are assigned to valueless data. Time and effort are also expended on data with little or no value to the organization. This needlessly raises the cost of protecting data. It also increases the odds that important data will not be adequately protected.

What Is Policy-Based Data Protection?

Policy-based data protection is a way of defining data protection methods, tools, and procedures as policies and then deriving rules from those policies. The goal of policy-based data protection is to alleviate some of the difficulties associated with the complexity and cost.

A policy is a set of best practices that the organization must follow. These policies are not simply guidelines or suggestions. Policies are a concrete expression of the data protection strategy. If the goal is to protect only valuable e-mail, a policy can be developed that defines what is valuable, what is not valuable, and how to manage it. From policies, a set of rules can be derived that tells the organization exactly what it must do. Policies remove ambiguity from the management of data.

It is important to point out that policies define business processes. They do not mandate that specific technology be used. Technology may be used to automate compliance with policies, but the definition of policies is not dependent on software or hardware.

Policy Development Guidelines

Writing data protection policies is a very difficult task. Despite the fact that it is helpful in the long run, in the short term it is usually an arduous process. Many constituents need to be consulted, and data protection is too critical to leave any of them out. Unfortunately, the initial effort involved inhibits organizations from doing the necessary work of data protection policy development.

Policies are, by nature, hierarchical. Broad policies covering large sections of the data protection strategy are supported by smaller components. These in turn are supported by smaller components. This continues until the desired level of detail is achieved. The level of granularity necessary to create a good policy depends on the organization and on the scope of the data protection strategy.

It is best to start small, choosing either a top-down or a bottom-up approach. In the top-down approach, the first polices developed are broad and cover the overall data protection strategy. The next set of policies drills down and fills in more details. This has the advantage of having all the individual policies governed by a root policy, providing context to the overall hierarchy. The disadvantage is that a lot of work has to go into policy development before it becomes useful to the organization.

The bottom-up approach focuses on one or two small functional areas of the data protection problem and develops detailed policies for them. Other detailed policies are developed over time, which are aggregated into higher-level policies until a full policy set is developed. This type of policy development works best in organizations that already have a clear sense of their overall data protection strategy. Specific, detailed policies can be put into action sooner.

Tip

Though the bottom-up approach allows for quick implementation of critical policies, it can create problems later. Individual policies tend not to agree with one another. When the top-level policies are written, they may force changes in the lower-level policies. This creates more work as policies are written and rewritten.

The top-down approach better assures internal consistency among policies and reduces the chance of having to rewrite policies.

Data protection policies have certain characteristics. These guide the overall process of developing policies but do not define them. Instead, policies are defined by business needs, company processes, and the data protection strategy.

Characteristics of good data protection policies are that they:

• Must be written. All policies must be written down and made available to everyone. If the people who need to follow the policies do not have access to them, they cannot comply with them.

• Must define a set of processes and rules. A policy is a failure if it does not clearly tell people what they need to do. It needs to be expressed as a process or procedure that can be easily converted in a set of rules to follow.

• Must not be vendor- or technology-specific. Policy is not about technology; it's about business and organizational needs. A good data protection policy should never define specific technology, products, or vendors. The policy should be valid even if these change.

• Must be specific to the organization. Data protection policies are like a toothbrush an individual item. Each organization is different and has different needs. Templates and best practices from other organizations are good starting points and guideposts. They are never a sufficient substitute for doing the work of policy development.

• May be hierarchical. There are advantages to arranging policies in a hierarchical tree. First, it creates clear connections among related policies, making related policies easier to find. Next, it makes it easier to see where subsequent policies have overridden statements in the parent policy. Finally, it provides a structure for future policy development.

• Must be simple to understand. Overly complex policies ensure lack of compliance. If the policy is hard to understand, the organization will make mistakes. When the policy is complex and burdensome, it will be subverted.

Many data protection policies are based a need to comply with regulatory and legal requirements. Failure to protect data in a manner that complies with regulations and laws may result in fines and lawsuits. Nonpublic companies in nonregulated industries will not be governed as much by regulations during policy development.

Policy Languages

There is no set language for expressing data protection policies. Using simple statements in a policy that everyone can understand is perfectly fine. For some organizations, a more structured approach is desired. Some popular ways of expressing policies are using the Extensible Markup Language (XML), Unified Markup Language (UML) Use Case diagrams, and flowcharts.

Although all of these approaches have pros and cons, XML has the advantage of being both human readable and machine readable. XML also allows for the use of Schemas, which allow the author first to define the structure of the document. There are hundreds of industry and special-use Schemas for XML. At this time, there is no specific XML Schema for data protection.

A Sample Data Protection Policy

In this example, assume that Widget Corporation (a fictional maker of widgets) has the following requirement regarding corporate e-mail:

All customer and prospect e-mails must be retained.

Widget Corporation defines a customer as anyone who has bought or ordered products in the history of the company. A prospect is defined as anyone who has expressed interest in Widget's products but has not yet purchased anything.

The data protection methods that Widget Corporation are using include continuous replication of e-mails and daily and monthly backups of the e-mail database

The e-mail retention policies can be described in plain language as:

Name: Customer E-Mail Retention
Policy Type: E-Mail
Data Type: E-Mail
Parent: E-Mail Policy
Description: Policy governing the retention of customer e-mail
Purpose: To support continuing business operations by ensuring that previous
e-mail communications with customers are available to Sales, Marketing, and
Customer Service.
Creation Date: MAY 4, 2004
Revision Date: FEB 28, 2005
Process:
All e-mails to and from customers and potential customers (also known as
prospects) will be copied to a duplicate copy of the e-mail database as they
are received. End-users are not allowed to delete customer e-mails in any way,
including from their personal mailboxes.
The primary and duplicate e-mail database will be backed up to tape each
night; tapes will be rotated according to current IT policy (IT Tape Rotation
Policy).
Customer e-mail will never be archived.
Expected Results: All customer e-mail will be available online all the time.
Constraints: There is no automated method of keeping users from deleting
e-mails.
Assets: primary_email, secondary_email
Asset Type: Disk array
Asset: backup1
Asset Type: Backup server with attached autoloader

The sample clearly states what the policy is, what is expected from IT and end-users, and how it is to be accomplished. It also recognizes constraints that may affect compliance. By including parent policies, it establishes a hierarchy as well. A typical hierarchy in this case might be as follows:

Data Protection Policy:
E-Mail Policy:
    Customer Retention Policy
    Financial E-Mail Retention Policy
Database Protection Policy:
    Financial Database Protection Policy
    Manufacturing Database Policy

Each subsequent level of policy adds detail and overrides more general processes in the parent.

In XML, this policy can be written as such:

 <policy policy_type="E-mail" data_type="E-Mail" parent="E-Mail Policy">    <name>Customer E-Mail Retention</name>    <description>    Policy governing the retention of customer e-mail    </description>    <purpose>    To support continuing business operations by ensuring that    previous e-mail communications with customers are available    to Sales, Marketing, and Customer Service.    </purpose>    <date>       <create>MAY 4, 2004</create>       <revision>FEB 28, 2005</revision>    </date>    <process>    All e-mails to and from customers and potential customers    (also known as prospects) will be copied to a duplicate copy    of the e-mail database as they are received. End-users are    not allowed to delete customer e-mails in any way, including    from their personal mailboxes.    The primary and duplicate e-mail database will be backed up    to tape each night; tapes will be rotated to according to    current IT policy (IT Tape Rotation Policy). Customer e-mail will never be archived.    </process>    <expected_result>    All customer e-mail will be available online all the time.    </expected_result>    <constraints>    There is no automated method of keeping users from deleting    e-mails.    </constraints>    <asset asset_types="Disk Array">    primary_email, secondary_email    </asset>    <asset asset_types="Backup Server">backup1</asset>   </    policy> 

The XML document can still be read by a nontechnical individual. Unlike the first document, it can also be read by software that might manage or use the policies later. The XML may be extended to include commands for software or devices that tell them to perform specific functions related to implementing the policy. For example, a <command> tag may be added that is read only by software that controls the tape library.

 <command> backup  source primary_email  dest backup1  schedule daily  time 20:00:00 </command> 

It would be clear, even to a nontechnical person, that this was intended to be a command for a software program that would define a backup process. The plain-language and XML versions could be used together to provide maximum clarity and enhance automation of compliance.

The Reasons Policy-Based Strategies Fail

Developing sound policies is tough. The work can be tedious and tends to uncover all the places where the organization is deficient. There are some common potholes that many organizations step into when developing data protection policies. Some examples are

• Failure to use logical names for devices. One of the great strengths of the Internet is that it does not rely on raw device addresses, such as IP addresses. Instead, it uses logical names. Changes in the infrastructure are transparent to users. Designing around physical device names or addresses makes changes difficult. Changes in devices should never force changes in policies.

• Reliance on human compliance. Even simple scripts that automate processes help with compliance. Asking end-users to remember to perform tasks, especially when the tasks require multiple steps, assures noncompliance.

• Expecting users to change their behavior. The classic problem with document management systems is that they depend on check-in and check-out practices. This is not what people do normally.

  Warning

  End-users should never have to change how they work to comply with the data protection policies. Not only is it easy to make a mistake, but forcing changes in human behavior practically invites subversion. Design policies according to accepted and existing end-user practices, and people will comply.

  
  

• Focusing on the technology, not the process. It is natural for IT people to view data protection as a technology problem. Technology then becomes the natural starting point. That is the tail wagging the dog. Policies derive from the process and practices of the organization. The best place to focus attention is on the goals and policies of the organization. Technology exists only to assist compliance with those policies.

• Having IT do all the work. Remember to include the other stakeholders in the decision-making process. Even if IT has charge of the data protection policy, many other people in the organization will be affected by it. They need to be part of building and implementing data protection policies.

• Refusing to fix process problems. The development of data protection policies undoubtedly will uncover problems with existing processes. Some policies will simply be broken or obsolete; others will conflict with the data protection needs. Refusal to fix process problems first results in data protection policies that users cannot or will not comply with.

The overarching reasons that policies fail, either in development or implementation, are lack of attention to human behavior and too much attention paid to technology. IT professionals especially must focus their attention on the processes and how they affect people before considering technology.