CHAPTER 67

DEVELOPING CLASSIFICATION POLICIES FOR DATA

Karthik Raman and Kevin Beets

67.1 INTRODUCTION

67.2 WHY DATA CLASSIFICATION IS PERFORMED

67.3 DATA CLASSIFICATION'S ROLE IN INFORMATION SECURITY

67.4 LEGAL REQUIREMENTS, COMPLIANCE STANDARDS, AND DATA CLASSIFICATION

67.4.1 Legal Requirements

67.4.2 Family Educational Rights and Privacy Act

67.4.3 Compliance Standards

67.4.4 Other Standards

67.5 DESIGNING AND IMPLEMENTING DC

67.5.1 Data Classification Solutions

67.5.2 Examples of Data Classification Schemas

67.6 CONCLUDING REMARKS

67.7 NOTES

67.1 INTRODUCTION.

A figure appears from the bushes on a dark and stormy night and silently slips past two guards. Inside the building, a flashlight flickers to life and begins a slow dance around a cluttered office. The beam freezes. It illuminates an envelope that is stamped with large red letters: “TOP SECRET.”

The top secret label is likely the most popularly recognized part of an example of a data classification (DC) scheme. DC labels information so that its custodians and users can comply with established data protection policies when organizing, viewing, editing, valuing, protecting, and storing data.

Historically, DC has been used by the government and military. Today, however, it has increasingly become a necessity for businesses because of the competitive value of information, because of the legal requirements for maintenance of sound financial and operational records, and because of the demands of privacy-protection laws.

This chapter explains why DC is necessary, how it relates to information security, common laws and standards associated with DC, its design and implementation in an enterprise, hardware and software solutions that can assist in performing DC, and some practical recommendations to consider when implementing DC.

67.2 WHY DATA CLASSIFICATION IS PERFORMED.

Information life cycle management (ILM) is a combination of processes and technology that allows for the control of data throughout its life cycle.¹ ILM ensures that data storage professionals can manage data from creation through destruction. DC is an important part of ILM.

Consider an audit on a business for compliance with the requirements of the Health Insurance Portability and Accountability Act (HIPAA). If a data administrator has not established a DC scheme, not only will the audit take longer than it should, but the company may be fined for lacking controls on sensitive data; indeed, the company may not understand or be able to describe the nature of its data. For example, in the absence of DC, someone in the organization could conceivably post patient records on a public Web site with no conception of the seriousness of such an error. Without having clear standards and procedures for classifying data, employees cannot reliably know what to protect and how to disseminate information securely.

Although legal requirements and compliance fines are major reasons for implementing DC, a business can also gain from increased productivity and cost savings through DC. Allowing data to flow in a free yet secure manner is critical to the carrying out of business objectives. DC is one of the steps in risk analysis that helps to estimate and justify rational protection costs.

As this chapter is being written in 2008, energy costs are rising rapidly. DC can help analysts identify information that may have outlived its usefulness and that can be purged from active data storage systems, thus increasing the efficiency of data access and reducing some of the wasted energy involved in maintaining large data stores.²

In summary, DC can bring an organization these benefits:

• Compliance with data standards and legal requirements
• Streamlined and secure sharing of data
• More efficient data storage and retrieval
• Tracking of data through the ILM

67.3 DATA CLASSIFICATION'S ROLE IN INFORMATION SECURITY.

Guidelines such as those from the Federal Financial Institutions Examination Council (FFIEC) highlight the need to secure data as an integral part of DC.³

Classifying data allows the institution to ensure consistent protection of information and other critical data throughout the system. Classifying systems allows the institution to focus its controls and efforts in an efficient and structured manner. Systems that store or transmit data of different sensitivities should be classified as if all data were at the highest sensitivity. Classification should be based on a weighted composite of all relevant attributes.⁴

DC supports risk analysis and helps security analysts determine the degree of protection required for data during transport and storage; classification allows clear definition of what types of users may be able to access or modify the data. Investment in encryption (see Chapter 7 in this Handbook) and physical controls (see Chapters 22 and 23) are affected by data classification.

DC plays a central role in business continuity planning (see Chapter 58) and in disaster recovery planning (see Chapter 59).

Legal requirements and compliance standards may make the marriage of DC and security a mandatory step for some businesses. A brief overview of such standards and compliance codes follows.

67.4 LEGAL REQUIREMENTS, COMPLIANCE STANDARDS, AND DATA CLASSIFICATION.

The amount of data that passes through an average-size enterprise's computers and networks daily can run into terabytes. Regulations and compliance standards may make it necessary that the enterprise's IT staff be able to manage all of these data. The use of DC to meet legal requests, and for compliance, has been hastened by the advent of the “paperless” office. Just 20 years ago, an enterprise could reasonably manage its data for compliance if its (physical) filing systems were well organized. In today's digital office however, an enterprise's data can be scattered over any number of hosts, in several geographic locations, across storage area networks in offsite data centers, or any combination of each of these. Without a concerted enterprise-wide automation and DC implementation, meeting regulatory requirements will be nearly impossible.

Compliance with a number of laws and standards is facilitated by DC. For more extensive discussion of privacy laws, see Chapter 69 in this Handbook. For more extensive discussion of intellectual property laws, see Chapter 11.

67.4.1 Legal Requirements.

This section summarizes key provisions of several U.S. laws that bear on DC.

67.4.1.1 Privacy Act of 1974.

The Privacy Act of 1974 aims to regulate the disclosure of records by government agencies. The Computer Matching and Privacy Protection Act of 1988 was grafted into the Privacy Act of 1974, and introduced provisions for

67.4.2 Family Educational Rights and Privacy Act.

Educational institutions that receive U.S. government funding have to contend with the requirements of FERPA, which regulates the handling of educational data. Many sections of FERPA on information disclosure are relevant to DC. Here are some examples:⁶

67.4.2.1 Health Insurance Portability and Accountability Act.

One of the most important regulations that medical organizations must consider is the Health Insurance Portability and Accountability Act of 1996. Title II of HIPAA, “Preventing Health Care Fraud and Abuse; Administrative Simplification; Medical Liability Reform,” mandates a set of standards for the management of health information. The contents of Part C of Title II, “Administrative Simplification,” address security:⁷

Sec. 1171. Definitions.

Sec. 1172. General requirements for adoption of standards.

Sec. 1173. Standards for information transactions and data elements.

Sec. 1174. Timetables for adoption of standards.

Sec. 1175. Requirements.

Sec. 1176. General penalty for failure to comply with requirements and standards.

Sec. 1177. Wrongful disclosure of individually identifiable health information.

Sec. 1178. Effect on state law.

Sec. 1179. Processing payment transactions.

67.4.2.2 Gramm-Leach-Bliley Act.

The Gramm-Leach-Bliley Act (GLBA) of 1999 introduced reform for the financial sector. Title V of GLBA imposes privacy requirements on the handling of information by financial organizations:

The contents of “Title V—Privacy” are:⁸

Subtitle A—Disclosure of Nonpublic Personal Information

Sec. 501. Protection of nonpublic personal information.

Sec. 502. Obligations with respect to disclosures of personal information.

Sec. 503. Disclosure of institution privacy policy.

Sec. 504. Rulemaking.

Sec. 505. Enforcement.

Sec. 506. Protection of Fair Credit Reporting Act.

Sec. 507. Relation to state laws.

Sec. 508. Study of information sharing among financial affiliates.

Sec. 509. Definitions.

Sec. 510. Effective date.

Subtitle B—Fraudulent Access to Financial Information

Sec. 521. Privacy protection for customer information of financial institutions.

Sec. 522. Administrative enforcement.

Sec. 523. Criminal penalty.

Sec. 524. Relation to state laws.

Sec. 525. Agency guidance.

Sec. 526. Reports.

Sec. 527. Definitions.

67.4.2.3 Sarbanes-Oxley Act.

The Sarbanes-Oxley (SOX) Act was introduced in 2002 in the wake of a slew of accounting scandals involving a few large U.S. corporations. The scope of SOX is broad, and many of its sections may have relevance for DC. For example, Section 404, “Management assessment of internal controls,” makes “establishing and maintaining an adequate internal control structures and procedures for financial reporting”⁹ the responsibility of management.

67.4.2.4 Federal Rules of Civil Procedure.

The Federal Rules of Civil Procedure (FRCP) are a set of rules for the trial of noncriminal cases in federal courts in the United States. The most recent editions of the FRCP include sections that address electronically stored information (ESI).¹⁰

Rule 26, “General Provisions Governing Discovery; Duty of Disclosure,” states that a party should be able to provide:

Rule 34, “Production of Documents, Electronically Stored Information, and Things and Entry Upon Land for Inspection and Other Purposes,” states:

Further, Rule 34 states:

67.4.3 Compliance Standards.

For more detailed discussion of security standards, see Chapter 51 in this Handbook. This section summarizes key elements of widely used security standards that bear on DC.

67.4.3.1 U.S. Federal Government's Executive Order 12958.

On March 25, 2003, President George W. Bush issued “Further Amendment to Executive Order 12958, as Amended, Classified National Security Information.”¹² The preamble sates that this order describes “Classified National Security Information” and stipulates:

The order provides extensive policies and procedures for classifying and maintaining the security of information affecting the national security of the United States. In particular, the well-known classifications used in U.S. Government circles are defined in this way:

67.4.3.2 ISO/IEC 17799.

ISO/IEC 17799 of 2005 “establishes guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization.”¹³ It makes it the responsibility of an organization's security management to design and implement DC according to confidentiality and importance. It suggests a five-point labeling system for data, in order of increasing confidentiality and importance requirements: public documents, internal use only, proprietary, highly confidential, and top secret.¹⁴

67.4.3.3 Control Objectives for Information and Related Technology.

Control Objectives for Information and related Technology (CoBIT) is a set of standards and tools for IT management. The Web site of Information Systems Audit and Control Association (ISACA), the organization that maintains CoBIT, states:

The CoBIT 4.1 standard states in section PO2, titled “Define the Information Architecture,” that “the establishment of an enterprise data model that incorporates a data classification scheme to ensure the integrity and consistency of all data” is part of the Planning and Organizing phase of the CoBIT strategic information technology (IT) plan.¹⁶

A well-written article by Rafael Etges, CISA, CISSP, and Karen McNeil in the ISACA's Information Systems Control Journal points out that sections DS5.8 (primarily); DS5, “Ensure Systems Security”; DS11, “Manage Data”; and DS13, “Manage Operations”; are relevant to DC.¹⁷

67.4.4 Other Standards.

Other regulations may apply to a specific field of business or as part of working with businesses in other fields:

Defense contracting. Department of Defense (DoD) issuances

Finances. Federal Financial Institutions Examination Council (FFIEC) regulations

Life sciences. Food and Drug Administration (FDA) regulations

Media, telecom. Federal Communications Commission (FCC) regulations

67.5 DESIGNING AND IMPLEMENTING DC.

In this section, we outline how a business can design and implement DC. Both tasks should be carried out by IT or information security staff with the support of management. These tasks should be iterative.

The process to design DC can be modeled in this way:¹⁸

Obtain Management Approval

1. Study the organization's Business Continuity Plan (BCP) and note the organization's current IT assets and storage-management processes.
2. Present the benefits of DC to the heads of business units (BU).
3. Survey users in various BUs about how they store, retrieve, and edit data and how they would like to see their data organized and labeled.
4. List the revenue-generating and mission-critical usage of each BU's data. Understand how each unit uses and manipulates data specific to its needs, and how those data may be shared across other units.

Once these steps are undertaken, the DC team can devise a data-labeling scheme that takes into account all BUs and their interactions.

The process of implementation of DC can be modeled as in this way:

1. Obtain management approval.
2. Map data-labeling scheme to available hardware, networks, systems, and storage.
3. Apply automation or DC tools where relevant.
4. Guide users through adoption of new DC scheme and solicit feedback.

Finally, the DC team should report the results of DC design and implementation to management. A refined data classification report would include a service-level agreement (SLA) for data usage as well as a comprehensive model of costs.¹⁹ One of the major costs to announce would be for new hardware, networks, storage, or software needed to implement DC.

For more details of developing security policies in general, see Chapter 66 in this Handbook.

67.5.1 Data Classification Solutions.

Software solutions for DC have been driven mostly by the advances in data-storage optimization. Some examples of the storage advances that helped to spark these solutions include:

• Virtualization—the ability to logically organize multiple physical locations
• De-duplication technology to reduce duplicate data
• Cheaper storage media

As stated earlier, knowing the type of data being managed is imperative when deciding how to secure it, store it, and manage its information life cycle. This process can be involved and extremely time consuming. Several vendors provide software solutions to assist in this classification process. Most of these solutions run on rackmounted appliances. The information and classification management (ICM) market provides tools and consultation for DC.

Some of the features that a data custodian may want to consider when making a software solution decision include:

• Policy-based data-type discovery. DC based on the policies outlined by the data custodian. These policies can later be used to enforce automatically a business's storage policies.
• File metadata classification. DC using a file's metadata and file content.
• Multiple file system management. Seamless classification across multiple file system types.
• Compliance and legal considerations. DC that includes usage of legal metadata, retains file ownership chains, and uses pattern-matching for sensitive data such as Social Security numbers.
• Report style. DC based on the utility of the reports on data that have been discovered, labeled, and classified.

One example of a software data classification system is Titus Labs' Document Classification™ for Microsoft Office.²⁰ The product:

RSA Data Security's Data Loss Prevention (DLP) Suite is described by the company as providing

67.5.2 Examples of Data Classification Schemas.

Security policy and practice can vary widely in design and implementation across different organizations. So too can DC design and implementations. For example, here are some differences in the implementation of DC in three major U.S. universities:

• The George Washington University's Data Classification Security Policy states:

  Data is a critical asset of the University. All members of the University community have a responsibility to protect the confidentiality, integrity, and availability of data generated, accessed, modified, transmitted, stored or used by the University, irrespective of the medium on which the data resides and regardless of format (such as in electronic, paper or other physical form).

  Three categories of data are defined, Public, Official Use Only, and Confidential. The policy gives examples of each category.²²

• Stanford University's Data Classification Guidelines Webpage states the case for the classification of the university's data clearly and concisely. It defines three categories of data, Public, Sensitive, and Restricted, and tabulates some legal requirements, reputation risks, other risks, access restrictions, and examples of these categories.²³
• The University of Missouri's DC policy outlines the case for DC and defines four categories of data, Public, Confidential, Restricted, and National Security Interest. It lists three network zones, each with its own security requirements. It tabulates various setup and usage requirements for each data category.²⁴

For each of the three examples, the DC policies and procedures can vary based solely on the labels chosen. Those entities that use fewer labels will most likely have fewer policies and procedures across a broader spectrum of data, as opposed to those that choose to divide their data into more categories. For example, if a business chooses to label all data as Confidential, a single policy would be in place that all users would need to follow, as opposed to a business that chooses to label data with many different labels. In practice, the number of labels or categories would most likely be somewhere between three and six.

67.6 CONCLUDING REMARKS.

In conclusion, here are some important points to remember when dealing with DC:

• A complete solution will most likely not be achieved by using software solutions alone. Since DC is still evolving, these solutions may require customization to fit what a business must accomplish. Thorough research will be required to find a best-fit solution.²⁵
• In order to determine what type of data is used across an entire business, it is imperative to interview users from all segments of the business using surveys.
• Locations of data must be written into a DC policy. Since data can reside in many different locations, a policy must be drafted to account for geography and to allow for proper storage and retrieval of these data from varied locations.
• An educational policy for users will need to be created for the “Important” data type (or equivalent) level and above. Creators and users of valuable data types must be educated about the policies and procedures that are put into place for the storage, retrieval, and use of their data.
• A complete DC solution will take some time to implement. Because of the complexity of DC, a complete and well-designed implementation will not happen overnight. A realistic estimate should be provided to management when undertaking a DC project.
• Compliance and legal requirements need to be understood well for each particular business. Several compliance standards make a business legally liable for certain data types. It is imperative to understand which of those standards apply to the business's data when taking on the DC task. Remember, too, that legal requirements may also cover investigations that require these data, so understanding data-handling laws is also important. For further information, see Chapter 55 in this Handbook.

67.7 NOTES