Link to the home page.
Print from PDF version
 

Security Disciplines for Objective 2: Prevention

2-5. Change Management

Description

Security is achieved by establishing a set of controls, configurations, protocols, policies, and practices. Systems are never static and neither are the controls, because things change. But uncontrolled change means an unknown state of control, so change must be managed. In this way, the state of our security measures, the knowledge of who has access to make changes and what types of changes, will be known at any given time. Capability to roll back changes, if they prove inoperable or problematic, and to change schedules to meet business needs will be possible.

Purpose

Change management is important for minimizing security risks and ensuring business continuity. It describes methods, approaches, and policies which organizations can use to make system changes in a controlled way and to assure that configurations are standardized, documented, and maintained. Different organizations will have varying needs, dependent on such factors as whether software is outsourced or developed in-house and how the network infrastructure is provided and maintained.

Principles

  • All programs, settings, and configurations should be documented, and that documentation should be kept current. The documentation provides an authoritative source for how things are intended to function. Program documentation includes requirement documents that tell the story of what functions the users should expect, design documents that show how the system meets those business needs, documentation of the program code that addresses what business rules are being implemented and the origin of those rules, and data dictionaries that explain what the various data elements are and what the coded values indicate. Network and hardware configurations are documented in network diagrams and in various logs that document setup and maintenance activities.
  • Changes to programs or physical infrastructure should be documented using a change request process. This process should show the reason or source for the change. It should have rules about who in the organization must approve what types of changes.
  • Access to critical systems should be limited and controlled. Limiting access reduces the risk that systems will be compromised and reduces the work involved in incident response. Controls need to be in place to assure that access limits are enforced. Actual access should be monitored and tested.

    The overall approach is to document what we expect the system to look like, to have a process to assure that changes are approved and added to the documentation, and to control who can make changes to the systems.

Policies

Access Control Policy—This policy should address who can have access to critical systems and infrastructure and how this access will be controlled. It should also address the methods to be used to audit compliance. The access control policy should incorporate separation of duties so that any single staff member has a limited scope of influence.

Documentation Policy—This policy should establish what the required documentation should be for each critical system, whether software or hardware. The documentation should address current status or configuration. It should also provide some context for why the system settings are as they are. In software, this may tie back to the business rule that is being implemented. For infrastructure, it should reference overall network design documents.

Change Request Procedure—For each critical system type, this should address how to ask for a change, what information needs to be supplied, who needs to approve that change, how it is to be implemented and tested, and how the change is to be documented in the system documentation.

Audit Plan—Policies are useful, but to assure compliance with controls and procedures, staff needs to understand and expect that there will be some type of periodic audit activity. The audit plan may need to be treated as a confidential document, since it will address how controls are tested.

Best Practices

Evaluate all network design documents, security policy and procedure documents, and application architecture documents from a security risk perspective before publishing or otherwise disclosing them. Create tools and establish practices for reviewing the operation of internal controls and conducting audits of their effectiveness.

Establish procedures and internal controls on how changes can be made to network components, applications, or security settings. Limit the scope of changes that a single individual can make. If possible, require two or more individuals to make changes.

Establish a notification procedure that determines who must be notified for what types of changes and within what time frames. Create and maintain a set of approved standard configurations. When changes are made, the date and time of the change, the objective of the change, the details of the change itself, and the implementing and approving of staff members should be logged.

Establish a procedure for keeping software patches current. Set standards for acceptable elapsed time between the issuance of a patch and its implementation. This includes antivirus software.

Samples of Best Practices

  • Develop and enforce a change management policy.
  • Convene an Infrastructure Configuration Control Board (ICCB) with members of key management and section chiefs.
  • Develop and enforce architectural and engineering standards.
  • Create a test and integration laboratory.

Reference