In my work as a consultant, I've always been surprised by the number of organisations I come across that don't classify their data. Many take data security seriously and have sophisticated physical and logical security controls -- yet they don't use data classification standards, or even have policies and procedures covering data classification.
How do you know what security controls are appropriate if you don't know what data you want or need to protect?
For me, data classification standards are the starting point for any security initiative. Whenever data is created, amended or received, its sensitivity level needs to be defined. Then, an organization can establish the appropriate level of security required to protect it.
It's essential to differentiate between that which has little (if any) value, and that which is highly sensitive and confidential. This prioritization makes it a lot easier to see where and what your risks are, increasing the chances that you'll end up with an effective and efficient security infrastructure instead of one that's over-engineered and unnecessarily costly. Yes, you need to be compliant, but encrypting every piece of data is a waste of resources.
Data classification has other benefits, too. Organisations can reduce data duplication, cut storage and backup costs, and speed up search, retrieval and discovery. Data can be stored more effectively as well. Active data, for example, can be kept on high-performance systems with encryption accelerators where necessary, and archive data can be placed on lower-spec ones.
Using the Security Policy Framework, government data classification standards
Thankfully, the number of companies implementing data classification, certainly in the U.K., appears to be on the rise. My personal experience is that this welcome development is being driven by the Data Handling Review -- the government's response to the high profile public sector data breaches in 2008 -- and the release of the Security Policy Framework.
The Security Policy Framework (SPF), which contains guidance and policies on security and risk management for HM Government Departments, sets out five core security principles, number three being "Departments and Agencies must be able to share information (including personal data) confidently knowing it is reliable, accessible and protected to agreed standards."
It also contains seven security policies which outline the 70 minimum security requirements and government data classification standards that are mandatory for all departments and agencies. The framework offers technical information, advice and guidance to support implementation of the policy requirements, some of it made publicly available for the first time in an effort to increase public knowledge and awareness.
Of key importance is that the requirements extend to any organisations working on behalf of, or handling, Her Majesty's Government assets, such as contractors and regular suppliers of goods and services, with departments stipulating where and what level of compliance is required. This arrangement is forcing many organisations in the private sector to introduce or align their data classification policies with the government data classification standards of the SPF, in order to provide assurances to clients that they handle information correctly and securely.
So, now is a good time to introduce or improve your data classification policy; the benefits will certainly outweigh the initial efforts required to implement it.
If you want to follow best practice, you can easily adopt or adapt the Government Protective Marking System (GPMS) covered in Security Policy No. 2 in the SPF, Protective Marking and Asset Control.
This system of data classification is designed to ensure that access to information is correctly managed and safeguarded to a proportionate level throughout its lifecycle, including creation, storage, transmission and destruction.
The process uses five levels of classification or markings. In descending order of secrecy, these are: TOP SECRET, SECRET, CONFIDENTIAL, RESTRICTED and PROTECT, with documents without a classification often being marked as UNCLASSIFIED or NOT PROTECTIVELY MARKED to positively indicate that a protective marking is not needed.
You probably won't need quite such an elaborate hierarchical clearance and sensitivity structure; most organisations are unlikely to have any data that is truly TOP SECRET -- liable to cause considerable loss of life, international diplomatic incidents, or severely impact ongoing intelligence operations. However, these levels, used with supplementary markings or descriptors, provide a very granular classification system practical for any type of organisation.
Descriptors are used to identify sensitivities around the distribution and handling of data, and access requires clearance for both the marking and the descriptor.
For example, a document marked CONFIDENTIAL MANAGEMENT would indicate that the information is only accessible by those in the organisation's management team cleared to access data marked confidential. Access can be further limited by using code words to exclude certain named staff or groups.
Beginning your data classification policies
So how do you determine what data gets which marking? Applying too high a protective marking can lead to unnecessary and expensive protective controls, and adversely impact efficiency, while too low a protective marking could lead to lost or compromised data.
In order to apply the correct classification, the originator or nominated owner of the information should conduct a damage or harm test. Consider the likely impact or consequences if the information were to be compromised. This kind of harm test is done by assessing the information against the criteria for each protective marking.
The government uses business impact levels to classify and label data according to the protection it requires. Below is an example of the financial criteria for Impact Levels 1 to 4:
Work substantially against national finances or economic and commercial interests; substantially to undermine the financial viability of major organisations.
Cause financial loss or loss of earning potential or to facilitate improper gain or advantage for individuals or companies.
Cause financial loss or loss of earning potential, or to facilitate improper gain; unfair advantage for individuals or companies.
IL1–Not Protectively Marked
Don't miss need-to-know info! Security pros can't afford to be the last to know. Sign up for email updates from SearchSecurity.co.uk and you'll never be behind the curve!
Depending on your type of organisation and the variety of data you're protecting, your criteria may need refining, but you can see how data in each level requires differing amounts of protection.
When classifying a collection of data, like an employee's personnel file, it's always the most sensitive data element in the collection which determines the classification category of the entire collection.
A related element of data classification involves classifying aggregated data. When data at one impact level is combined with other data at the same level, the impact level of the whole collection can increase significantly.
For example, losing an entire client list is far more damaging than losing a single client record. The entire client list therefore requires a higher protective marking. Also the sensitivity of information may change over time, requiring reclassification for items like financial statements, for instance.
By implementing data classification, you can better control access and use of your organisation's data. Aligning your data classifications with the government data classification standards will help ensure the security controls protecting commercially sensitive documents and personnel and client data meet the requirements of relevant legislation and best practice.
In my next article I'll be looking at one of the challenges an organisation will face when introducing data classification: educating its users. I'll also be demonstrating ways to implement and enforce data classification policies, while also pointing out some of the problems you may face along the way.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.