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?

  • 3
    Is the copied data secret or confidential in any way? If so, copying it out of a locked down environment to a looser dev environment does create the opportunity for that information to leak out (due to any temporary flaws in the dev environment).
    – dr jimbob
    Jan 21, 2016 at 20:45
  • The data is not PII but we don't want it leaving the environment. I'm not sure if it was clear in my post but I am allowed to have the data in dev. I'm just not allowed to copy from prod to dev. I would have to re-ETL it in dev Jan 21, 2016 at 20:56
  • It may not be PII, but has it been labeled as OUO (Official Use Only)? Things can be OUO but not PII and still cause a lot of damage if they are leaked. Can you speak to its classification? Jan 21, 2016 at 21:19
  • 1
    Given the confusion around the data in question, I'd lead you in another direction. Specifically, there is no such thing as "A security concern." Something may be, however, "A security concern, because..." I suggest that the first step is for you to go back to your security team and find out what the "because" is. When you know why they think it is a security concern, then you can bring that information back here and we can have a more productive conversation about whether or not we agree with their assessment.
    – Xander
    Jan 22, 2016 at 20:20
  • 1
    If both systems have the same data and both (ostensibly) execute ETL from Source to Target (self in each case) then the real question IMO is why is Dev not locked down as tight as Prod? Unless the link between Prod and Dev is less secure than either to Source this is a silly roadblock.
    – Dave
    Jan 22, 2016 at 20:55

4 Answers 4


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.

  • To correct something I think you may have misunderstood (Or I miss stated) Dev and Prod both have access to the same source data. However it gets ETL'd and put into prod or dev. Same processes (can) run in both. But in dev we don't save everything. I have access to both prod and dev from different accounts. You know what I mean, everything is the same within the two environments except that in DEV we don't run the full historical ETL. We just run subsets to dev Jan 21, 2016 at 21:01
  • @CarlosBribiescas One of the problems we have in software is too much language. Keep in mind when asking questions that security is inherently cross-discipline, and we don't all know what something like ETL might mean, so information gets lost in translation. Jan 21, 2016 at 21:03
  • 1
    Yes, you're right. Let me try to rephrase. We have two environments. Dev and Prod. They both have access to the same sources of data. We usually develop something that will take the source data and transform it many times over and over again for different needs. We're allowed to do this identically in both prod and dev, but we are not allowed to copy from prod to dev. Another restriction is dev doesn't persist all historical data. So prod may have 4 years of data, while dev has a month. Mind you, if I want anything in prod I can run a job to get it in DEV, it just may take a week. Jan 21, 2016 at 21:06

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.

  • So, one clarification. There is not test data. its all the same data. We just don't persist all the data in dev. In any single case, the same data would end up in DEV its just the way it is now, I may have to wait to process it first. Jan 22, 2016 at 19:47
  • You asked "why" a company might prohibit moving data from prod to dev or dev to prod. I tried to answer that question by explaining that a company may have a blanket policy, and that your data may not get to be a special snowflake. Jan 23, 2016 at 2:52

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.


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.

  • As a side note, at my agency we have multiple environments (prod, dev, release candidate, etc.) and all of them are either on their own network segment and completely separated as well as being on their own domains, or they aren't allowed to interconnect at all. We have full staging areas where items can be transferred securely. This may be overkill for some I realize, but it's worked for us so far. Jan 21, 2016 at 21:36

Not the answer you're looking for? Browse other questions tagged .