Data classification plays a key role in securing an IT system, making it a lot easier to see where and what the organisation's risks are, thereby increasing the chances that you'll end up with an effective security infrastructure. For example, anyone conducting a risk analysis will need to know the value and classification of the information held and processed by the organisation in order to establish its threat profile and understand the possible impact there would be on the business if the data's confidentiality, integrity or availability were compromised.
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
However, data classifications can produce misleading or inappropriate risk profiles if data aggregation is not taken into account. There are two types of data aggregation that can raise the sensitivity level of data and therefore affect the controls needed to protect it.
The first, accumulation, refers to the volume of information stored in one place: 1,000 records versus 50,000 records, for example. The other, association, occurs when information of little value or a low business-impact level is combined with other information of a similarly low business-impact level to create information of significantly greater value. When accumulation or association occurs, the impact on a business if the data is compromised can be much greater than if a single element of the data were compromised. Here are some examples.
The November sales figures for an individual member of a company's sales force probably wouldn't be commercially sensitive, but when the figures for all members of the sales force are added to a spreadsheet to calculate the total November sales for the entire company, then they potentially become much more commercially sensitive.
An HR list containing the names of all of a company's employees and, separately, a budget forecast of salaries and bonus payments would probably each be assigned a relatively low classification, but a combined list containing the names and the salaries of employees would most certainly warrant a higher classification.
There are also situations where accumulation and association combine to change the sensitivity of data and, thus, the business-impact level if it were compromised. Emails are a good example of this: A single email may be of little or no interest, but when collected together, perhaps when being archived, emails may provide a detailed insight into a project or person.
In these examples a compromise of either the data's confidentiality or integrity could have a serious impact on the business, but accumulation can have an effect on availability as well. Suppose a system becomes infected, and the malware starts to delete records in a database. The impact of losing 5% of these records may be containable, but if the malware managed to destroy more than half the records, the resulting lack of availability could have a devastating impact on the organisation.
Thus, a risk mitigation plan needs to assess the business impact of a compromise of aggregated data, not just individual items. If aggregation raises the business-impact level, then further security controls may be required.
A useful exercise is to check whether there is a valid business case for aggregating all data in one place. Does an employee need the entire client database on his or her laptop or USB key? Maybe a subset of the data is sufficient for day-to-day business requirements. The compromise of 1,000 records may be bad, but the compromise of 5,000 records would have a far worse effect. Also, a laptop carrying 5,000 records would clearly need stronger -- and probably more costly -- security controls than one carrying a smaller subset of 500 records.
However, aggregation doesn't automatically increase the business impact or threat level. The aggregation risk assessment will help the organisation avoid disproportionate and inappropriate controls being put in place and impairing business operations unnecessarily. The security controls need to be matched to the threat: Don't fall into the trap of assigning an unnecessarily high-risk rating to an entire system just because aggregation has raised the business effect of a compromise for a portion of that system.
Think about when aggregation could occur and review how it could be controlled or prevented. Database queries that return all the records from a client database require careful construction and appropriate permissions, perhaps limiting the results if they return sensitive data or preventing certain queries that join tables when the combined data would increase its sensitivity.
Security controls relating to personnel need to take into account the effect of aggregation. For example, a database may contain rows of restricted information and access to all the rows greatly increases the potential impact of a breach. Therefore, administrators with low-level access rights to a database should complete more thorough personnel checks than would normally be required; a simple but cost-effective measure.
Other cost-effective controls, such as monitoring and checking that staff follows the relevant security procedures, can help mitigate the extra risks created by aggregation. Where systems are affected by aggregation, consider improvements to the physical and procedural security of the server room, introducing a two-man rule for access and ensuring there is proper segregation of duties. Also, beefing up your business continuity plans and running more frequent backups provides greater resilience in the event that data availability is affected.
Information assets such as databases are fundamental to support modern businesses, but they are also obvious targets, one-stop locations for a would-be attacker. Today's forward-thinking businesses are always looking for an edge over their competitors, and aggregation of data across business lines and the integration of legacy systems and databases are obvious areas that can produce additional business intelligence. However, don't let eagerness to combine and mine data lead you to create an information asset that isn't appropriately protected.
About the author:
Michael Cobb CISSP-ISSAP, CLAS, is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.
This was first published in January 2011