The data classification policy that I introduced a couple of years ago has served the company well, but now the global architecture team has pointed out its limits.
We have three classifications: Restricted, Confidential and Public. The problem is that only the Public classification allows for any possibility of data being shared with anyone outside of the company. That inflexibility doesn't work very well in the real world.
The global architecture team is responsible for reviewing all enterprise applications. They do that using a strict set of questions and requirements, including the applications' compliance with the data classification policy. There have been some mismatches in that area. For example, the sales organization wanted to deploy a mobile application that is capable of rendering executive reports on sales forecasts. According to our classification system, anything related to sales forecasting has to be classified as Restricted. That means a user wanting to use that mobile app would need to VPN into our network, which is an overly cumbersome restriction in the minds of some of our executives.
And it's hard to argue that "rules are rules" when we don't enforce the same controls equally for other data that has been classified as Restricted, such as pricing lists.
It isn't just that one mobile app for the sales group that seems problematic. Another example is a mobile app that lets users view their HR records and managers approve time-off requests, among other things. Because the app can access sensitive HR data, such as Social Security numbers and salaries, it should also be treated as a repository of restricted data. But that undercuts the app's utility a good deal.
Though I resisted the idea at first, the architecture team was able to convince me to create a fourth data category. Under the new plan, we will classify as Restricted only that data that, if lost or compromised, would represent grave loss to the company. Confidential data will be deemed as unsuitable for public disclosure as well, but the consequences of its compromise would be less dire, and the restrictions are less stringent. The new category, which is as yet unnamed, will be for data that should not be made public but may be accessed in ways that aren't always highly secure. One consideration is that the aforementioned HR app, for example, could reveal someone's Social Security number, but it could never reveal everyone's Social Security number. Another candidate for the new category might be a customer knowledge base. It wouldn't be a loss to the company if knowledge base information were disclosed, but we still make it available only to our customers.
Enter the Matrix
We have also created a matrix for evaluating new applications that weighs methods of access against the need for restriction. For example, our Sarbanes-Oxley-protected financial application will remain Restricted, meaning that access can only be from a company asset and on the corporate network. In the case of cloud-based applications classed as Restricted, we will limit access to company IP address ranges, and will also require that the data be encrypted both at rest and in transit. It's extremely important that we set guidelines for cloud-based apps, since the company continues to look at the cloud first whenever we think about starting to use a new application or replacing an existing one.
Now that we have defined our new data classification, we will have to name it. But more importantly, we need to get buy-in from legal and HR. Then we'll modify our policy documentation and security awareness training materials, which are always necessary steps when a policy is modified.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.
Join in the discussions about security! computerworld.com/blogs/security