Ineffective operating system level security can jeopardize your entire SCM operations and the hundreds of millions of dollars of software assets you are trying to control. It is important to match SCM to your company’s security model and use OS security to exercise control over application runtime environments, which CCM tools typically do not control. Here are some important guidelines for using operating system security to provide robust SCM for Windows and *NIX platforms.
Understand Your Company’s Security Model
Your company’s security model, likely stops at securing hardware, operating system (OS) and database management system (DBMS) security. By operating system I am referring to the base operating system such as Windows 2000 or AIX and the mechanisms these OS’s use to secure file systems. I won’t belabor web security here because a web server is just an application on top of network (hardware), DBMS and OS security.
Hardware and OS security are relatively mature fields and your company’s security policies are likely to be widely understood and implemented. SCM, on the other hand, is often not as well understood throughout the organization and its implementation given a later start. This is to be expected since SCM is in many respects an extension, or specialized form of, security that includes additional change controls and reporting.
While OS security attempts to secure file and memory objects, and database security database objects, SCM attempts to secure and control changes to business objects that (should) map reasonable well to the file, memory and database objects. Since SCM usually involves getting into the nitty-gritty of files and database objects, you should understand the ins and outs of your company’s policies and conform to them to avoid run-in’s with you security organization.
Make Sure Security Is Implemented
Secondly, make sure your company’s security model is actually implemented to the detail you need for the applications you have or intend to have under SCM. If you are tasked with implementing SCM for a particular mission critical application and it is not locked down according to your company’s guidelines, then guess what? You’re going to be implementing OS level security also! Otherwise, you can’t trust the integrity of the file and database objects that the enterprise objects are based on. And then what’s the point of managing objects that you can’t trust the integrity of?
Many Enterprise-oriented SCM tools today require effective OS and DBMS level security measures, not surprisingly. They are no different than any other application in this regard, including web servers. Without these measures in place the control functions of your SCM tool can be bypassed or otherwise put at risk.
You may find that your company’s security policies are not detailed enough or otherwise inadequate to protect your enterprise objects. You may also find the policies are too strict and inhibit highly beneficial SCM controls or audit functions. Work closely with your security organization to make modifications with the understanding that you are working toward a common goal.
Securing Application QA Test and Production Runtime Environments
Unlike the mainframe, few distributed platforms CCM tools attempt to manage application runtime environments. This very important area is the machine and location on the machine where the application actually executes. To implement effective SCM, you must resort to the design and implementation of OS-level security measures in addition to mastering one or more software tools designed for SCM functions.
Aside from preventing malicious changes or disruptions to the application, OS-level security measures can act as a change control mechanism, limiting access to those who with the appropriate role to change them. This in turn has two consequences: greater segregation and clarity of roles and responsibilities, and reduction of change volume.
The benefits of locking down the production runtime environment to a limited few charged with production control responsibilities has long been known. On the distributed platforms you have little choice but to employ OS level security, including managing the passwords to the machines themselves. This concept should also be extended to critical QA test environments.
A classic example of the utility