System and Application Configuration and Change Management

Any organization that develops or modifies software applications must follow a configuration management method to ensure the integrity of their software. Far too many organizations lack the formal procedures to control changes to their software. Compliance requires formal change procedures. For example, SOX requires that any changes made to software be documented and tracked in such a way that changes can be undone. Further, SOX requires that all development activities and personnel be completely separate from your production environment. Although compliance requires these actions, they are really just good practices.

Software development and maintenance have evolved as more of an art than a science in many organizations. Small organizations with very few software developers commonly approach the development process informally because it is easy to keep track of a few programs and a few people. As an organization grows, the software development and maintenance activities become more complex. It becomes evident that informal procedures no longer provide the level of control needed to maintain a dynamic application’s integrity. One formal method to control the software development life cycle is software configuration management (SCM). SCM provides the activities and requirements to formalize the entire software development process.

SCM requires that all development occur in a separate environment from production. In the most secure environments, the development area is on a server separate from where the completed application runs in production. When developers complete software changes, the changes should move to an isolated testing and quality assurance (QA) environment. Testing and QA personnel test modified software to ensure it complies with the change request requirements and with existing application requirements. Many software changes to fix bugs or add functionality actually cause unintended problems. It is the responsibility of the testing and QA personnel to validate that the newly modified software performs as intended.

Once software changes have been tested and approved, they can be moved into production. SOX requires complete separation between developers and the production environment. Software developers are not allowed to access the production environment at all. Another role, such as a configuration gatekeeper, must move the software to the production environment. This security control limits the ability for software developers to accidentally place untested software in production. Untested code could violate any or all of the three C-I-A properties of data security. The separation between developers and production also stops malicious software developers from placing unauthorized software in production environments.

Regardless of your operating or development environment, it is imperative that your organization implement software configuration management software and controls to manage any changes to software. A solid set of tools will help manage changes, keep untested software from harming your data, and make it far easier to remove and replace offending software if an undiscovered bug does end up in the production environment.