Secure All Software Environments, Not Just Production

Imagine for a moment, you’re a project manager at the Federal Emergency Management Agency (FEMA), and you’re in the midst of a number of catastrophes consuming people, their homes, and their lives. Your responsibility is to help as quickly as humanly possible, and your job involves leading efforts to put out the wildfires, rescue people from flooding, and plan the repair and rebuilding once the crisis has passed.

The contractors you hire need more than just a statement of work and a purchase order, they need the right information and data points to get the job done. Fast forward a year later, you find out that in your zeal to accomplish your mission, you may have provided too much information to one of your contractors. Luckily, it wasn't an actual data breach — nobody broke in, and no data was misused.

But now, you’re under the microscope for a mistake you made under pressure. After your unrelenting efforts to help people, a moment's inattention while including a few additional columns when building your spreadsheet might bring disgrace to your organization and probably an end to your career as well.

Was there a mistake made? Yes, indeed. But in making this mistake, are you solely responsible? Definitely not. Here’s why.

IT Honor Code is Outmoded

Most, if not all, IT organizations have been extremely lax about data security for decades, going all the way back to the dawn of computing. Many have relied on the IT honor code as the main line of defense. The necessity for the honor code has been hammered into us, implying that we have been "privileged" with access to data that we should not see, and that we must be careful not to do anything with that privilege. As a result, the industry has largely been content to rely on this approach.

In addition, the honor code only protects the organization, but it does not protect the people employing it. Think about it this way: if anything goes wrong, investigators must focus on what is possible, not on what is intended. One must be more than unwilling to do the wrong thing, one must be unable to do so — an honor code does not provide this protection.

It’s not until recently that more and more organizations have bothered to proactively protect personal and confidential data.

The Data Security Conundrum

On production systems, authentication, authorization, and auditing by applications and data security teams ensure that data is handled appropriately. But for non-production environments, used for development, maintenance, and testing, there’s an enormous increase in the surface area of risk for exposure of sensitive production data.

Non-prod environments are almost always copies of production environments because it’s difficult for generated data to realistically simulate data conditions found in production. Hence, software development teams make copies or clones of production for non-production use to yield better systems and software.

Yet herein lies the conundrum...

Real data provides realistic cases for thorough and complete testing, but real data also contains confidential information about the organization, its employees, and its customers.

As a result, copying and cloning all of that confidential information to more and more non-production environments presents an increasing risk that somebody somewhere will accidentally or purposefully expose it.

In addition, current trends exacerbate the problem. Gone are the days when organizations built their own IT systems in-house and on-premise. Outsourcing, off-shoring, internetworking, and the cloud require that data be sent out of reach of an organization’s data security team.

How to Win the Data Game

The key is providing developers and testers with realistic, but not real data. Data masking, also referred to as obfuscation, is a method of protecting sensitive data by replacing the original value with a fictitious but realistic equivalent. Data cannot cause any harm if it falls into the wrong hands.

By masking data as it's copied or cloned from production to non-production systems, an enormous and purposeful exposure of confidential data is averted. Artful masking retains all the realism, such as the distribution of popular and unpopular data values, but imparts nothing useful to a criminal.

So if you don’t want your software developers or testers to be liable for exposing personal data, they shouldn’t have access to it in the first place. They should only be authorized to review and modify code. A foundational change in how data is accessed, managed, secured, and leveraged across the enterprise is key to dramatically reducing your company’s risk of a data breach.

If you’d like to hear more from Tim Gorman on how to accelerate QA/Testing securely using data masking and virtualization, be sure to check out his session at Quest 2019 on May 17 in Chicago.