# CM-06 Configuration Settings

NIST SP 800-53 control. Family: CM Configuration Management. Function: preventative. Baselines: low, moderate, high. Mapping licence: CC BY-SA 4.0.

Statement: a. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [Assignment: organization-defined common secure configurations]; b. Implement the configuration settings; c. Identify, document, and approve any deviations from established configuration settings for [Assignment: organization-defined system components] based on [Assignment: organization-defined operational requirements]; and d. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures.
Guidance: Configuration settings are the parameters that can be changed in the hardware, software, or firmware components of the system that affect the security and privacy posture or functionality of the system. Information technology products for which configuration settings can be defined include mainframe computers, servers, workstations, operating systems, mobile devices, input/output devices, protocols, and applications. Parameters that impact the security posture of systems include registry settings; account, file, or directory permission settings; and settings for functions, protocols, ports, services, and remote connections. Privacy parameters are parameters impacting the privacy posture of systems, including the parameters required to satisfy other privacy controls. Privacy parameters include settings for access controls, data processing preferences, and processing and retention permissions. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the configuration baseline for the system. Common secure configurations (also known as security configuration checklists, lockdown and hardening guides, and security reference guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for information technology products and platforms as well as instructions for configuring those products or platforms to meet operational requirements. Common secure configurations can be developed by a variety of organizations, including information technology product developers, manufacturers, vendors, federal agencies, consortia, academia, industry, and other organizations in the public and private sectors. Implementation of a common secure configuration may be mandated at the organization level, mission and business process level, system level, or at a higher level, including by a regulatory agency. Common secure configurations include the United States Government Configuration Baseline [USGCB] and security technical implementation guides (STIGs), which affect the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol provide an effective method to uniquely identify, track, and control configuration settings.

## Enhancements (2)
- CM-06(01) Automated Management, Application, and Verification. Baselines: high
- CM-06(02) Respond to Unauthorized Changes. Baselines: high
Withdrawn by NIST: CM-06(03) (now in SI-07); CM-06(04) (now in CM-04).
Each enhancement's statement: /api/v1/controls/CM-06?fields=enhancements

## Patterns that use it (15)
- Critical (1): SP-015 Secure Remote Working
- Important (9): SP-001 Client Module; SP-002 Server Module; SP-017 Secure Network Zone Module; SP-025 Advanced Monitoring and Detection; SP-028 Secure DevOps Pipeline Pattern; SP-029 Zero Trust Architecture; SP-033 Passkey Authentication; SP-035 Offensive Security Testing; SP-038 Vulnerability Management and Patching
- Standard (5): SP-012 Secure Software Development Lifecycle; SP-032 Modern Authentication; SP-039 Client-Side Encryption and Data Privacy; SP-050 Mobile Security Architecture (draft); SP-052 Decentralised Identity & Verifiable Credentials (draft)

## Clauses by framework (78 frameworks)
- iso_27001_2022: A.8.9
- iso_27002_2022: 5.37, 8.9
- cobit_2019: BAI10
- pci_dss_v4: 1.2, 1.2.1, 1.2.8, 2.1, 2.2, 2.2.1, 2.2.2
- nist_csf_2: DE.CM-09, PR.PS-01
- cis_controls_v8: CIS 4, CIS 4.1, CIS 4.2, CIS 4.6, CIS 4.7, CIS 10.5, CIS 12, CIS 12.1, CIS 12.3, CIS 16.7
- soc2_tsc: CC6.1-POF7, CC6.7-POF1, CC7.1, CC7.1-POF1, CC8.1
- finos_ccc: CCC-C14
- iso_42001_2023: A.4.2, A.6.2.3
- iec_62443: 3-3 SR 7.6
- asd_e8: E8-3, E8-3 ML1, E8-3 ML3, E8-4, E8-4 ML1, E8-4 ML2, E8-4 ML3
- nis2: Art. 21(2)(g)
- mas_trm: 11
- bsi_grundschutz: APP.1.1, NET.1.2, NET.3.1, SYS.1.1, SYS.2.1
- anssi: Hygiene.18, Hygiene.20, SecNumCloud.13.1
- osfi_b13: B-13.2.2, B-13.3.2
- finma_circular: IV.A(28), IV.A(29), IV.C(64)
- gdpr: Art.25(1), Art.25(2), Art.32(1)(b)
- dora: Art.7(1), Art.9(1)
- bio2: 5.37, 8.9
- rbi_csf: Annex1.5
- fisc: FISC.O3, FISC.T7, FISC.T14
- lgpd_bcb: LGPD.Art.46
- hkma_tme1: TME1.4.1
- mlps_2: 8.1.5.3, 8.1.10.4, 8.1.10.6
- dnb_good_practice: DNB.3.2, DNB.13.1, DNB.19.2, DNB.20.1
- cra: CRA.I.2b, CRA.Info.8a
- swift_cscf: SWIFT.1.3, SWIFT.2.3, SWIFT.2.10
- cbb_tm: TM-5
- cbuae: CR-7
- nca_ecc: 2-3, 2-10, 5-1
- qatar_nia: OS
- sama_csf: 3.3, 3.5, 3.8, 4.3
- uae_ia: T7
- bog_cisd: CISD-VI
- bom_ctrm: 3.1, 3.2
- cbe_csf: CTO-6, CTO-7, CTO-12
- cbn_csf: Part3.3
- popia: s19
- sa_js2: JS2-7.2, JS2-8.4
- bot_cyber: Ch2.1
- cpmi_pfmi: CG.PR, PFMI.P17, PFMI.P22
- eba_ict: 3.4.4, 3.5(a)
- ecb_croe: CROE.2.3.4
- ffiec_is: II.A.2, II.C.10, II.C.15(a), II.C.18
- hipaa_sr: §164.316(b)(2)(ii)
- iosco_cyber: PROT-6
- nydfs_500: 500.5
- sebi_cscrf: PR.ES, PR.IP
- cmmc_2: CM
- nerc_cip: CIP-010-4
- nrc_73_54: RG5.71-B-CM
- ieee_1686: 5.4
- doe_c2m2: ASSET
- api_1164: Sec 7
- iaea_nss: Sec 5.4
- fips_140: FIPS 140-3 §7.2, FIPS 140-3 §7.6
- pci_hsm: 8
- common_criteria: CC Part 2 — FMT
- isae_3402: Clause 4
- fca_sysc_13: SYSC 13.6.5, SYSC 13.7.1
- fda_21_cfr_11: §11.10(f)
- fda_cyber: PU-2, SPDF-3
- hitrust_csf: 09.a
- iso_27799: 12.1, 18.4
- lloyds_ms: MS8.4
- naic_ds: 4-config, 4B
- nhs_dspt: NDG-9.9
- pra_ss1_23: P3.3, P-IT.3
- solvency_ii: DR.266, EIOPA-ICT-4.8
- owasp_masvs_v2: MASVS-CODE-1, MASVS-CRYPTO-1, MASVS-CRYPTO-2
- csa_ccm_v4: CCC-06, IVS-04, UEM-05, UEM-07
- csa_aicm: CCC-06, I&S-04, UEM-05, UEM-07
- ccss_v9: 1.02.6
- mica: Art.62(1), Art.62(5)
- basel_sco60: SCO60.51, SCO60.64, SCO60.65
- bssc: GSP-14, NOS-03, TIS-03
- sec_custody_digital: SEC-CD-03, SEC-CD-06, SEC-CD-07, SEC-CD-08
OSA's mapping for iso_27001_2022 and nist_csf_2 takes NIST's published crosswalk as its base. A clause not marked as OSA's own is in that crosswalk.

## More
- This control as JSON, with guidance and ATT&CK techniques: /api/v1/controls/CM-06
- Clauses only: /api/v1/controls/CM-06?fields=mappings
- Page for people: /controls/cm-06/
- Found an error? Open an issue at https://github.com/opensecurityarchitecture/osa-data/issues with the id, what OSA says and what the source says.