CM-7 CM · Configuration Management

Least Functionality

✓ LOW ✓ MODERATE ✓ HIGH
9 Enhancements 1 Overlay 17 Related Controls
Graph
Export ▾

Requirements NIST SOURCE

Discussion (NIST Supplemental Guidance)

Systems 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. Additionally, it is sometimes convenient to provide multiple services from a single system component, but doing so increases risk over limiting the services provided by that single component. Where feasible, organizations limit component functionality to a single function per component. Organizations consider removing unused or unnecessary software and disabling unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of components, transfer of information, and tunneling. Organizations employ network scanning tools, intrusion detection and prevention systems, and end-point protection technologies, such as firewalls and host-based intrusion detection systems, to identify and prevent the use of prohibited functions, protocols, ports, and services. Least functionality can also be achieved as part of the fundamental design and development of the system (see SA-8, SC-2 , and SC-3).

Enhancements NIST SOURCE

CM-7(1) Periodic Review LOW ✓ MODERATE ✓ HIGH
  1. (a) Review the system [frequency] to identify unnecessary and/or nonsecure functions, ports, protocols, software, and services; and
  2. (b) Disable or remove [organization-defined functions, ports, protocols, software, and services within the system deemed to be unnecessary and/or nonsecure].
Discussion

Organizations review functions, ports, protocols, and services provided by systems or system components to determine the functions and services that are candidates for elimination. Such reviews are especially important during transition periods from older technologies to newer technologies (e.g., transition from IPv4 to IPv6). These technology transitions may require implementing the older and newer technologies simultaneously during the transition period and returning to minimum essential functions, ports, protocols, and services at the earliest opportunity. Organizations can either decide the relative security of the function, port, protocol, and/or service or base the security decision on the assessment of other entities. Unsecure protocols include Bluetooth, FTP, and peer-to-peer networking.

Open full page for CM-7(1) →
CM-7(2) Prevent Program Execution LOW ✓ MODERATE ✓ HIGH

Prevent program execution in accordance with [one of: ; rules authorizing the terms and conditions of software program usage].

Discussion

Prevention of program execution addresses organizational policies, rules of behavior, and/or access agreements that restrict software usage and the terms and conditions imposed by the developer or manufacturer, including software licensing and copyrights. Restrictions include prohibiting auto-execute features, restricting roles allowed to approve program execution, permitting or prohibiting specific software programs, or restricting the number of program instances executed at the same time.

Open full page for CM-7(2) →
CM-7(3) Registration Compliance LOW MODERATE HIGH

Ensure compliance with [registration requirements].

Discussion

Organizations use the registration process to manage, track, and provide oversight for systems and implemented functions, ports, protocols, and services.

Open full page for CM-7(3) →
CM-7(4) Unauthorized Software — Deny-by-exception LOW MODERATE HIGH
  1. (a) Identify [software programs];
  2. (b) Employ an allow-all, deny-by-exception policy to prohibit the execution of unauthorized software programs on the system; and
  3. (c) Review and update the list of unauthorized software programs [frequency].
Discussion

Unauthorized software programs can be limited to specific versions or from a specific source. The concept of prohibiting the execution of unauthorized software may also be applied to user actions, system ports and protocols, IP addresses/ranges, websites, and MAC addresses.

Open full page for CM-7(4) →
CM-7(5) Authorized Software — Allow-by-exception LOW ✓ MODERATE ✓ HIGH
  1. (a) Identify [software programs];
  2. (b) Employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the system; and
  3. (c) Review and update the list of authorized software programs [frequency].
Discussion

Authorized software programs can be limited to specific versions or from a specific source. To facilitate a comprehensive authorized software process and increase the strength of protection for attacks that bypass application level authorized software, software programs may be decomposed into and monitored at different levels of detail. These levels include applications, application programming interfaces, application modules, scripts, system processes, system services, kernel functions, registries, drivers, and dynamic link libraries. The concept of permitting the execution of authorized software may also be applied to user actions, system ports and protocols, IP addresses/ranges, websites, and MAC addresses. Organizations consider verifying the integrity of authorized software programs using digital signatures, cryptographic checksums, or hash functions. Verification of authorized software can occur either prior to execution or at system startup. The identification of authorized URLs for websites is addressed in CA-3(5) and SC-7.

Open full page for CM-7(5) →
CM-7(6) Confined Environments with Limited Privileges LOW MODERATE HIGH

Require that the following user-installed software execute in a confined physical or virtual machine environment with limited privileges: [user-installed software].

Discussion

Organizations identify software that may be of concern regarding its origin or potential for containing malicious code. For this type of software, user installations occur in confined environments of operation to limit or contain damage from malicious code that may be executed.

Open full page for CM-7(6) →
CM-7(7) Code Execution in Protected Environments LOW MODERATE HIGH

Allow execution of binary or machine-executable code only in confined physical or virtual machine environments and with the explicit approval of [personnel or roles] when such code is:

  1. (a) Obtained from sources with limited or no warranty; and/or
  2. (b) Without the provision of source code.
Discussion

Code execution in protected environments applies to all sources of binary or machine-executable code, including commercial software and firmware and open-source software.

Open full page for CM-7(7) →
CM-7(8) Binary or Machine Executable Code LOW MODERATE HIGH
  1. (a) Prohibit the use of binary or machine-executable code from sources with limited or no warranty or without the provision of source code; and
  2. (b) Allow exceptions only for compelling mission or operational requirements and with the approval of the authorizing official.
Discussion

Binary or machine executable code applies to all sources of binary or machine-executable code, including commercial software and firmware and open-source software. Organizations assess software products without accompanying source code or from sources with limited or no warranty for potential security impacts. The assessments address the fact that software products without the provision of source code may be difficult to review, repair, or extend. In addition, there may be no owners to make such repairs on behalf of organizations. If open-source software is used, the assessments address the fact that there is no warranty, the open-source software could contain back doors or malware, and there may be no support available.

Open full page for CM-7(8) →
CM-7(9) Prohibiting The Use of Unauthorized Hardware LOW MODERATE HIGH
  1. (a) Identify [hardware components];
  2. (b) Prohibit the use or connection of unauthorized hardware components;
  3. (c) Review and update the list of authorized hardware components [frequency].
Discussion

Hardware components provide the foundation for organizational systems and the platform for the execution of authorized software programs. Managing the inventory of hardware components and controlling which hardware components are permitted to be installed or connected to organizational systems is essential in order to provide adequate security.

Open full page for CM-7(9) →

Implementation Guidance

Engineering Interpretation

Original engineering commentary written for this explorer — not NIST source text and not authoritative guidance.

No engineering interpretation has been authored for CM-7 yet. This section is architected to receive it — see the Requirements and Assessment sections above for the authoritative NIST source content in the meantime.

Assessment

NIST SP 800-53A REV 5.2.0

Assessment Objectives

  1. mission-essential capabilities for the system are defined;
  2. functions to be prohibited or restricted are defined;
  3. ports to be prohibited or restricted are defined;
  4. protocols to be prohibited or restricted are defined;
  5. software to be prohibited or restricted is defined;
  6. services to be prohibited or restricted are defined;
  7. the system is configured to provide only <CM-07_ODP[01] mission-essential capabilities>;
  8. the use of <CM-07_ODP[02] functions> is prohibited or restricted;
  9. the use of <CM-07_ODP[03] ports> is prohibited or restricted;
  10. the use of <CM-07_ODP[04] protocols> is prohibited or restricted;
  11. the use of <CM-07_ODP[05] software> is prohibited or restricted;
  12. the use of <CM-07_ODP[06] services> is prohibited or restricted.

Examine

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

Interview

[SELECT FROM: Organizational personnel with security configuration management responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers].

Test

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

Overlays

OT/ICS Overlay SP 800-82r3

NIST SP 800-82r3 Appendix F, Table 22. Blank baseline means the control/control enhancement is not selected in that initial OT baseline.

LOW

  • Base control: Included (matches standard baseline)

MODERATE

  • Base control: Included (matches standard baseline)
  • Included: (1) (2) (5)

HIGH

  • Base control: Included (matches standard baseline)
  • Included: (1) (2) (5)

STIGs & CCIs

No STIG checks or CCI mappings are currently loaded for CM-7. This section is architected to display, per product: STIG ID, Finding ID, Severity, Title, Description, Check, Fix, CCI, and NIST control mapping — but nothing is populated here until a real DISA STIG/CCI dataset is ingested.

Learn more about STIG/CCI integration →

Evidence

Potential Evidence — Derived

Categorized from the SP 800-53A "Examine"/"Test" artifact list above by keyword — not an authoritative NIST evidence list.

Policy

  • system security plan

Configuration

  • Configuration management policy
  • configuration management plan
  • system design documentation
  • system configuration settings and associated documentation
  • system component inventory
  • common secure configuration checklists

Testing

  • Organizational processes prohibiting or restricting functions, ports, protocols, software, and/or services
  • mechanisms implementing restrictions or prohibition of functions, ports, protocols, software, and/or services

Other Records

  • procedures addressing least functionality in the system
  • other relevant documents or records