Home page logo

pen-test logo Penetration Testing mailing list archives

RE: Proof of concept - Segregation of developers
From: WALI <hkhasgiwale () gmail com>
Date: Tue, 06 Mar 2007 21:52:40 +0400

Yes..I am with you kevin ...all the way. The dangers of NOT segregating ( through logical access mechanisms) developers from the production are immense.

I was wondering, if there exists the need to physically separate these guys vlan (disable inter vlan routing etc) of development/test and production environment?

My only concern right now is, the threat of allowing developers be able to ping/netstat/access production servers from their own workstations in development environment, is if they have hard coded a backdoor entry and do stuff in production without authorisation.

Is this concern ..genuine?

At 01:23 PM 3/5/2007 -0600, Dunn, Kevin wrote:

I would submit that by specifying "malicious intent" in your scenario
you are closing off the vast majority of problems that can arise in
environments where strict controls between development, testing, and
production environments are not applied. You original question is very
valid - however I would be interested in responses to a broader question

In my opinion, the majority of problems occur when things are "fixed" in
production. This is a natural impulse, as the overwhelming majority of
people in the information technology field are "fix it" people. We do
not like to see a problem go on for a minute more than necessary.

However, when development teams are allowed access to production for
debugging and remediation, the following items can occur in the "heat of
battle" without any malicious intent.

-- A fix is created and applied - but not applied to the source code
system so the problem re-occurs with the next code update.

-- Unknown exploit code on the developers machine has access to live
production data - potentially HIPPA or trade secret data which can cost
significant resources if exposed.

-- Ad-hoc logging and tracing functions are created, causing problems
later when log files grow in strange, out of the way places and cause a
server to crash due to disk or resource exhaustion.

-- The same ad-hoc logging and tracing functions create logs which
contain sensitive data which are unknown and unmonitored and
subsequently not handled in a secure manner.

-- Debugging code is activated in production which causes un-explained
system slowness.

Unfortunately for the proof of concept aspect of your question - it is
difficult to prove that these thing will occur. However, you can show
through mathematical analysis of an organizations operational and
software defect percentages the likelihood of these items occurring.

Hope these thoughts help. Best wishes on your research, I hope you are
able to share the results with the list.

Kevin Dunn
STATEMENT OF CONFIDENTIALITY: The information contained in this message or any attachments to this message are intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material as well as being protected from disclosure. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer.

This List Sponsored by: Cenzic

Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]