Change Control

Change control (also called change management) ensures that any configuration changes taking place in software or hardware will not adversely affect the security or stability of the operational systems. Changes will occur in both the application development process and the normal network and application upgrade process. Any changes to a critical system that could potentially cause those systems to fail are a threat to the ability of the organization to function. Critical systems are those that transmit, process, or store the data vital to accomplishing the mission of an organization. Change control helps ensure that the security policies and infrastructure that have been built to protect the organization are not broken by changes that occur on the system from day to day.

Change management must occur at every stage of the development and maintenance cycles within the organization. In most instances, the person requesting a change, either to the software or hardware, does not totally understand the impact such changes can have on the overall security of the organization. As such, a security administrator must sit within the approval chain for requested changes. The security administrator will review the suggested change and study the potential impact to the security of the organization if the change is allowed. Other individuals within the approval chain will also look for direct or indirect impacts on their own systems that may be caused if a requested change is implemented. The real key is to protect the organization from mission failure due to a system outage because of bad changes.

For the software side, the security administrator must first have a copy or backup of the software that can be called "safe" and "reliable." This is called the baseline and will be the foundation used to compare all changes requested against the system. Baseline software is said to be the most recent approved version of the software that has not been tampered with or altered in any manner. The baseline is constantly progressing as each successful change to the system is made. If a change goes awry, the baseline will also be the working version of the software that will be restored in order to back out of the change process. But if those files are suspect, the entire change control process will fail and the system could be impacted. Listed below are some examples of methods that can be used to verify the integrity of the baseline files:

• Checksums   An example of a checksum algorithm is the Message Digest 5 (MD5) algorithm. It is used in various software to create a cryptographically sound and concise summary of the characters in the file being checked. If a checksum is created against each file in a baseline directory, they can be compared to those checksums run right before a rollback of those files. If the old checksums and the new checksums match, it is relatively certain that the files have not been tampered with or modified inadvertently.

• Digital Signatures   Digital signatures are electronic representations of an individual's identity. When a set of baseline files are stored in case they are needed later, the security administrator can attach their own digital signature to the files to validate their authenticity. If the files are altered, the digital signature becomes invalid and the files will be suspect.

• Host-based Intrusion Detection Systems   Some host-based intrusion detection systems (HIDS) can automatically create checksums for every system-critical file defined by the security administrator. These files are checked on a daily basis, sometimes more often, to ensure their integrity is intact. Should a file be found that does not match the checksum in the database for that file, the security administrator will be alerted immediately. The file is then considered suspect and will likely not be used in the event of a rollback.

• File Integrity Monitors   Once a system has been loaded, patched, updated, and secured, the administrator needs a mechanism for ensuring that the files maintain their integrity and have not been tampered with. File integrity monitors, such as the Tripwire product, allow administrators to "watch" files throughout the day for any unauthorized changes. Should changes to important system files occur, Tripwire will alert the administrator. One important note here: These tools only work for systems that are secure. This would most likely be a new server that has been patched, secured, and protected with a file integrity monitor prior to being put into operational use.

• Software Configuration Management Applications   Software configuration management (SCM) applications allow an easy-to-use interface for controlling the change process and tracking all changes. New versions of software are automatically renumbered as they are implemented providing fast rollback response in the event of a mishap. Although this software makes the process easier, it will not do the research required or make decisions about whether changes can be adopted within the system safely.

Test Day Tip 

Change control, or change management as it is sometimes called, is a common process at many companies. Bear in mind that it does not apply strictly to the software development lifecycle, but is also very important in the network arena. Firmware upgrades on routers, software upgrades on applications, rule changes on firewalls, and other maintenance-based changes in the operational environment should also be included in a change management process.

The goal is to keep a reliable baseline of operational components. Changes are approved by a group of individuals, sometimes called a Change Control Board (CCB), only if each change is said to have no impact on other operational systems that may not have been considered. If an approved change impacts operations within the organization, those changes can be rolled back to a known "safe" baseline environment. Keep this basic premise in mind during the test.

Protecting the system being controlled is the next step. Physical security processes can protect a hardware system from unauthorized change. Secure storage and non-rewriteable storage can be used to protect the integrity of baseline files. Access to these areas should be limited to only those individuals requiring access to manage the change process. These procedures also facilitate a rollback to a previous version of software or prior hardware configuration should the change fail to produce the intended outcome. The change control process never assumes that a change will work as expected and as such, keeps prior versions available until the reliability of the changes can be verified.

Examples of change requests can include hardware changes such as physical device upgrades, swaps, or additions. They can also include upgrades to physical devices such as the basic input/output system (BIOS) upgrades on routers, computers or switches. Redundant Array of Independent (sometimes Inexpensive) Disks (RAID) systems are notorious for having failed disks or power supplies. Replacing those devices also constitutes a change requiring change management.

Examples of software change requests can include changes or upgrades to operational code, service packs or hot fixes on operating system software, or changes to security applications. Changes to a firewall rule set should always fall into the change management process. Those changes could easily impact pieces of the organization not originally considered by the individual or department requesting the change.

Formal policies and processes are used to define the change request and approval processes. These processes define the limitations of implemented changes. For instance, many change control processes require changes to be tested in a mock system prior to being approved for operational systems. Maintenance windows are defined that give a time slot during each day or week that changes will least likely impact the mission-critical operations of the system.

Policies also define the numbering system used to keep old versions of software. Each upgrade or change made to a system has a number associated with it that is incremented as each change occurs. These numbers identify software based on the change made and the date it was implemented. If a rollback must happen, these numbers are vital to determining which version of the software to roll back into the system.

Exam Warning 

The change management process is the key to keeping operational systems in good working order. Remember that the process applies to both software configuration changes (updates, patches, fixes, code revisions) and hardware configuration changes (hardware upgrades, swaps, configuration changes). There can be many different types of change and each one can impact the operational systems.

The change management process is often overseen by a Change/Configuration Control Board (CCB). The board will consist of individuals from different parts of the organization having a vested interest in making sure the operational system in the organization stay operational. Each change is reviewed and approved by each member of the board. If doubts arise about the validity of changes being requested or the impact those changes will have on a system, they will be resolved through the board before they are approved for implementation.

Tools

Putting these controls in place is very important, but how do you enforce these controls and detect violations of the policies? The use of tools for developing these security policies for an organization has become a reality. In most instances, these tools also help detect violations of the policies and prevent the breaches of security. The use of tools makes it easier for smaller security teams to have wider reach and control of information security within the organization.

Policy creation tools normally use some type of best practices template to help security administrators quickly create a comprehensive security policy for their organization. Using fill-in values, the administrators define the organization and the primary mission. Flexibility allows the administrator to pick and choose which pieces of the template to include in the final security policy, be it incident response, secure server configurations, or acceptable use policies.

Policy enforcement tools allow security administrators to ensure that the documented security policies are being adhered to by users on the system. These tools can either be standalone or integrated into one of the policy creation tools. Products by NetIQ, PentaSafe, PoliVec, NFR, and Tripwire all offer solutions for monitoring the configurations of servers and workstations to ensure policy enforcement.

Tool types include clients that monitor security configurations on the computer; watch for intrusion attempts against the box; guard against potential viruses, worms, or logic bombs; and detect and prevent changes to critical files. The exact type and brand of tool used depends on the specific goals of the organization and the size of the security team. No two tools address these issues exactly the same, so it is important to research each one.