Knowledge is Power

Sitewide Search

Search Bare Metal Cyber

Search courses, individual lessons, wiki entries, books, podcasts, magazine articles, Daily Cyber News, and Darwin.

NIST SP 800-171 CUI Protection Center

03.04.02 — Configuration Settings

Read the official CUI requirement and assessment content, then use the separately labeled Bare Metal Cyber perspective to connect it to implementation, evidence, and sustained operation.

1Parameters
1Source controls
4Assessment objectives
3Assessment methods

03.04 — Configuration Management · NIST SP 800-171 Revision 3

Active
Official NIST requirement content

Security requirement

  1. a.Establish, document, and implement the following configuration settings for the system that reflect the most restrictive mode consistent with operational requirements: [Organization-defined: configuration settings] .
  2. b.Identify, document, and approve any deviations from established configuration settings.
Official NIST discussion

Discussion

Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system and that affect the security posture or functionality of the system. Security-related configuration settings can be defined for systems (e.g., servers, workstations), input and output devices (e.g., scanners, copiers, 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 that impact the security state of the system, including the parameters required to satisfy other security requirements. Security parameters include registry settings; account, file, and directory permission settings (i.e., privileges); and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for the system. The established settings become part of the system’s configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, and 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.

Official organization-defined parameters

Tailoring decisions required

Resolve these values through the governing organization’s approved tailoring and risk-management process before declaring the requirement implemented.

configuration settingsorganization-defined configuration settingsconfiguration settings for the system that reflect the most restrictive mode consistent with operational requirements are defined.
Bare Metal Cyber interpretation

Implementation perspective

Treat Configuration Settings as a CUI protection outcome that must be reflected in the system boundary, documented implementation, operational behavior, and assessment evidence. Pay particular attention to approved baselines, secure configuration, change control, inventories, and drift management within the CUI boundary.

  1. Confirm the requirement is in scope for the CUI system components, services, users, and external connections being assessed.
  2. Resolve every organization-defined parameter through an approved governance and tailoring process.
  3. Map each clause of the requirement to an accountable owner, implementation mechanism, and evidence source.
  4. Verify that inherited and shared implementations are supported by current provider evidence and responsibility boundaries.
  5. Collect evidence during normal operation and review changes, exceptions, and deficiencies on a risk-based cadence.

Questions to ask

  • Which CUI assets, data flows, users, and services are protected by this requirement?
  • Which portions are implemented locally, inherited, shared, or not applicable, and what evidence supports that determination?
  • Do the system security plan, deployed configuration, operating process, and assessment evidence tell the same story?
  • What change, incident, or threshold should trigger reassessment?

Evidence and validation

  • approved baseline configurations
  • change tickets and approvals
  • configuration scan and drift reports
  • software and hardware inventories

Common failure patterns

  • baselines documented but not enforced
  • emergency changes never reconciled
  • cloud or ephemeral assets missing from inventory
  • security impact analysis performed after deployment
Official NIST SP 800-171A content

Assessment objectives and methods

Assessment objectives (4)
  1. a.

    the following configuration settings for the system that reflect the most restrictive mode consistent with operational requirements are established and documented: [Organization-defined: configuration settings].

  2. b.

    any deviations from established configuration settings are identified and documented.

  3. b.

    any deviations from established configuration settings are approved.

  4. a.

    the following configuration settings for the system are implemented: [Organization-defined: configuration settings].

Examine

  • configuration management policy and procedures
  • procedures for system configuration settings
  • configuration management plan
  • system design documentation
  • system configuration settings
  • common secure configuration checklists
  • system component inventory
  • evidence supporting approved deviations from established configuration settings
  • change control records
  • system data processing and retention permissions
  • system audit records
  • system security plan
  • other relevant documents or records

Interview

  • personnel with security configuration management responsibilities
  • personnel with information security responsibilities
  • system administrators

Test

  • processes for managing configuration settings
  • mechanisms that implement, monitor, or control system configuration settings
  • mechanisms that identify or document deviations from established configuration settings
Official source-control relationships

Source NIST SP 800-53 controls

These controls are referenced by the official SP 800-171 Rev. 3 OSCAL record. Open the corresponding control pages for complete control text, enhancements, D3FEND mappings, and related learning.

Source record

Authoritative sources