with source code in the development environment and transferring the executable to the test environment.The problem is now that it is too easy to make changes to the test environment, and those changes are not made in a controlled manner. The test environment effectively becomes a development environment too, and with only a few corrections made, the integrity of both the development and testing configurations come into question. This disrupts what is a normally a linear process of develop-and-then-test creating something more murky. It happens that the code is then released directly to production from the QA test environment, and no one can remember what changes were made where after the next round of Unreal Tournament.By limiting access to the test environment to the testers, much greater accountability is placed on the testers for the integrity of that environment. Greater segregation and clarity of the activities in the test environment is achieved and the tester won’t have to point a finger at the developer as being responsible for supposedly “fixing” the defect that led to a successful QA test but failed in production. The testers are equally responsible. This tighter access requires a robust turnover mechanism so that the handoff of changes from development to QA is repeatable and efficient. This is where we look for CCM tools to provide the functionality.
It can’t be emphasized enough that the OS must be secured prior to utilizing application SCM. I see examples, about once per year per machine in secure environments, where the system administrators (those immune to OS security measures) mistakenly change the file owners or permissions, remove links or just plain delete something they shouldn’t have. The command line nature of *NIX administration and the muddy line between application and OS on Windows means mistakes will happen every now and then. The point is that if this happens in secure environments, then imagine the situation in more unsecured environments.
A more surreptitious problem occurs with development tool runtime environments. These runtime environments refer to a set of executables (not file locations as in the production and QA test environments). They are closely associated with the operating system, so that an update to the operating system can alter the runtime environment and crash the application. This is as important in Windows environments as *NIX, the difference being that typically only a system administrator has access to make these changes on *NIX.
A real-life instance of this occurred due to an innocent update made to an Oracle client by the system administrator on a UNIX machine. This happened on a development server, and the developers, from their point of view, inexplicably started getting compile errors building their C++ application. Unbeknownst to all, the update to the Oracle client included an operating system patch that upgraded the C/C++ runtime executables and libraries. The system administrator had installed the update as the root user, which bypasses OS file security. The operation of the application was put at great risk since this was the only build server for this marketing application. The developers would have been unable to build a production fix if it were necessary until they backed out the Oracle client and the OS and C/C++ runtime patch. This shows the need to lock down the development tool runtime environments and involve operating system administrators in SCM. In this case, there was an approval-based change system in place, but the impact was not fully assessed ahead of time.
As they say, HTH. Hope this helps. Here is a summary of what we’ve covered:
- Understand your company’s security model down to the