8-2.4 Configuration and Change Management

All information resources, whether developed in house, outsourced, or acquired must be developed under standard configuration and change management procedures to maximize risk reduction and vulnerabilities introduced by undocumented and untested changes in accordance with the Postal Service change management policy/procedure. Postal Service information resources must not be developed or deployed unless a change and configuration management process is in place.

Configuration and change control involve the systematic proposal, justification, test/evaluation, review, and disposition of proposed changes. Appropriate organizational officials approve information system changes in accordance with this process. Emergency changes are also included in the configuration and change control process.

8-2.4.1 Configuration Component Inventory

To effectively manage information resources, the information system components must be inventoried and the initial or baseline configuration of the information resources must be documented in the corporate Configuration Management Database (CMDB) prior to deployment. The inventory of information system components must include manufacturer, type, serial number, version number, information system/component owner, and location (i.e., physical location and logical position within the information system architecture). The inventory must also designate those information system components required to implement and/or conduct contingency planning operations.

Configurations of information resources must be reviewed at least annually to ensure the documented configuration in the appropriate inventory application matches the current components.

8-2.4.2 Configuration Hardening Standards

Hardware and system software must be hardened to Postal Service information security requirements. Configuration hardening standards must be used to maintain a high level of information security, enable cost-effective and timely maintenance and repair, and protect Postal Service information resources against unexpected vulnerabilities. Critical security patches for PCI-related information resources, including applications and infrastructure, must be installed within 30 days of release. See the manager, Corporate Information Security Office (CISO) Information Security Services (ISS), to request access to a specific Postal Service configuration hardening standard.

8-2.4.3 Change and Version Control

Changes to information resources and configurations must be managed to ensure that Postal Service information resources are not inadvertently exposed to unnecessary risks and vulnerabilities and that only qualified and authorized individuals initiate changes, upgrades, and modifications. Individual access privileges must be approved by appropriate management officials.

All changes must be appropriately approved and documented. Application code changes are managed using version control software. Change control records must be maintained to support and document system software maintenance, software and hardware upgrades, and any local system modifications.

8-2.4.4 Patch Management

An effective patch management process must be implemented to investigate, prioritize, test, track, control the deployment and maintenance of software releases, and resolve known security vulnerabilities. The patch management process must address all information resources installed in the Postal Service computing environment. Security patches must be installed in accordance with the agreed upon schedule and following established evaluation and implementation processes. Critical security patches for PCI- related information resources, including applications and infrastructure, must be installed within 30 days of release. Software security patches must be evaluated on a regular basis. The evaluation period varies by platform and is defined in the applicable hardening standard. If the patch is appropriate for the Postal Service environment, the patch must be tested and approved by Postal Service management prior to implementation. Software patch evaluations and testing must be properly documented and retained in the appropriate repository that is available for audit purposes. Personnel involved in the patch management process must be appropriately trained to ensure a viable vulnerability remediation process.

Patch management involves acquiring, testing, and installing multiple patches (code changes) to software systems, including operating system software, supporting software and packages, firmware, and application software. Patch management tasks include the following:

  1. Maintaining current knowledge of available patches.
  2. Deciding what patches are appropriate for particular information resources.
  3. Prioritizing the patches to be installed.
  4. Testing patches in a nonproduction environment first in order to check for unwanted or unforeseen side effects.
  5. Developing a back-out plan which includes backing up the systems about to be patched to be sure that it is possible to return to a working configuration.
  6. Securing management approval.
  7. Ensuring that patches are installed properly.
  8. Testing information resources after installation.
  9. Documenting all associated procedures, such as specific configurations required.

Patch management is critical to ensure the integrity and reliability of information resources. Patch management should be capable of:

  1. Highly granular patch update and installation administration (i.e., treating patches and mainframes, servers, desktops, and laptops separately).
  2. Tracking machines, and updating and enforcing patches centrally.
  3. Verifying successful deployment on each machine.
  4. Deploying client settings, service packs, patches, hot fixes, and similar items network-wide in a timely manner in order to address immediate threats. Critical security patches for PCI-related information resources, including applications and infrastructure, must be installed within 30 days of release.
  5. Initiating from a central management console.
  6. Providing scheduling, desktop management, and standardization tools to reduce the costs associated with distribution and management.
  7. Providing ongoing deployment for both new and legacy systems in mixed hardware and operating system environments.
  8. Automating the repetitive activity associated with rolling out patches.
  9. Analyzing the operating system and applications to identify possible security holes.
  10. Scanning the entire network (IP address by IP address) and providing information such as service pack level of the machine, missing security patches, key registry entries, weak passwords, users and groups, and more.
  11. Analyzing scan results using filters and reports to proactively secure information resources (e.g., installing service packs and hotfixes).

8-2.4.5 Security Testing of the Configuration

After the information system is changed, the security controls must be checked to ensure the security features are still functioning properly. Periodically (at a minimum annually), the security controls must be tested to ensure the information security controls are functioning as designed and documented.

Significant changes will cause the re-initiation of the C&A process. The criteria for initiating a recertification are defined in Handbook AS-805-A, Information Resource Certification and Accreditation (C&A) Process, 6-2.