You ask about separating access to development and production environment software and its components. Software developers should not have access to software components that are running in a production environment, since keeping limited access prevents potential fraudulent activities and ensures the availability and stability of the environment. If software developers need to tweak some software component that is in a live production environment, they -- like everyone else -- should follow a change control process. Such a procedure evaluates the problem, calculates implementation costs, designs a fix and reviews the fix's ramifications; examples would be if the fix causes interoperability issues with other software, if it opens a new vulnerability or if it negatively affects availability. The fix is then built on development (not production) systems, and then tested by another person or group in charge of quality assurance. After the fix is documented, the software version is increased to demonstrate its change, and then the fix is deployed. When working with in-house developers, have them save their code to a database that carries out version control, and back it up either each day or each week.
Organizations cannot implement separation of duties without establishing logical controls. Every organization should be able to configure their access controls to allow authorized individuals to access the necessary resources. This can be done at the domain level, resource level, and file and directory level. If an organization cannot purchase a software package that specifically provides a separation of duties functionality, then they'll need to implement tight access control with strict individual accountability and thorough management supervision.
It's easier to implement separation of duties if solely attempting to ensure that developers do not interact with production code and operational employees do not interact with development code. In this case, simply configure the access control lists on the different libraries and set which operations each user or group can carry out. You can also implement an automated configuration management tool like Tripwire to detect any changes in production code.
It's also worth noting that it's much more difficult to implement separation of duties when you have to split up actual transaction steps or business processes that take place across more than one application or system. Because of the complexity that is involved with these more intrinsic activities, there are products that automate such implementations. They allow the administrator to set the rules through a rule engine and enforce them when a user tries to carry out various operations.
This was first published in November 2006