Configuration and Patch Management Planning

Introduction

This document describes the objectives and processes of configuration and patch management and provides expanded guidance on the agency’s responsibility to conduct and manage effective configuration management programs. It also clarifies the requirements for patching of enterprise information system components that receive, store, process or transmit federal tax information (FTI).

Configuration Management

NIST defines CM in SP 800-128 as comprising “a collection of activities focused on establishing and maintaining the integrity of products and systems, through control of the processes for initializing, changing and monitoring the configurations of those products and systems.” An organization’s CM capability directly impacts the security of the organization’s data and must be managed as part of a risk-based protection strategy.

Configuration management (CM) ensures that information system components are configured to optimize compatibility, functionality and performance. Proper CM practices also ensure vulnerabilities and risks are minimized to the greatest extent possible.

The configuration management process:

• Establishes and maintains information system consistency,
• Ensures that system components conform to requirements and are identified and documented in sufficient detail to support the product life cycle,
• Assures accurate system configuration information to support safe operation and maintenance and
• Provides system control to improve capabilities, correct deficiencies, improve performance, reliability, or maintainability, extend system life, reduce cost, risk and liability.

Patch Management

Patch management is a related process for identifying, acquiring, installing and verifying software and/or firmware updates on a recurring basis. An effective patch management program ensures all identified information system components are the latest version, as specified and supported by its vendor.

Patches are usually the most effective way to mitigate software flaw vulnerabilities. Patches may also add new features to software and firmware, including security capabilities. New features may also be added through upgrades, which bring software or firmware to a newer version. Upgrades may also directly fix security and functionality problems in previous versions of software and firmware.

Mandatory Requirements

For FTI systems, application of security patches is a required activity. In terms of patch management, the agency must meet the following mandatory requirements:

1. Security patches for system components that store, transmit, process and/or receive FTI (including, but not limited to, firmware, operating systems, databases and applications) must be applied starting no later than 30 days after availability, and completed by 90 days after availability,
2. Security patches must not be tested on systems with FTI and
3. All system components on FTI systems must be under current vendor support.

These requirements are explained in detail in the sections below.

Security Patches for FTI Systems

Organizational personnel should receive vulnerability and patch alerts from appropriate vendors, the Department of Homeland Security’s US-CERT and other sources, such as the Multi-State Information Sharing and Analysis Center (MS-ISAC).

The organization should establish a formal procedure to review and to acknowledge these alerts, as outlined in IRS Publication 1075, Tax Information Security Guidelines for Federal, State, and Local Agencies (Pub. 1075), Section 4.19 Security Alerts, Advisories, and Directives (SI-5).

Once received, the patches should be prioritized based on the risk associated with the affected system(s) and the nature of the vulnerability being patched. See Figure 1 below for a sample prioritization schedule. For example, the organization’s most critical systems and internet-facing systems that may have increased exposure to threats if running unpatched software should be weighted more heavily in evaluating the rollout of a security patch.

The organization may use the following criteria to prioritize the applications of patches to the production environment:

• Impact to organization data
• Types of systems impacted
• Number of systems impacted
• Access level required to exploit the vulnerability being patched
• How widely known the vulnerability is.

For the purposes of FTI systems, available security patches must be considered in no lower priority than Medium in Figure 1 below, requiring that the distribution of patches to these systems begin within 30 days of availability and be completed within 90 days.

Many vendors offer extended support programs that allow access to previously released patches; however, the vendor no longer reviews software code or provides security or other patches for the product. These extended support programs do not meet the requirement for support of the product for processing FTI.

Configuration Management Guidance

Configuration management may be broken down into four general sets of activities:

• Managing and Planning – Define roles and responsibilities, relationships between stakeholders, establish a change control board and create guidelines based on business and security requirements.
• Identifying and Implementing Configurations – Document information system baseline configurations and establish a configuration control board.
• Controlling Configuration Change -- Develop and implement a controlled change process that includes requests for changes, analysis and evaluation of the change and its impacts, approval/resolution and implementation.
• Monitoring – Ensure that configurations remain sound and comply with business and security requirements.

The following sections discuss components of the first phase of this cycle, Management and Planning, specifically as they apply at the system level – documenting the CM plan and maintaining a system component inventory.

Documenting the Configuration Management Plan

Planning for configuration management at both the enterprise and the system levels requires initially defining and maintaining a CM Plan for the information system (see Pub. 1075, Section 4.5 Configuration Management Plan (CM-9). Some activities may be accomplished at the enterprise level and shared among systems (e.g., configuration change control procedures), while others are specific to the system itself. NIST recommends the following be documented for system configuration management planning:

• Brief description of the subject information system,
• Information system component inventory,
• Information system configuration items,
• Rigor to be applied to managing changes to configuration items (e.g., based on the impact level of the information system),
• Identification of the roles and responsibilities,
• Identification and composition of the group or individual(s) that consider change requests;
• Configuration change control procedures to be followed (including references to organization-wide procedures),
• Identification on the location where CM artifacts (change requests, approvals, etc.) are maintained (e.g., media libraries),
• Access controls employed to control changes to configurations,
• Access controls to protect CM artifacts, records, reports, etc. (e.g., commensurate with system impact level,
• Tools that are used,
• Identification of common secure configurations (e.g., FDCC/USGCB, DISA STIGs, National Checklist Program, etc.) to be used as a basis for establishing approved baseline configurations for the information system,
• Deviations from common secure configurations for configuration items including justifications,
• Criteria for approving baseline configurations for the information system and
• Handling of exceptions to the CM plan (e.g., location of CM artifacts, configuration change control procedures, etc.).

Maintaining a Component Inventory

Documenting and maintaining an inventory of information system components enhances security by identifying all system elements that must be individually managed and secured. Following the organization’s system development lifecycle (SDLC), the components must be tracked from acquisition through retirement/disposition. Per Pub. 1075 Section 4.5, Information System Component Inventory (CM-8), the organization may define the level of granularity necessary for tracking and reporting components to be included in the inventory (e.g., identifying peripheral devices individually or including them as part of a workstation).

Pub. 1075 requires that the inventory include information deemed necessary to achieve effective information system component accountability. To achieve this requirement, NIST recommends the following elements be maintained for every item in the inventory:

• Unique Identifier and/or Serial Number,
• Information System of which the component is a part,
• Type of component (e.g., server, desktop, application),
• Manufacturer/Model information,
• Operating System Type and Version/Service Pack Level (preferably using the appropriate Common Platform Enumeration Name),
• Presence of virtual machines,
• Application Software Version/License information (preferably using the appropriate Common Platform Enumeration Name),
• Physical location (e.g., building/room number),
• Logical location (e.g., IP address),
• Media Access Control (MAC) address,
• Owner,
• Operational status,
• Primary and secondary administrators and
• Primary user (if applicable).

Maintaining this inventory also provides the organization with means to validate compliance with required configurations. The inventory also provides a baseline of components for which vulnerabilities must be monitored and patches applied.

Patch Management Guidance

The organization should develop a detailed patch management process to ensure patches are deployed in a timely manner, meet organizational security requirements and practices and maximize the confidentiality, availability and integrity of information system components and functions.

The IRS patch management process (as described in Internal Revenue Manual 10.8.50) consists of five phases of tasks and activities:

• Assess – Accurately assess the current production environment, prioritize security threats and vulnerabilities and develop a plan to implement patches. This follows from the CM Planning phase and expands to which systems and applications can automatically receive security patches and which require manual installation, and configuring and maintaining distribution tools.
• Identify – Reliably identify new patch updates and ensure they are relevant and virus free, establish a notification method from an authorized source and create a patch criticality ranking that establishes patch priorities, and time frames for patch distribution, installation and application.
• Evaluate and Plan – Test patches to determine any impact to information system components, identify a patch owner and develop a systematic method to deploy security patches into production.
• Deploy – Deploy patches to the production environment, detail results and any configuration changes and communicate stakeholder advisories, acknowledgement time frames and patch reports.

After a patch has been deployed into production, the organization should complete the following steps as part of the Next Steps phase to update current documentation and prepare for future patch releases:

• Document all system changes to both the baseline configuration and the system component inventory,
• Assess system security threats and vulnerabilities,
• Validate appropriate source(s) for information about patch updates,
• Assess the existing software distribution methodology and
• Assess operational effectiveness.

Resources

• Publication 1075, Tax Information Security Guidelines for Federal, State and Local AgenciesPDF
• NIST SP 800-128, Guide for Security-Focused Configuration Management of Information SystemsPDF
• Internal Revenue Manual (IRM) 10.8.50, Information Technology (IT) Security, Servicewide Security Patch Management
• NIST SP 800-53, Revision 5, Recommended Security Controls for Federal Information Systems and OrganizationsPDF
• NIST SP 800-70, National Checklist Program for IT Products-Guidelines for Checklist Users and DevelopersPDF
• NIST SP 800-40, Revision 3, Guide to Enterprise Patch Management TechnologiesPDF
• Appendix C of Treasury Directive P 85-01 (TD P 85-01 Section 3.5)