Data classification best practices in financial services

Most information security practitioners would agree that all data is not created equal -- in other words, some data is more sensitive than others, and should be more rigorously protected. There are many different data types, with varying degrees of sensitivity. How should security teams in financial organizations protect each of these different data types? This is the realm of data classification -- each data type gets a specific "label" which then relates to ground rules regarding access control, encryption, business processes and data handling.

Many data classification best practices and programs are derived from classic security and risk management frameworks such as ISO 27001 and COBIT. ISO 27001 has been used in many cases to develop controls for compliance with the Gramm-Leach-Bliley Act (GLBA), and section A.7.2.1 of the standard mandates the creation and maintenance of data classification guidelines. The FFIEC Information Security IT Examination Handbook specifically suggests the need for data classification, and links classification to "protection profiles" that describe what measures should be in place to protect certain data types from exposure or loss.

Given that data classification is so important, how should financial organizations go about the process? The following are key steps that all organizations should follow in data classification best practices:

1. Define what's important, and know where it is stored and transported. For financial organizations, this will most likely constitute financial data from customers (bank account and personal information), company financial records (earnings information, sales data), intellectual property related to financial systems, and related data such as authentication and access control information. Then, working with individual business units, assess application architecture and network diagrams to determine where and how data is stored and moving through the environment. Be sure to include all partner and interconnected networks.
2. Define data classification categories and labels. These should be developed in conjunction with business units, and should focus on particular types of financial and other sensitive data. First, define categories based on data confidentiality and criticality levels. Examples of confidentiality categories might include public (available to anyone), limited access (available to specific groups) and restricted (controlled by compliance or legal mandates). Combine this set of labels with criticality classifications, as recommended by financial services teams:
1. Low: No financial loss or legal liability resulting from exposure or improper use.
2. Medium: Exposure may lead to limited legal liability, loss of customer trust or financial loss.
3. High: Exposure may lead to significant legal liability, loss of customer trust, or financial loss.
4. Very High: Exposure or misuse could result in catastrophic fines and legal liability, loss of customer trust or financial losses.
3. Define Acceptable Use. Acceptable use of data should be based on internal and external compliance requirements (including state data breach laws), and take into account who needs access to the data and how it will be used. In many cases, the data creator will be designated as the "owner," and this person/group should have input into its use. For example, customer banking data may only need to be accessed by customers (the data "owners") and transaction processing staff.
4. Update policies to reflect data classification. By ensuring policies are inclusive of data classification types and compliance influences, organizations can then incorporate data classification into security awareness, incident response and other risk management program initiatives.
5. Establish a maintenance process. A standard data life cycle includes creation, storage, access, modification, retention and archival, as well as disposal. For each of the stages, data classification and security should be addressed via some regularly followed process.

Data classification is a complicated process, but there are tools available to help. . Several vendors offer products, most of which include ediscovery capabilities, and that integrate with storage systems. For example, EMC Corp.'s Kazeon product line and StoredIQ Inc.'s Intelligent Information Platform can support large enterprise data classification efforts.

Although classifying and tracking data may seem daunting, it is a critical element in financial services organizations' data protection efforts. Many compliance mandates and security best practices frameworks require some degree of data classification, and focusing security efforts on more sensitive data types can help to maximize operational efficiency and effectiveness. By creating "protection profiles" based on the most sensitive customer and internal data, financial organizations can better tailor prevention, detection and response efforts.

About the author:

Dave Shackleford is director of risk and compliance and acting director of security assessments at Sword and Shield Enterprise Security Inc., and is a certified SANS instructor. He was formerly CSO at Configuresoft Inc. and CTO at the Center for Internet Security, and has worked as a security architect, analyst, and manager for several Fortune 500 companies. In addition to these roles, he has consulted with hundreds of organizations for regulatory compliance, as well as security and network architecture and engineering.