The testing and development environments are an overlooked information security risk. When it comes to information management and governance, we tend to focus instead on business production environments.
What about the data that’s been created during test and development and too often forgotten? Ignoring that data leads to a pretty gnarly InfoSec problem.
It’s too easy to have a laissez faire, “who cares?” kind of attitude when it comes to test and development. The teams that develop and test are all about innovation, speed and building new business processes and customer-facing products. Too often, the last thing these teams worry about is security and privacy.
But they should worry—and so should the organizations that employ them. There is risk here. There is a lot of risk. How would you explain that development and test data are not as protected as production data if there were a breach?
When I recently bumped into a former colleague at an InfoSec conference, we started talking about information management in the so-called “lower regions.” My former colleague’s company hadn’t yet had an audit that pointed out a problem, but the company did realize that data from development and test are becoming targets for bad internal and external actors. They knew that the risk in these lower regions could be made more acute by poor information governance.
The discussion reminded me of a former job I had where we had to report a breach. A contractor wanted to do some development and test work during home leave and e-mailed herself—from the corporate system—a spreadsheet with sensitive customer information. Though the records “de-identified” each customer, the Data Loss Prevention (DLP) people were not happy.
And given the industry we were in, we had to report what happened to regulators. The breach—which was not maliciously intended—meant that we had to inform members and verify deletion, in case any individuals ever would be at risk.
No harm was done, but there was a monetary cost from the whole incident. Some 15 people were working on the problem for a three-week period. The organization spent at least $75,000 fixing the issue. The opportunity cost of our not doing other work was even higher. (For advice on Information Governance in the healthcare industry, see Joe Shepley’s post, Information Governance in the Health Care Industry.)
Incidents like these show just how intertwined information governance and information security are. From a risk perspective there are essentially two scenarios: development and test managed in-house, or development and test that’s done by outsiders, as was the case with the contractor in my former company.
But there’s another way to view InfoSec and information governance in the lower regions: as an opportunity. Software engineers have more control in the lower regions than they do in production environments. There’s a lot of live data that may be dumped from production into dev-test. Data can proliferate and cross between the two areas.
Unlike the incident at my prior job, DLP protocols often don’t hit these test and development regions. Content can slip through the cracks. You don’t want errant information on the other side of your firewalls.
That’s why traditional information governance is critical: get rid of ROT (redundant, outdated and trivial content), archive what doesn’t need to be accessed and have a good data map with solid access management and privacy controls. (See Jim Polka’s recent post, Retention and Sensitive Data Identification.)
At the highest level you want to treat the lower regions with the same security and governance that you would treat production-generated information.
Here are three things you can do to improve information security in the testing and development environments:
Start with PII and PCI type of content. For this kind of information, if there is a breach, it becomes a treasure trove of risk with potential fiscal and reputational damage.
Be sure to do this in a managed and controlled way. In that way, from an audit and compliance perspective, you’ll be in line with the information governance frameworks that you employ in production environments. (See Rich Medina’s Defensible Disposition in a Nutshell.)
The key thing to understand is that information risk knows no bounds. It can occur in production environments and interactions with consumers and clients, or it can occur in the “lower regions” of test and development. You’ve gotta govern it all!
I encourage you to learn more about how Doculabs helps companies Discover Information Security issues, Plan how to protect sensitive data and Remediate—migrate and dispose—of sensitive data, including Development and Test information.
Interested in following Doculabs analysis of the links between Information Security and Information Governance? Subscribe to our quarterly newsletter!