1

I am reading a book on security which suggest that if you have both development and production server and if you make some change, you should pull them from production server rather pushing them from development server via some means of automated scripts. Here is the whole excerpt:

Content should move to the production server by being pulled from the development server, not by being pushed to it. That is, the transfer of new content or software should be initiated from the production server. It might ask for updates at regular intervals (just as your workstation does), or it could require an administrator to log in and initiate the update. And of course, the process that pulls updates should have read access only on the development server.

So, my question is why this is suggested?

3
  • May I ask what book are you reading? I'd like to check it out.
    – Matrix
    Feb 15, 2014 at 7:42
  • @Matrix Sure, Pro PHP Security amazon.com//dp/1430233184 But remember, it is mainly about application security. So, these topics are less covered. This paragraph as in the question is taken from "Ch 17. Final Recommendation"
    – VarunAgw
    Feb 15, 2014 at 9:05
  • The concept here is one of initiation, and separation of privileges. Funnily enough, if you have to update a large slew of machines, you'll find that there's always some form of pushing.
    – munchkin
    May 12, 2015 at 8:20

4 Answers 4

4

The primary concern is not giving developers write access to production systems. This goes well with the principle of giving someone the least amount of privileges needed to perform a task.

Giving developers write access to production systems poses a few risks. Developer machines are used to surf the net. It's expected because developers need to browse documentation, download software, use Stackoverflow etc. There is a slight chance of them getting compromised by malware. This of course spells disaster if the same developer machine has write access to production. Secondly, giving production write access to developers might open them up to the temptation of pushing to production directly, bypassing things like having review systems in place, ensuring all commits pass unit tests etc. This could very well lead to sloppy code which further opens up the application to compromise.

3

In the event the development server is compromised, it would become easier to access production (development sometimes have lower security requirements).

This is also in the spirit of Segregation of Duties.This is a classic security method to manage conflict of interest, the appearance of conflict of interest, and fraud. It restricts the amount of power held by any one individual. Developers are never allowed onto production as there would be a risk for fraud (from the perspective of a financial audit). Code should also never be pulled from production without review (four-eyes principle).

There are exceptions to this rule in case of emergencies, but this are only used under extreme circumstances when there is risk to business continuity. And even then these accounts will be heavily audited on usage during and after the developer had access. These accounts are normally always locked and can only be unlocked after formal business approval as well as approval from the security office and responsible IT manager.

2

Clarification of the Question

Most of the answers thus far make the assumption that the passage cited in the question refers to changes originating on individual developers' workstations.

To the contrary, the passage refers to change-propagation between a development server and a production server. The author should have used more appropriate terminology for the most common use-case: propagating changes from a "testing" or "staging" server to a production server. The phrasing in the cited passage is awkward, too, but the gist is that the change-propagation process should always be initiated from the production server -- that is, changes are "pulled" from the development server, not "pushed" from the development/testing/staging server.

The Rationale

The rationale is simple: in most cases, it makes a lot more sense to give a production environment access to a development (or testing/staging) server than the other way around. If the production server is compromised, the likelihood of additional harm resulting from the attacker "leapfrogging" into the development server is minimal (at least provided best-practices are observed and there is nothing "sensitive" on the development server, particularly in the way of credentials to other systems or "real" data). It goes without saying that credentials to other internal systems, real customer data, etc., should never be propagated to a development server.

A Related Aside

In cases in which a thorny problem absolutely requires access to production data, special care should be taken to "sandbox" the data in an offline, isolated system with extremely limited access. The data on such a system should be destroyed immediately after the problem is resolved. For problems that require access to other systems to be reproduced, such as a web-server that requires access to a data-warehouse instance, every effort should be made to "mock" whatever functionality the dependency provides and eliminate the need to connect the systems.

Exception to the Rule

One exception to the "rule" that the author describes is when the development server is inside the firewall and the production server is in the DMZ. In such cases, it may be that the production server cannot initiate communication with the development server (thereby making the "pull" strategy impossible), but the development server is able to initiate communication with the production server. In such topologies, in which this one-way initiation is by-design, it may be necessary to push changes from development to production.

In such cases, the credentials required to connect from development to production should be highly-guarded and should never be stored on the development server (e.g., in the form of an SSH key without a password). Further, any individual who is authorized to connect to the development server and initiate a push to production should be forced to log into his own account on both systems (accounts should never be shared among users, as doing so compromises accountability).

If root-level access on either system is required to complete the propagation, a sudo-like implementation should be employed if at all possible, as such a mechanism improves accountability tremendously.

1

Contemplate what happens if someone spoofs your development server. If the prod server is configured to accept the update, it is completely owned.

If changes are pulled, rather than pushed. it is more difficult to spoof.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.