A Q&A with Chris Pillay of Meridian Technologies
An often-overlooked risk in cyber security is software development and testing, which is often done in house in large companies. To test software, engineers utilize either scrubbed data and where the process of scrubbing personally identifiable information is too complex, costly or time-consuming, live data is used, posing serious security and privacy risks. I learned more about this issue by talking to Chris Pillay, CEO of Meridian Technologies.
Why would a company need to be concerned about sensitive data in their own environment?
Companies have a lot of controls around how data in their production environment can be accessed by insiders. This is not true in the test and development environments. In these environments, developers and testers have enhanced access to the data and development tools to be able to manipulate the data. This means that they can transform names, social security numbers, account numbers, etc. and easily email these sensitive data points out of the company.
Most companies have data loss protection (DLP) software that will detect if sensitive data is being emailed, so won’t that stop this from happening?
DLP software works by looking for patterns such as a 9-digit number with two dashes embedded. If the software sees that, it flags it as a SSN and will suspend the email and send and alert. But with the availability of development tools or even Microsoft Excel, a developer can transform the SSN into a series of alpha characters, embed that into an email, and send it. The DLP software will not stop the email because it cannot detect the data. Once the email is received outside the company, the transformation can be reversed to get the SSN back.
Most companies have been carrying this live data around for so long that they do not have details about where it’s located.
How big is the problem?
Every large company we’ve worked with has live data in their test and development environments. To make matters even worse, they have multiple copies of their production data in these lower environments to facilitate multiple development and testing processes. So the biggest exposure that most companies have is these lower environments.
How does one determine where sensitive data is located?
Most companies have been carrying this live data around for so long that they do not have details about where it’s located. While many have archiving policies for their production environments, there is no one charged with tracking and cleaning up lower environments. They will need to implement an auditing process to find the data and then secure it. The audit is not a one-time activity because any time a lower environment is refreshed, it should be audited again to ensure that sensitive data was not moved.
How can these environments and the sensitive data be secured?
By utilizing tools that can obfuscate the data. Companies can only truly deal with this risk if they set up a central process overseeing the creation of test data with well detailed security policies. Companies need to make it someone’s job to track where the data is located and ensure that it is cleaned up. Data security should live with the data, not in the infrastructure. The infrastructure is too permeable.
In summary…
We want to thank Chris for his expertise in this often-overlooked area of internal development systems which houses and thus can expose live client data. Our insurance carrier partners see cyber breach claims each year impact a system or data-set that was completely forgotten or overlooked by the business client. Verizon does a great computer crime study/report each year called the Data Breach Investigations Report (DBIR) which accounts for the fact that often data breaches fit into the “unknown unknowns” (forgotten data or systems) category, which internal development systems can fall victim to. Vigilance within your software application development and testing staff (and outsourced vendors) is key.
