Developer

Protect sensitive data everywhere: not just in production

Defending against unwanted network and end-user device intrusions has one objective—protecting the data.  This means protecting the data no matter where it resides or how it moves.  However, this seems to be a problem in some organizations when addressing security for testing (QA) and development environments.

Recently I discovered that an organization I work with stored ePHI (electronic protected health information) and PII in their QA and development systems.  They were making no effort to mask this information.  After asking a few questions, it was obvious that they didn’t ensure appropriate trust levels when moving sensitive data to new or existing testing and developing systems.  When I asked why, they told me that these weren’t production systems so they didn’t need the same level of security.  They also said that even if they wanted to secure the data, the processes needed to do so would cripple their ability to move new or modified solutions through development and QA.

This isn’t the first time I’ve heard this, and I’m not saying there isn’t some truth in what I was told.  But consider this: if the security controls used in production to protect ePHI and PII are considered reasonable and appropriate, then why would an organization provide any less security if the data is copied to a development server?

ePHI and PII is information provided to a company by patients and employees who are entrusting us with one of their most valuable possessions—their identity.  Even if regulations like HIPAA didn’t exist, and even if most states weren’t moving quickly to force companies to take reasonable precautions to protect PII, keeping these identities safe is the ethical path.  So what can a company do to protect this information while maintaining an efficient development process?

One of the easiest ways to both efficiently provide test and development data while protecting employee and customer identities is to mask data elements used to establish a person’s identity.  For example, you might replace several characters in a social security number with X’s.  999-99-9999 becomes 999-xx-xxx9.  There are numerous masking solutions available.  One such solution is Camouflage

Alternatives to masking include encryption, isolating QA and development systems in restricted VLAN’s, or creating test databases that contain fictitious entities.  Once created, these databases can be used for any solution implementation project. 

Regardless of the steps you take, be sure to provide the same level of security in your testing and development environments as you do in production.  Working to secure sensitive information in production, only to copy it to areas that lack the same level of protection, makes very little sense.

About Tom Olzak

Tom is a security researcher for the InfoSec Institute and an IT professional with over 30 years of experience. He has written three books, Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide (to be publish...

Editor's Picks

Free Newsletters, In your Inbox