Is reading from prod to dev a security concern? [closed]

Question

We have two environments, both of which have access to the same data sources. However, prod is locked down (reasonably so) while dev can be written/read by developers.

Data flows from the source through the ETL process and end up in various places. Usually mirrored in folder structure. I would like access to an intermediary dataset to do some development. The Security expert on our team claims its a security concern to allow me to copy from prod to dev. (Not modify prod)

I'm not a security expert, but in this case it seems like there is very little security risk since the data is allowed in both places, it just much more of it exists in prod than in dev. Can someone clarify why this is such a big concern?

Answer 1

I don't think it's possible to answer this generally. But I can think of some things that MIGHT be valid.

1. Prod has data in it that should only be viewed by certain people. Since prod normally feeds dev, the "secret data" would have to be mitigated in some way before it gets to dev, or the data itself is time sensitive. If it's not, then the only difference between prod and dev is dev is generally older.
2. Prod has sensitive usernames/passwords/configuration items that shouldn't be given to developers.

At the least though, your security expert should be able to identify the REASON behind the security concern rather than you having to guess at them. If he's not, he's simply using his authority unreasonably, and not working towards a solution that meets everyones needs.

Answer 2

It's possible that a company subject to PCI or HIPAA audits may need to write a security policy prohibiting sharing data between dev and prod in order to comply with the data security standards, but it's also possible they wrote the policy so that it applies to all data, not just the PCI or health data.

This is not necessarily a bad thing. Security isn't just defending against attack, but about protecting against risks in general. Plenty of problems have been caused by data crossing the boundary in either direction, and following a good policy can prevent losses.

A bank had a famous example of a problem that could have been prevented by following this policy. They decided to send a solicitation letter out to their thousand top customers. Of course, some developer had entered a clever fake name in their test database. Due to a mixup between dev and prod, the letters went out to all of their good customers with the greeting "Dear Rich Bastard". While not a 'security' risk in the sense that an attacker didn't cause it, they may have lost some good customers because of this mistake.

Conversely, copying data from prod to dev can open up holes in your secured environment. You could argue on a case-by-case basis why data X is safe to move to dev while data Y is not safe to move, but even that introduces risk. Who authorizes the data is safe to move? Who ensures that only the safe data is moved, but not the sensitive data? Are firewall ports opened to move the data, and if so, who opens and closes them? Who audits the movement of the data? Who audits the firewall ports were closed? There are a lot of moving parts, any of which can fail leaving your data or systems exposed.

A single policy that prohibits such movement eliminates the risk, but at a cost. You now need to expend resources to create the test data. This is where you can make a business case: the cost of the policy is X, the risk avoided by the policy is Y, is it worth it? Just by starting the analysis, you may quickly arrive at the conclusion that it's not worth pursuing.

Answer 3

Production and non-production environments should be isolated as a best practice. Your non-production environments likely have less monitoring, may have unsafe code, may not have updated machines, etc.

If you have anything that can go between these environments you are increasing the risk of:

• Malware traversing from dev to prod
• Confusion and mixing of group memberships or permissions
• People accidentally using dev for production processes or decision making
• People being confused about where they are accessing information

If you have one ETL process that sends the same data to production and non-production, you also may be violating data privacy requirements/policies or external requirements like from HIPAA or PCI.

In general, data should not go from production to development or vice a versa. Only code should be migrated from dev to production through a well defined and controlled process.

You should probably not be sharing authentication systems or at least accounts between both environments either. You may not even want to use production accounts for "training" environments. Production systems should remain isolated from anything non-prod.

I have seen non-production and test environments where all sorts of weird stuff was permitted, where accounts were shared between developers, were data was dumped, logged, and analyzed in ways which would not be acceptable for production data at any organization.

---

Reading some of your comments to other answers: It sounds like a concern may be too much data being permitted into the dev environment. It's not clear if you are sanitizing data, but it may be an acceptable risk to have 1 month of data in dev, but putting 5 years worth is too much of a risk exposure.

I will update my answer if you add more details to your question.

Answer 4

I can't speak fully as to why your local security officer considers this a security risk/concern, but I can tell you two things that I'm guessing he's thinking; even if he isn't thinking these, this will be my answer as this is what I would be concerned with if I were the local security officer at your organization:

1. You mentioned prod is locked down, and dev not so much. My first concern would be sensitive company data, that may not contain PII, but may be OUO (Official Use Only) would be leaked, and have a much greater chance of being leaked or manipulated as it doesn't appear to have the tight security controls that dev does. Again I can only go off of the context you set in your question, but if company information isn't as tightly controlled in dev as it is in prod then I can definitely see the concern from your security guy/gal.
2. You also mentioned that data can flow from prod to dev and (I shouldn't do this, but I assume vice versa; from dev to prod) if data can flow from at least prod to dev then there has to be a physical/logical network connection between the two. Again, production environments should be subject to tighter security controls so as to protect the data you're referring to. If there is a network connection then to me that is an entry point for potentially malicious risks to enter into prod. I'm not necessarily talking about viruses per se (however this threat could be very real if your dev environment, like most, has a very relaxed security posture and allows all sorts of configurations and software and other processes to be installed and/or take place), rather any sort of malicious vector that could result in the compromise of integrity, confidentiality or availability due to the (physical or logical) network connection from prod to dev. I'm sure there are firewalls involved, however I'm not aware of what kind of ACLs or other access policies you guys have in place. This, again, would warrant concern from your security officer.

This isn't gospel, but this is coming from a security professional who thinks a lot like your guy/gal.

Hopefully that can give you some more insight into what they're thinking.