Grading Your Data: Developing and Applying a Data Classification Policy

Without well defined policies, organizations tend to treat all data as if it were of the highest sensitivity, which requires storage for old data and logs, extra layers of access control, and more work involved to micromanage it all.

A general rule in systems administration is to keep systems as simple and standardized as possible , but even though we know inefficiency adds to our costs and headaches, the status quo still seems easier for us to face than the prospect of changing our policies and procedures. For these reasons, developing a data classification policy and performing a data inventory survey just got added to my employer’s initiatives for the new year. But how to go about it?

Look To The Experts

I found a thorough, detailed outline of the data classification process available from the ISACA Journal Online (JOnline), 2006 vol. 5. For those who don’t know, ISACA is the Information Systems Audit & Control Association, a “pace-setting global organization for information governance, control, security and audit professionals.” The basic steps they outlined were:

• Identify critical processes and data
• Identify ownership, control and liability
• Determine security and business requirements for classifying data
• Outline your data classification scheme
• Evaluate changes to processes because of classification

http://www.isaca.org/Images/journal/jonline0605-understanding-data-1.jpg

Data Inventory

My team has spent the past few years working with other agencies within our company to develop a business continuity plan, which means we have already spent a lot of time interviewing people about what systems and applications they use to conduct their daily business, and which of these are most critical to perform their essential job functions. The information we collected with this survey is a perfect place to start our data classification process. By interviewing data owners or directly reviewing the identified datasets, we can determine the nature of that data and then determine which regulatory concerns apply to its handling.

Business and Security Requirements

The ISACA JOnline article contains an extensive, detailed data classification table. This is where specific requirements of regulatory policies come into play, like Sarbanes-Oxley, HIPPA, Export Administration Regulations, and so forth.

http://www.isaca.org/Images/journal/jonline0605-understanding-data-2.jpg

Reviewing actual classification policies used by other organizations, such as Carnegie Mellon University, Michigan Technological University, University of California-Berkley and the Texas Department of Information Resources suggest that its best to limit your effective classes to 3 broad categories; which is in keeping with our “simple as possible” philosophy. These categories can be generalized as “high”, “medium” and “low” sensitivity; with the default posture being “medium” sensitivity unless specific determinations are made to require “high” or “low” safeguards.

https://security.berkeley.edu/sites/default/files/uploads/Data_Classification.JPG

Some commercial policies recommend to make a further distinction between between “our” sensitive data and “someone else’s” sensitive data (company confidential vs. client confidential) for added granularity. This might be an appropriate choice for some environments, especially if separate regulatory standards apply to these types of data in our environment.

Update Your Processes

After all that, the most important step is to make sure to update IT processes to support your data classification standards. One best practice we have learned is to group data sets with similar security requirements into discrete resource pools (servers, clusters or virtualized machines) to simplify automated administration tasks. This also allows default controls and settings to be set and enforced by group policies, insulating us from some types of common administrative errors. The fewer classifications we have to manage, the easier it will be for our admins to apply them, and for our auditors to evaluate them.

Development and production processes need to make sure information regarding new systems is added to the data classification library, so that new systems aren't left out of the loop. System configurations, access audits, maintenance tasks and log management policies need to be configured in accordance with the newly identified requirements.

In truth, this is the uncomfortable phase where everyone’s existing routines get impacted -- but that’s what makes the difference between an organization that can count on a compensating control like breach insurance to cover any potential gaps in their administrative practices, and one that is left to be held liable for its own negligence.