Configuration Management (CM)¶

CM.L2-3.4.1 – System Baselining¶

Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 26.

Determine if:

• [a] a baseline configuration is established;
• [b] the baseline configuration includes hardware, software, firmware, and documentation;
• [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;
• [d] a system inventory is established;
• [e] the system inventory includes hardware, software, firmware, and documentation; and
• [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 26.

Examine: [SELECT FROM: Configuration management policy; procedures addressing the baseline configuration of the system; procedures addressing system inventory; system security plan; configuration management plan; system inventory records; inventory review and update records; enterprise architecture documentation; system design documentation; system architecture and configuration documentation; system configuration settings and associated documentation; change control records; system component installation records; system component removal records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with configuration management responsibilities; personnel with responsibilities for establishing the system inventory; personnel with responsibilities for updating the system inventory; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Organizational processes for managing baseline configurations; mechanisms supporting configuration control of the baseline configuration; organizational processes for developing and documenting an inventory of system components; organizational processes for updating inventory of system components; mechanisms supporting or implementing the system inventory; mechanisms implementing updating of the system inventory].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 20.

This requirement establishes and maintains baseline configurations for systems and system components including for system communications and connectivity. Baseline configurations are documented, formally reviewed, and agreed-upon sets of specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and changes to systems. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and update and patch information on operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of those components within the system architecture. Baseline configurations of systems also reflect the current enterprise architecture. Maintaining effective baseline configurations requires creating new baselines as organizational systems change over time. Baseline configuration maintenance includes reviewing and updating the baseline configuration when changes are made based on security risks and deviations from the established baseline configuration. Organizations can implement centralized system component inventories that include components from multiple organizational systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., system association, system owner). Information deemed necessary for effective accountability of system components includes hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include manufacturer, device type, model, serial number, and physical location. NIST SP 800-128 provides guidance on security-focused configuration management.

Further Discussion¶

An effective cybersecurity program depends on consistent, secure system and component configuration and management. Build and configure systems from a known, secure, and approved configuration baseline. This includes:

• documenting the software and configuration settings of a system;
• placement within the network; and
• other specifications as required by the organization.

Examples¶

• You are in charge of upgrading the computer operating systems of your office’s computers. Some of these computers process, store, or transmit CUI. You research how to set up and configure a workstation with the least functionality and highest security and use that as the framework for creating a configuration that minimizes functionality while still allowing users to do their tasks. After testing the new baseline on a single workstation, you document this configuration and apply it to the other computers [a]. You then check to make sure that the software changes are accurately reflected in your master system inventory [e]. Finally, you set a calendar reminder to review the baseline in three months [f].

Potential Assessment Considerations¶

• Do baseline configurations include software versions and patch level, configuration parameters, network information, and communications with connected systems [a,b]?
• Are baseline configurations updated as needed to accommodate security risks or software changes [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.4.1

CM.L2-3.4.2 – Security Configuration Enforcement¶

Establish and enforce security configuration settings for information technology products employed in organizational systems.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 26-27.

Determine if:

• [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and
• [b] security configuration settings for information technology products employed in the system are enforced.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 26-27.

Examine: [SELECT FROM: Configuration management policy; baseline configuration; procedures addressing configuration settings for the system; configuration management plan; system security plan; system design documentation; system configuration settings and associated documentation; security configuration checklists; evidence supporting approved deviations from established configuration settings; change control records; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with security configuration management responsibilities; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Organizational processes for managing configuration settings; mechanisms that implement, monitor, and/or control system configuration settings; mechanisms that identify and/or document deviations from established configuration settings; processes for managing baseline configurations; mechanisms supporting configuration control of baseline configurations].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 21.

Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture or functionality of the system. Information technology products for which security-related configuration settings can be defined include mainframe computers, servers, workstations, input and output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security parameters are those parameters impacting the security state of systems including the parameters required to satisfy other security requirements. Security parameters include: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. NIST SP 800-70 and SP 800-128 provide guidance on security configuration settings.

Further Discussion¶

Information security is an integral part of a company’s configuration management process. Security-related configuration settings are customized to satisfy the company’s security requirements and are applied them to all systems once tested and approved. The configuration settings must reflect the most restrictive settings that are appropriate for the system. Any required deviations from the baseline are reviewed, documented, and approved.

Examples¶

• You manage baseline configurations for your company’s systems, including those that process, store, and transmit CUI. As part of this, you download a secure configuration guide for each of your asset types (servers, workstations, network components, operating systems, middleware, and applications) from a well-known and trusted IT security organization. You then apply all of the settings that you can while still ensuring the assets can perform the role for which they are needed. Once you have the configuration settings identified and tested, you document them to ensure all applicable machines can be configured the same way [a,b].

Potential Assessment Considerations¶

• Do security settings reflect the most restrictive settings appropriate [a]?
• Are changes or deviations to security settings documented [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.4.2

CM.L2-3.4.3 – System Change Management¶

Track, review, approve or disapprove, and log changes to organizational systems.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 27.

Determine if:

• [a] changes to the system are tracked;
• [b] changes to the system are reviewed;
• [c] changes to the system are approved or disapproved; and
• [d] changes to the system are logged.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 27.

Examine: [SELECT FROM: Configuration management policy; procedures addressing system configuration change control; configuration management plan; system architecture and configuration documentation; system security plan; change control records; system audit logs and records; change control audit and review reports; agenda/minutes from configuration change control oversight meetings; other relevant documents or records].

Interview: [SELECT FROM: Personnel with configuration change control responsibilities; personnel with information security responsibilities; system or network administrators; members of change control board or similar].

Test: [SELECT FROM: Organizational processes for configuration change control; mechanisms that implement configuration change control].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 21 Processes for managing configuration changes to systems include Configuration Control

Tracking, reviewing, approving/disapproving, and logging changes is called configuration change control. Configuration change control for organizational systems involves the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled and unauthorized changes, and changes to remediate vulnerabilities.

Boards or Change Advisory Boards that review and approve proposed changes to systems. For new development systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards or Change Advisory Boards. Audit logs of changes include activities before and after changes are made to organizational systems and the activities required to implement such changes. NIST SP 800-128 provides guidance on configuration change control.

Further Discussion¶

You must track, review, and approve configuration changes before committing to production. Changes to computing environments can create unintended and unforeseen issues that can affect the security and availability of the systems, including those that process CUI. Relevant experts and stakeholders must review and approve proposed changes. They should discuss potential impacts before the organization puts the changes in place. Relevant items include changes to the physical environment and to the systems hosted within it.

Examples¶

• Once a month, the management and technical team leads join a change control board meeting. During this meeting, everyone reviews all proposed changes to the environment [b,c]. This includes changes to the physical and computing environments. The meeting ensures that relevant subject-matter experts review changes and propose alternatives where needed.

Potential Assessment Considerations¶

• Are changes to the system authorized by company management and documented [a,b,c,d]?
• Are changes documented and tracked (e.g., manually written down or included in a tracking service such as a ticketing system) [d]?

Key References¶

• NIST SP 800-171 Rev. 2 3.4.3

CM.L2-3.4.4 – Security Impact Analysis¶

Analyze the security impact of changes prior to implementation.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 27.

Determine if:

• [a] the security impact of changes to the system is analyzed prior to implementation.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 27.

Examine: [SELECT FROM: Configuration management policy; procedures addressing security impact analysis for system changes; configuration management plan; security impact analysis documentation; system security plan; analysis tools and associated outputs; change control records; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibility for conducting security impact analysis; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Organizational processes for security impact analysis].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 21-22.

Organizational personnel with information security responsibilities (e.g., system administrators, system security officers, system security managers, and systems security engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills and technical expertise to analyze the changes to systems and the associated security ramifications. Security impact analysis may include reviewing security plans to understand security requirements and reviewing system design documentation to understand the implementation of controls and how specific changes might affect the controls. Security impact analyses may also include risk assessments to better understand the impact of the changes and to determine if additional controls are required. NIST SP 800-128 provides guidance on configuration change control and security impact analysis.

Further Discussion¶

Changes to complex environments are reviewed for potential security impact before implemented. Changes to IT systems can cause unforeseen problems and have unintended consequences for both users and the security of the operating environment. Analyze the security impact of changes prior to implementing them. This can uncover and mitigate potential problems before they occur.

Examples¶

• You have been asked to deploy a new web browser plug-in. Your standard change management process requires that you produce a detailed plan for the change, including a review of its potential security impact. A subject-matter expert who did not submit the change reviews the plan and tests the new plug-in for functionality and security. You update the change plan based on the expert’s findings and submit it to the change control board for final approval [a].

Potential Assessment Considerations¶

• Are configuration changes tested, validated, and documented before installing them on the operational system [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.4.4

CM.L2-3.4.5 – Access Restrictions for Change¶

Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 28.

Determine if:

• [a] physical access restrictions associated with changes to the system are defined;
• [b] physical access restrictions associated with changes to the system are documented;
• [c] physical access restrictions associated with changes to the system are approved;
• [d] physical access restrictions associated with changes to the system are enforced;
• [e] logical access restrictions associated with changes to the system are defined;
• [f] logical access restrictions associated with changes to the system are documented;
• [g] logical access restrictions associated with changes to the system are approved; and
• [h] logical access restrictions associated with changes to the system are enforced.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 28.

Examine: [SELECT FROM: Configuration management policy; procedures addressing access restrictions for changes to the system; system security plan; configuration management plan; system design documentation; system architecture and configuration documentation; system configuration settings and associated documentation; logical access approvals; physical access approvals; access credentials; change control records; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with logical access control responsibilities; personnel with physical access control responsibilities; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Organizational processes for managing access restrictions associated with changes to the system; mechanisms supporting, implementing, and enforcing access restrictions associated with changes to the system].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 22.

Any changes to the hardware, software, or firmware components of systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access systems for purposes of initiating changes, including upgrades and modifications. Access restrictions for change also include software libraries. Access restrictions include physical and logical access control requirements, workflow automation, media libraries, abstract layers (e.g., changes implemented into external interfaces rather than directly into systems), and change windows (e.g., changes occur only during certain specified times). In addition to security concerns, commonly-accepted due diligence for configuration management includes access restrictions as an essential part in ensuring the ability to effectively manage the configuration. NIST SP 800-128 provides guidance on configuration change control.

Further Discussion¶

Define, identify, and document qualified individuals authorized to make physical and logical changes to the organization’s hardware, software, software libraries, or firmware components. Control of configuration management activities may involve:

• physical access control that prohibits unauthorized users from gaining physical access to an asset (e.g., requiring a special key card to enter a server room);
• logical access control that prevents unauthorized users from logging onto a system to make configuration changes (e.g., requiring specific credentials for modifying configuration settings, patching software, or updating software libraries);
• workflow automation in which configuration management workflow rules define human tasks and data or files are routed between people authorized to do configuration management based on pre-defined business rules (e.g., passing an electronic form to a manager requesting approval of configuration change made by an authorized employee);
• an abstraction layer for configuration management that requires changes be made from an external system through constrained interface (e.g., software updates can only be made from a patch management system with a specific IP address); and
• utilization of a configuration management change window (e.g., software updates are only allowed between 8:00 AM and 10:00 AM or between 6:00 PM and 8:00 PM).

Examples¶

• Your datacenter requires expanded storage capacity in a server. The change has been approved, and security is planning to allow an external technician to access the building at a specific date and time under the supervision of a manager [a,b,c,d]. A system administrator creates a temporary privileged account that can be used to log into the server’s operating system and update storage settings [e,f,g]. On the appointed day, the technician is escorted into the datacenter, upgrades the hardware, expands the storage in the operating system (OS), and departs. The manager verifies the upgrade and disables the privileged account [h].

Potential Assessment Considerations¶

• Are only employees who are approved to make physical or logical changes on systems allowed to do so [a,d,e,h]?
• Are authorized personnel approved and documented by the service owner and IT security [a,e]?
• Does all change documentation include the name of the authorized employee making the change [b,d,f,h]?

Key References¶

• NIST SP 800-171 Rev. 2 3.4.5

CM.L2-3.4.6 – Least Functionality¶

Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 28-29.

Determine if:

• [a] essential system capabilities are defined based on the principle of least functionality; and
• [b] the system is configured to provide only the defined essential capabilities.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 28-29.

Examine: [SELECT FROM: Configuration management policy; configuration management plan; procedures addressing least functionality in the system; system security plan; system design documentation; system configuration settings and associated documentation; security configuration checklists; other relevant documents or records].

Interview: [SELECT FROM: Personnel with security configuration management responsibilities; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Organizational processes prohibiting or restricting functions, ports, protocols, or services; mechanisms implementing restrictions or prohibition of functions, ports, protocols, or services].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 22.

Systems can provide a wide variety of functions and services. Some of the functions and services routinely provided by default, may not be necessary to support essential organizational missions, functions, or operations. It is sometimes convenient to provide multiple services from single system components. However, doing so increases risk over limiting the services provided by any one component. Where feasible, organizations limit component functionality to a single function per component. Organizations review functions and services provided by systems or components of systems, to determine which functions and services are candidates for elimination. Organizations disable unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of devices, transfer of information, and tunneling. Organizations can utilize network scanning tools, intrusion detection and prevention systems, and end-point protections such as firewalls and host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports, protocols, and services.

Further Discussion¶

You should customize organizational systems to remove non-essential applications and disable unnecessary services. Systems come with many unnecessary applications and settings enabled by default including unused ports and protocols. Leave only the fewest capabilities necessary for the systems to operate effectively.

Examples¶

• You have ordered a new server, which has arrived with a number of free utilities installed in addition to the operating system. Before you deploy the server, you research the utilities to determine which ones can be eliminated without impacting functionality. You remove the unneeded software, then move on to disable unused ports and services. The server that enters production therefore has only the essential capabilities enabled for the system to function in its role [a,b].

Potential Assessment Considerations¶

• Are the roles and functions for each system identified along with the software and services required to perform those functions [a]?
• Are the software and services required for those defined functions identified [a]?
• Is the information system configured to exclude any function not needed in the operational environment [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.4.6

CM.L2-3.4.7 – Nonessential Functionality¶

Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 29.

Determine if:

• [a] essential programs are defined;
• [b] the use of nonessential programs is defined;
• [c] the use of nonessential programs is restricted, disabled, or prevented as defined;
• [d] essential functions are defined;
• [e] the use of nonessential functions is defined;
• [f] the use of nonessential functions is restricted, disabled, or prevented as defined;
• [g] essential ports are defined;
• [h] the use of nonessential ports is defined;
• [i] the use of nonessential ports is restricted, disabled, or prevented as defined;
• [j] essential protocols are defined;
• [k] the use of nonessential protocols is defined;
• [l] the use of nonessential protocols is restricted, disabled, or prevented as defined;
• [m] essential services are defined;
• [n] the use of nonessential services is defined; and
• [o] the use of nonessential services is restricted, disabled, or prevented as defined.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 29.

Examine: [SELECT FROM: Configuration management policy; procedures addressing least functionality in the system; configuration management plan; system security plan; system design documentation; security configuration checklists; system configuration settings and associated documentation; specifications for preventing software program execution; documented reviews of programs, functions, ports, protocols, and/or services; change control records; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for reviewing programs, functions, ports, protocols, and services on the system; personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Organizational processes for reviewing and disabling nonessential programs, functions, ports, protocols, or services; mechanisms implementing review and handling of nonessential programs, functions, ports, protocols, or services; organizational processes preventing program execution on the system; organizational processes for software program usage and restrictions; mechanisms supporting or implementing software program usage and restrictions; mechanisms preventing program execution on the system].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 22-23.

Restricting the use of nonessential software (programs) includes restricting the roles allowed to approve program execution; prohibiting auto-execute; program blacklisting and whitelisting; or restricting the number of program instances executed at the same time. The organization makes a security-based determination which functions, ports, protocols, and/or services are restricted. Bluetooth, File Transfer Protocol (FTP), and peer-to-peer networking are examples of protocols organizations consider preventing the use of, restricting, or disabling.

Further Discussion¶

Organizations should only use the minimum set of programs, services, ports, and protocols required for to accomplish the organization’s mission. This has several implications:

• All unnecessary programs and accounts are removed from all endpoints and servers.
• The organization makes a policy decision to control the execution of programs through either whitelisting or blacklisting. Whitelisting means a program can only run if the software has been vetted in some way, and the executable name has been entered onto a list of allowed software. Blacklisting means any software can execute as long it is not on a list of known malicious software. Whitelisting provides far more security than blacklisting, but the organization’s policy can direct the implementation of either approach. Control of execution applies to both servers and endpoints.
• The organization restricts the use of all unnecessary ports, protocols, and system services in order to limit entry points that attackers can use. For example, the use of the FTP service is eliminated from all computers, and the associated ports are blocked unless a required service utilizes those ports. The elimination of nonessential functionality on the network and systems provides a smaller attack surface for an attacker to gain access and take control of your network or systems.

This requirement, CM.L2-3.4.7, which requires limiting functionality to essential programs, ports, protocols, and services, extends CM.L2-3.4.6, which requires adherence to the principle of least functionality but does not specifically address which elements of a system should be limited.

Examples¶

• You are responsible for purchasing new endpoint hardware, installing organizationally required software to the hardware, and configuring the endpoint in accordance with the organization’s policy. The organization has a system imaging capability that loads all necessary software, but it does not remove unnecessary services, eliminate the use of certain protocols, or close unused ports. After imaging the systems, you close all ports and block the use of all protocols except the following:

• TCP for SSH on port 22;

• SMTP on port 25;
• TCP and UDP on port 53; and
• HTTP and HTTPS on port 443.

The use of any other ports or protocols are allowed by exception only [i,l,o].

Potential Assessment Considerations¶

• Are only applications and services that are needed for the function of the system configured and enabled [a,b,c,d,e,f]?
• Are only those ports and protocols necessary to provide the service of the information system configured for that system [g,h,i,j,k,l]?
• Are systems services reviewed to determine what is essential for the function of that system [m]?

Key References¶

• NIST SP 800-171 Rev. 2 3.4.7

CM.L2-3.4.8 – Application Execution Policy¶

Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 30.

Determine if:

• [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified;
• [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified; and
• [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 30.

Examine: [SELECT FROM: Configuration management policy; procedures addressing least functionality in the system; system security plan; configuration management plan; system design documentation; system configuration settings and associated documentation; list of software programs not authorized to execute on the system; list of software programs authorized to execute on the system; security configuration checklists; review and update records associated with list of authorized or unauthorized software programs; change control records; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for identifying software authorized or not authorized to execute on the system; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Organizational process for identifying, reviewing, and updating programs authorized or not authorized to execute on the system; process for implementing blacklisting or whitelisting; mechanisms supporting or implementing blacklisting or whitelisting].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 23.

The process used to identify software programs that are not authorized to execute on systems is commonly referred to as blacklisting. The process used to identify software programs that are authorized to execute on systems is commonly referred to as whitelisting. Whitelisting is the stronger of the two policies for restricting software program execution. In addition to whitelisting, organizations consider verifying the integrity of whitelisted software programs using, for example, cryptographic checksums, digital signatures, or hash functions. Verification of whitelisted software can occur either prior to execution or at system startup. NIST SP 800-167 provides guidance on application whitelisting.

Further Discussion¶

Organizations should determine their blacklisting or whitelisting policy and configure the system to manage software that is allowed to run. Blacklisting or deny-by-exception allows all software to run except if on an unauthorized software list such as what is maintained in antivirus solutions. Whitelisting or permit-by-exception does not allow any software to run except if on an authorized software list. The stronger policy of the two is whitelisting. This requirement, CM.L2-3.4.8, requires the implementation of allow-lists and deny-lists for application software. It leverages CM.L2-3.4.1, which requires the organization to establish and maintain software inventories. This requirement, CM.L2-3.4.8, also extends CM.L2-3.4.9, which only requires control and monitoring of any user installed software.

Examples¶

• To improve your company’s protection from malware, you have decided to allow only designated programs to run. With additional research you identify a capability within the latest operating system that can control executables, scripts, libraries, or application installers run in your environment [c]. To ensure success you begin by authorizing digitally signed executables. Once they are deployed, you then plan to evaluate and deploy whitelisting for software libraries and scripts [c].

Potential Assessment Considerations¶

• Is the information system configured to only allow authorized software to run [a,b,c]?
• Is the system configured to disallow running unauthorized software [a,b,c]?
• Is there a defined list of software programs authorized to execute on the system [b]?
• Is the authorization policy a deny-all, permit by exception for software allowed to execute on the system [a,b,c]?
• Are automated mechanisms used to prevent program execution in accordance with defined lists (e.g., whitelisting) [a,b,c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.4.8

CM.L2-3.4.9 – User-Installed Software¶

Control and monitor user-installed software.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 30.

Determine if:

• [a] a policy for controlling the installation of software by users is established;
• [b] installation of software by users is controlled based on the established policy; and
• [c] installation of software by users is monitored.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 30.

Examine: [SELECT FROM: Configuration management policy; procedures addressing user installed software; configuration management plan; system security plan; system design documentation; system configuration settings and associated documentation; list of rules governing user-installed software; system monitoring records; system audit logs and records; continuous monitoring strategy; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for governing user-installed software; personnel operating, using, or maintaining the system; personnel monitoring compliance with user-installed software policy; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Organizational processes governing user-installed software on the system; mechanisms enforcing rules or methods for governing the installation of software by users; mechanisms monitoring policy compliance].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 23.

Users can install software in organizational systems if provided the necessary privileges. To maintain control over the software installed, organizations identify permitted and prohibited actions regarding software installation through policies. Permitted software installations include updates and security patches to existing software and applications from organization-approved “app stores.” Prohibited software installations may include software with unknown or suspect pedigrees or software that organizations consider potentially malicious. The policies organizations select governing user-installed software may be organization-developed or provided by some external entity. Policy enforcement methods include procedural methods, automated methods, or both.

Further Discussion¶

Software that users have the ability to install is limited to items that the organization approves. When not controlled, users could install software that can create unnecessary risk. This risk applies both to the individual machine and to the larger operating environment. Policies and technical controls reduce risk to the organization by preventing users from installing unauthorized software.

Examples¶

• You are a system administrator. A user calls you for help installing a software package. They are receiving a message asking for a password because they do not have permission to install the software. You explain that the policy prohibits users from installing software without approval [a]. When you set up workstations for users, you do not provide administrative privileges. After the call, you redistribute the policy to all users ensuring everyone in the company is aware of the restrictions.

Potential Assessment Considerations¶

• Are user controls in place to prohibit the installation of unauthorized software [a]?
• Is all software in use on the information systems approved [b]?
• Is there a mechanism in place to monitor the types of software a user is permitted to download (e.g., is there a whitelist of approved software) [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.4.9