For many, IT security has been a long journey that is starting to come to an end as perimeters (at least those that exist) are secured, data is encrypted, viruses killed and leaks plugged using the latest vendor offerings.
Unfortunately the journey is far from over, as those that undertake systems implementation and development are finding out.
The issue? Data de-identification.
For those unfamiliar with the term some explanation is necessary.
Imagine that you run the software development function for a bank. You employ teams of developers who cut code all day creating bespoke applications for the various end user departments. Maybe trading solutions, maybe back office process solutions.
How are you going to test the software?
Easy, simply take a cut of data from the production database, populate the development server and start running the tests. This is a practice that would be familiar to development shops all over the world and happens all the time. The inherent problem this poses, from a security view point, is that the cut of production data now sitting on the development server is a full and frank copy of some, probably, very sensitive information. The fact the data has been extracted from the production server and now sits in software development almost inevitably means that it now resides below the radar of the corporate security team and therefore represents a potentially huge data leak waiting to be exploited.
For some this practice may seem a bit far fetched, but I would suggest that for the majority of development shops, either internal departments or external consultancies, this is exactly what happens day in, day out. By the nature of software development, security is often seen as way down the list of concerns. As long as the daily build does just that, and the latest code is put into a fireproof safe overnight, few give a thought as to the nature of the test data.
Some smarter developers see a way around this problem and decide to create their own test data using some clever algorithms that churn out random data sets for customer names or credit card details. In fact quite a few database administrators have become quite adept at writing SQL code to generate test data, maybe using a vendor's sample database as seed values. The problem with this approach is that it is very one dimensional. How can you be certain that you have quality of data as well as volume? Creating volumes of data is easy, it's creating meaningful data that actually looks and behaves as your production data would do which is tough.
Realistic data not only creates a system that looks and works as it should it also helps engage with the end user customer as they get to see the type of data they process daily.
Another difficulty with the DIY approach is how you create meaningful data that stretches across a relational database structure, preserving referential integrity and ensuring correct data types sit in correct columns. In fact when you start to look over the complexities of the problem populating a database with more than a few tables with meaningful, realistic data that actually works is now looking like a very ugly herd of elephants storming over the horizon.
Aside from internally developed applications we also need to consider the implementation of solutions such as JDE, SAP and Siebel. These are complicated implementations by anyone's ranking and demand to be taken very seriously when it comes to testing and deployment. For many, the only way they can undertake proper testing would be to use production data and hope that it remains secure inside the development team.
Security of the development team also needs consideration. The fashion for off shoring may or may not be shrinking but the reality is that many corporate applications are developed using overseas resources based in countries many development managers commissioning the work have never even visited. How are these people supposed to test their code? Fine, it could be sent back for testing but what if you don't have the resources available? For many companies it results in data being sent overseas and ending up completely out of the control of the original security team.
This is where data de-identification comes into play.
This is the process of masking original data by scrambling the source information so that it becomes useless as a data set, but still retains the look, feel and consistency of the original data. The type of data obfuscation that can result may be the random swapping around of first and last names, the random substitution of certain credit card details or artificial data aging. This is still extremely useful data for the system testers and implementers but of no value to those tempted to run off with it as part of a data theft scheme.
Optim, a product originally from Princeton Softech but now part of IBM, provides just such a solution to large enterprises struggling with the difficulties of testing solutions with production data. Using Optim, DBAs and developers get more than a secure test data generator, they get system tools that will look into the structure of the development database and ensure that all referential integrity rules are maintained even though the data is being obfuscated. This would be horrendous to undertake manually but using a solution such as Optim this problem is automatically catered for.
As well as maintaining the look of data the Optim solution ensures that data still passes elementary tests such as year of birth matching a person's age and that postcode/phone area code and address all reconcile, as in real life.
Demands on security officers to ensure adequate governance, regulation and compliance has focussed lots of energy on production systems but I would suggest that few have considered the issue of development test data. In fact the Payment Card Industry (PCI) regulations insist that credit card data be masked during the software testing environment, so if you are subject to these rules and not implementing data de-identification you are immediately open to action.
With the final IBM acquisition of Princeton Softech now complete this new business unit has an opportunity to take Optim forward under the watchful eye of the IBM engagement engine. Opportunities will now undoubtedly present themselves for the Optim team to work alongside the well respected Rational business unit and create more demand for this somewhat overlooked but vital area of IT security. I'll watch its progress with interest.