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.
Information security is too often ignored given the speed of software development.
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?
Data from test and development environments are becoming information security targets.
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.)
Traditional information governance in testing and development environments contributes to information security.
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.)
Use information governance to improve information security during software development and testing.
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:
- Store dev-test data in a centralized location. Be sure things get deleted on a quarterly or semi-annual basis, and at least every time you start a new development cycle. (See Jim Polka’s blog, Minimizing the Risk Surface of Unstructured Content for InfoSec: Content Migration.)
- De-identify sensitive data. To lower the risk, you want some obfuscation of the data. You want to de-identify sensitive data sets, such as social security numbers, potentially randomizing some of the information.
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.)
- Implement group access management. People come and go in the dev-test world the same as anywhere else in an organization. That's why you want tightly controlled Identity Access Management (IAM). One way to do that is through group access management. If a person goes away, you can manage the change at the group level instead of at the individual level.
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!