+Secure Baseline Configurations
---+Reviews & Updates
---+Automated Central Management & Verification
---+Retention Of Previous Configurations
---+Development & Test Environment Configurations
---+Configure Technology Assets, Applications and/or Services (TAAS) for High-Risk Areas
---+Network Device Configuration File Synchronization
---+Approved Configuration Deviations
---+Respond To Unauthorized Changes
---+Baseline Tailoring

Secure Baseline Configurations

Description

Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Secure Baseline Configurations (SBC)
∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs)
∙ Center for Internet Security (CIS) Benchmarks
∙ Original Equipment Manufacturer (OEM) security guides

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).

Level 2 Planned Tracked

Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).
▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.
▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.

Level 3 Well Defined

Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners.
▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.

Level 4 Quantitatively Controlled

Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

1. Overview

Summary	Standard
Reviews & Updates	Description Mechanisms exist to review and update baseline configurations: (1) At least annually; (2) When required due to so; or (3) As part of system component installations and upgrades. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Configuration Management (CM) program ∙ Change control program Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Configuration Management (CM) program ∙ Change control program Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Configuration Management (CM) program ∙ Change control program Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Configuration Management (CM) program ∙ Change control program Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Configuration Management (CM) program ∙ Change control program SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality. Level 2 Planned Tracked Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines). ▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). ▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met. Level 3 Well Defined Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners. ▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to review and update baseline configurations: (1) At least annually; (2) When required due to so; or (3) As part of system component installations and upgrades. Level 4 Quantitatively Controlled Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. ▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions.
Automated Central Management & Verification	Description Automated mechanisms exist to govern and report on baseline configurations of Technology Assets, Applications and/or Services (TAAS) through Continuous Diagnostics and Mitigation (CDM), or similar technologies. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ ManageEngine Vulnerability Manager Plus (https://manageengine.com) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ ManageEngine Vulnerability Manager Plus (https://manageengine.com) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ ManageEngine Vulnerability Manager Plus (https://manageengine.com) ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). Level 2 Planned Tracked Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines). ▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). Level 3 Well Defined Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners. ▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to automatically govern and report on baseline configurations of Technology Assets, Applications and/or Services (TAAS) through Continuous Diagnostics and Mitigation (CDM), or similar technologies. Level 4 Quantitatively Controlled Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. ▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions.
Retention Of Previous Configurations	Description Mechanisms exist to retain previous versions of baseline configuration to support roll back. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Document baseline configurations for key systems Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Configuration baseline documentation ∙ CIS Benchmark hardening guides Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Configuration management program ∙ Automated baseline assessment (e.g., CIS-CAT) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Enterprise CMDB ∙ Automated configuration compliance scanning Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise configuration management platform (e.g., Ansible, Puppet) ∙ CMDB ∙ Drift detection and remediation SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. Level 2 Planned Tracked Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines). ▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). ▪ Historical versions of configurations are maintained for troubleshooting and forensics purposes. Level 3 Well Defined Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners. ▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to retain previous versions of baseline configuration to support roll back. Level 4 Quantitatively Controlled Utilize SCR-CMM Level 3 criteria definitions: ▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. ▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define. Level 5 Continuously Improving Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
Development & Test Environment Configurations	Description Mechanisms exist to manage baseline configurations for development and test environments separately from operational baseline configurations to minimize the risk of unintentional changes. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Document baseline configurations for key systems Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Configuration baseline documentation ∙ CIS Benchmark hardening guides Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Configuration management program ∙ Automated baseline assessment (e.g., CIS-CAT) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Enterprise CMDB ∙ Automated configuration compliance scanning Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise configuration management platform (e.g., Ansible, Puppet) ∙ CMDB ∙ Drift detection and remediation SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). ▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment. ▪ IT/cybersecurity personnel use an informal process to design, build and maintain secure configurations for test, development, staging and production environments, including the implementation of appropriate cybersecurity and data protection controls. Level 2 Planned Tracked Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines). ▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). ▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks. ▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data. Level 3 Well Defined Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners. ▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to manage baseline configurations for development and test environments separately from operational baseline configurations to minimize the risk of unintentional changes. Level 4 Quantitatively Controlled Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. ▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions.
Configure Technology Assets, Applications and/or Services (TAAS) for High-Risk Areas	Description Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) utilized in high-risk areas with more restrictive baseline configurations. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality. Level 2 Planned Tracked Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines). ▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). ▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks. ▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data. Level 3 Well Defined Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners. ▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) utilized in high-risk areas with more restrictive baseline configurations. Level 4 Quantitatively Controlled Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. ▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions.
Network Device Configuration File Synchronization	Description Mechanisms exist to configure network devices to synchronize startup and running configuration files. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Document baseline configurations for key systems Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Configuration baseline documentation ∙ CIS Benchmark hardening guides Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Configuration management program ∙ Automated baseline assessment (e.g., CIS-CAT) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Enterprise CMDB ∙ Automated configuration compliance scanning Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise configuration management platform (e.g., Ansible, Puppet) ∙ CMDB ∙ Drift detection and remediation SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. Level 2 Planned Tracked Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines). ▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). Level 3 Well Defined Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners. ▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to configure network devices to synchronize startup and running configuration files. Level 4 Quantitatively Controlled Utilize SCR-CMM Level 3 criteria definitions: ▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. ▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define. Level 5 Continuously Improving Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
Approved Configuration Deviations	Description Mechanisms exist to document, assess risk and approve or deny deviations to standardized configurations. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Manual exception management process Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Manual exception management process Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Manual exception management process ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality. Level 2 Planned Tracked Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines). ▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). ▪ Any deviations from approved baseline configurations are reviewed, approved and documented on a case-by-case basis by IT and/or cybersecurity personnel. ▪ Deviations to baseline configurations are required to have a risk assessment and the business process owner's acceptance of the risk(s) associated with the deviation. Level 3 Well Defined Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners. ▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to document, assess risk and approve or deny deviations to standardized configurations. Level 4 Quantitatively Controlled Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. ▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions.
Respond To Unauthorized Changes	Description Mechanisms exist to respond to unauthorized changes to configuration settings as security incidents. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Incident Response Plan (IRP) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Incident Response Plan (IRP) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Incident Response Plan (IRP) ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Incident Response Plan (IRP) ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Incident Response Plan (IRP) ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ IT and/or cybersecurity personnel use an informal process to verify the functionality of security controls when anomalies or misconfigurations are discovered. Level 2 Planned Tracked Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines). ▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). Level 3 Well Defined Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners. ▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to respond to unauthorized changes to configuration settings as security incidents. Level 4 Quantitatively Controlled Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. ▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions.
Baseline Tailoring	Description Mechanisms exist to allow baseline controls to be specialized or customized by applying a defined set of tailoring actions that are specific to: (1) Mission / business functions; (2) Operational environment; (3) Specific threats or vulnerabilities; or (4) Other conditions or situations that could affect mission / business success. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides ∙ ManageEngine Vulnerability Manager Plus (https://manageengine.com) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides ∙ ManageEngine Vulnerability Manager Plus (https://manageengine.com) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides ∙ ManageEngine Vulnerability Manager Plus (https://manageengine.com) ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Secure Baseline Configurations (SBC) ∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs) ∙ Center for Internet Security (CIS) Benchmarks ∙ Original Equipment Manufacturer (OEM) security guides ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Netwrix Auditor (https://netrix.com) SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). ▪ Deviations from approved baseline configurations are handled on a case-by-case basis by IT/cybersecurity personnel. Acceptance of any deviations from baselines must be informed by performance of a risk assessment. ▪ As necessary, enhanced security requirements are developed for unattended systems (e.g., kiosks, ATMs, etc.) and point of sale devices. Level 2 Planned Tracked Configuration Management (CFG) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines). ▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides). ▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data. ▪ IT and/or cybersecurity personnel perform an annual review of existing configurations to ensure security objectives are still being met. Level 3 Well Defined Configuration Management (CFG) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with CFG domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with CFG domain capabilities are well-documented and kept current by process owners. ▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to allow baseline controls to be specialized or customized by applying a defined set of tailoring actions that are specific to: (1) Mission / business functions; (2) Operational environment; (3) Specific threats or vulnerabilities; or (4) Other conditions or situations that could affect mission / business success. Level 4 Quantitatively Controlled Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Configuration Management (CFG) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. ▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions.

1.1 References

1.2 Identified Requirements

1.3 Related Regulations

2. Identified Requirements

Requirements
Source	Requirement

3. Related Regulations

Regulations

DORA

DORA Ch. II Sec. II Art. 9 3.

3. In order to achieve the objectives referred to in paragraph 2, financial entities shall use ICT solutions and processes that are appropriate in accordance with Article 4. Those ICT solutions and processes shall:

(a) ensure the security of the means of transfer of data;
(b) minimise the risk of corruption or loss of data, unauthorised access and technical flaws that may hinder business activity;
(c) prevent the lack of availability, the impairment of the authenticity and integrity, the breaches of confidentiality and the loss of data;
(d) ensure that data is protected from risks arising from data management, including poor administration, processing-related risks and human error.

EULAW

Article 17 Quality management system

Article 17

Quality management system

1. Providers of high-risk AI systems shall put a quality management system in place that ensures compliance with this Regulation. That system shall be documented in a systematic and orderly manner in the form of written policies, procedures and instructions, and shall include at least the following aspects:

(a)	a strategy for regulatory compliance, including compliance with conformity assessment procedures and procedures for the management of modifications to the high-risk AI system;

(b)	techniques, procedures and systematic actions to be used for the design, design control and design verification of the high-risk AI system;

(c)	techniques, procedures and systematic actions to be used for the development, quality control and quality assurance of the high-risk AI system;

(d)	examination, test and validation procedures to be carried out before, during and after the development of the high-risk AI system, and the frequency with which they have to be carried out;

(e)	technical specifications, including standards, to be applied and, where the relevant harmonised standards are not applied in full or do not cover all of the relevant requirements set out in Section 2, the means to be used to ensure that the high-risk AI system complies with those requirements;

(f)

systems and procedures for data management, including data acquisition, data collection, data analysis, data labelling, data storage, data filtration, data mining, data aggregation, data retention and any other operation regarding the data that is performed before and for the purpose of the placing on the market or the putting into service of high-risk AI systems;

(g)	the risk management system referred to in Article 9;

(h)	the setting-up, implementation and maintenance of a post-market monitoring system, in accordance with Article 72;

(i)	procedures related to the reporting of a serious incident in accordance with Article 73;

(j)	the handling of communication with national competent authorities, other relevant authorities, including those providing or supporting the access to data, notified bodies, other operators, customers or other interested parties;

(k)	systems and procedures for record-keeping of all relevant documentation and information;

(l)	resource management, including security-of-supply related measures;

(m)	an accountability framework setting out the responsibilities of the management and other staff with regard to all the aspects listed in this paragraph.

2. The implementation of the aspects referred to in paragraph 1 shall be proportionate to the size of the provider’s organisation. Providers shall, in any event, respect the degree of rigour and the level of protection required to ensure the compliance of their high-risk AI systems with this Regulation.

3. Providers of high-risk AI systems that are subject to obligations regarding quality management systems or an equivalent function under relevant sectoral Union law may include the aspects listed in paragraph 1 as part of the quality management systems pursuant to that law.

4. For providers that are financial institutions subject to requirements regarding their internal governance, arrangements or processes under Union financial services law, the obligation to put in place a quality management system, with the exception of paragraph 1, points (g), (h) and (i) of this Article, shall be deemed to be fulfilled by complying with the rules on internal governance arrangements or processes pursuant to the relevant Union financial services law. To that end, any harmonised standards referred to in Article 40 shall be taken into account.

EULAW

Article 21 Cybersecurity risk-management measures

Article 21

Cybersecurity risk-management measures

Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services.

Taking into account the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation, the measures referred to in the first subparagraph shall ensure a level of security of network and information systems appropriate to the risks posed. When assessing the proportionality of those measures, due account shall be taken of the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents and their severity, including their societal and economic impact.

The measures referred to in paragraph 1 shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following:

(a)

policies on risk analysis and information system security;

(b)

incident handling;

(c)

business continuity, such as backup management and disaster recovery, and crisis management;

(d)

supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;

(e)

security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;

(f)

policies and procedures to assess the effectiveness of cybersecurity risk-management measures;

(g)

basic cyber hygiene practices and cybersecurity training;

(h)

policies and procedures regarding the use of cryptography and, where appropriate, encryption;

(i)

human resources security, access control policies and asset management;

(j)

the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.

Member States shall ensure that, when considering which measures referred to in paragraph 2, point (d), of this Article are appropriate, entities take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures. Member States shall also ensure that, when considering which measures referred to in that point are appropriate, entities are required to take into account the results of the coordinated security risk assessments of critical supply chains carried out in accordance with Article 22(1).

Member States shall ensure that an entity that finds that it does not comply with the measures provided for in paragraph 2 takes, without undue delay, all necessary, appropriate and proportionate corrective measures.

By 17 October 2024, the Commission shall adopt implementing acts laying down the technical and the methodological requirements of the measures referred to in paragraph 2 with regard to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers.

The Commission may adopt implementing acts laying down the technical and the methodological requirements, as well as sectoral requirements, as necessary, of the measures referred to in paragraph 2 with regard to essential and important entities other than those referred to in the first subparagraph of this paragraph.

When preparing the implementing acts referred to in the first and second subparagraphs of this paragraph, the Commission shall, to the extent possible, follow European and international standards, as well as relevant technical specifications. The Commission shall exchange advice and cooperate with the Cooperation Group and ENISA on the draft implementing acts in accordance with Article 14(4), point (e).

Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 39(2).

Linked Issues

Issuelinks
Linktype	Issue
is related to	Annual
is related to	relative Control Weighting = 10
is related to	Process
is related to	Protect
is related to	SCRM Focus Tier 1 STRATEGIC
is related to	SCRM Focus Tier 2 OPERATIONAL
is related to	SCRM Focus Tier 3 TACTICAL
blocks	Inability to maintain individual accountability
blocks	Improper assignment of privileged functions
blocks	Privilege escalation
blocks	Unauthorized access
blocks	Lost, damaged or stolen asset(s)
blocks	Loss of integrity through unauthorized changes
blocks	Emergent properties and/or unintended consequences
blocks	Business interruption
blocks	Data loss / corruption
blocks	Reduction in productivity
blocks	Information loss / corruption or system compromise due to technical attack
blocks	Information loss / corruption or system compromise due to non‐technical attack
blocks	Loss of revenue
blocks	Cancelled contract
blocks	Diminished competitive advantage
blocks	Diminished reputation
blocks	Fines and judgements
blocks	Unmitigated vulnerabilities
blocks	System compromise
blocks	Inability to support business processes
blocks	Incorrect controls scoping
blocks	Lack of roles & responsibilities
blocks	Inadequate internal practices
blocks	Inadequate third-party practices
blocks	Lack of oversight of internal controls
blocks	Lack of oversight of third-party controls
blocks	Illegal content or abusive action
blocks	Inability to investigate / prosecute incidents
blocks	Improper response to incidents
blocks	Ineffective remediation actions
blocks	Expense associated with managing a loss event
blocks	Inability to maintain situational awareness
blocks	Third-party cybersecurity exposure
blocks	Third-party physical security exposure
blocks	Third-party supply chain relationships, visibility and controls
blocks	Third-party compliance / legal exposure
blocks	Use of product / service
blocks	Reliance on the third-party
blocks	Data Obfuscation
blocks	Junk Data
blocks	Steganography
blocks	Protocol or Service Impersonation
blocks	OS Credential Dumping
blocks	LSASS Memory
blocks	Security Account Manager
blocks	NTDS
blocks	LSA Secrets
blocks	Cached Domain Credentials
blocks	DCSync
blocks	Proc Filesystem
blocks	/etc/passwd and /etc/shadow
blocks	Fallback Channels
blocks	Exfiltration Over Other Network Medium
blocks	Exfiltration Over Bluetooth
blocks	Traffic Duplication
blocks	Remote Services
blocks	Remote Desktop Protocol
blocks	SMB/Windows Admin Shares
blocks	Distributed Component Object Model
blocks	SSH
blocks	VNC
blocks	Windows Remote Management
blocks	Direct Cloud VM Connections
blocks	Obfuscated Files or Information
blocks	Command Obfuscation
blocks	Scheduled Transfer
blocks	Data Transfer Size Limits
blocks	Masquerading
blocks	Invalid Code Signature
blocks	Rename Legitimate Utilities
blocks	Match Legitimate Resource Name or Location
blocks	Double File Extension
blocks	Masquerade Account Name
blocks	Boot or Logon Initialization Scripts
blocks	Login Hook
blocks	Network Logon Script
blocks	RC Scripts
blocks	Startup Items
blocks	Network Service Discovery
blocks	Windows Management Instrumentation
blocks	Exfiltration Over Alternative Protocol
blocks	Exfiltration Over Symmetric Encrypted Non-C2 Protocol
blocks	Exfiltration Over Asymmetric Encrypted Non-C2 Protocol
blocks	Exfiltration Over Unencrypted Non-C2 Protocol
blocks	Exfiltration Over Physical Medium
blocks	Exfiltration over USB
blocks	Scheduled Task/Job
blocks	At
blocks	Cron
blocks	Scheduled Task
blocks	Systemd Timers
blocks	Process Injection
blocks	Ptrace System Calls
blocks	Web Portal Capture
blocks	Command and Scripting Interpreter
blocks	PowerShell
blocks	AppleScript
blocks	Windows Command Shell
blocks	Unix Shell
blocks	Visual Basic
blocks	Python
blocks	JavaScript
blocks	Network Device CLI
blocks	AutoHotKey & AutoIT
blocks	Lua
blocks	Exploitation for Privilege Escalation
blocks	Indicator Removal
blocks	Clear Command History
blocks	Clear Network Connection History and Configurations
blocks	Clear Mailbox Data
blocks	Clear Persistence
blocks	Application Layer Protocol
blocks	Web Protocols
blocks	File Transfer Protocols
blocks	Mail Protocols
blocks	DNS
blocks	Software Deployment Tools
blocks	Valid Accounts
blocks	Domain Accounts
blocks	Local Accounts
blocks	Cloud Accounts
blocks	Taint Shared Content
blocks	Account Discovery
blocks	Local Account
blocks	Domain Account
blocks	Proxy
blocks	Internal Proxy
blocks	External Proxy
blocks	Multi-hop Proxy
blocks	Replication Through Removable Media
blocks	Communication Through Removable Media
blocks	Non-Application Layer Protocol
blocks	Account Manipulation
blocks	Additional Cloud Credentials
blocks	Additional Email Delegate Permissions
blocks	Additional Cloud Roles
blocks	SSH Authorized Keys
blocks	Device Registration
blocks	Additional Local or Domain Groups
blocks	Web Service
blocks	Dead Drop Resolver
blocks	Bidirectional Communication
blocks	One-Way Communication
blocks	Multi-Stage Channels
blocks	Ingress Tool Transfer
blocks	Native API
blocks	Brute Force
blocks	Password Guessing
blocks	Password Cracking
blocks	Password Spraying
blocks	Credential Stuffing
blocks	Multi-Factor Authentication Interception
blocks	Email Collection
blocks	Remote Email Collection
blocks	Email Forwarding Rule
blocks	Automated Collection
blocks	Trusted Developer Utilities Proxy Execution
blocks	MSBuild
blocks	ClickOnce
blocks	Shared Modules
blocks	Data Encoding
blocks	Standard Encoding
blocks	Non-Standard Encoding
blocks	External Remote Services
blocks	Access Token Manipulation
blocks	Token Impersonation/Theft
blocks	Create Process with Token
blocks	Make and Impersonate Token
blocks	SID-History Injection
blocks	Network Share Discovery
blocks	Create Account
blocks	Local Account
blocks	Domain Account
blocks	Cloud Account
blocks	Office Application Startup
blocks	Office Template Macros
blocks	Office Test
blocks	Outlook Forms
blocks	Outlook Home Page
blocks	Outlook Rules
blocks	Add-ins
blocks	Software Extensions
blocks	Browser Session Hijacking
blocks	Forced Authentication
blocks	Drive-by Compromise
blocks	Exploit Public-Facing Application
blocks	Supply Chain Compromise
blocks	Compromise Software Dependencies and Development Tools
blocks	Compromise Hardware Supply Chain
blocks	BITS Jobs
blocks	Trusted Relationship
blocks	Password Policy Discovery
blocks	User Execution
blocks	Malicious Link
blocks	Malicious File
blocks	Malicious Image
blocks	Traffic Signaling
blocks	Port Knocking
blocks	Exploitation of Remote Services
blocks	Exploitation for Stealth
blocks	Exploitation for Credential Access
blocks	Data from Information Repositories
blocks	Confluence
blocks	Sharepoint
blocks	Customer Relationship Management Software
blocks	Messaging Applications
blocks	System Script Proxy Execution
blocks	PubPrn
blocks	SyncAppvPublishingServer
blocks	System Binary Proxy Execution
blocks	Compiled HTML File
blocks	Control Panel
blocks	CMSTP
blocks	InstallUtil
blocks	Mshta
blocks	Msiexec
blocks	Odbcconf
blocks	Regsvcs/Regasm
blocks	Verclsid
blocks	Mavinject
blocks	MMC
blocks	Electron Applications
blocks	Remote Access Tools
blocks	XSL Script Processing
blocks	Template Injection
blocks	File and Directory Permissions Modification
blocks	Windows Permissions
blocks	Linux and Mac Permissions
blocks	Domain Trust Discovery
blocks	Domain or Tenant Policy Modification
blocks	Data Destruction
blocks	Data Encrypted for Impact
blocks	Service Stop
blocks	Inhibit System Recovery
blocks	Defacement
blocks	Internal Defacement
blocks	External Defacement
blocks	Firmware Corruption
blocks	Network Denial of Service
blocks	Direct Network Flood
blocks	Reflection Amplification
blocks	Endpoint Denial of Service
blocks	OS Exhaustion Flood
blocks	Service Exhaustion Flood
blocks	Application Exhaustion Flood
blocks	Application or System Exploitation
blocks	Server Software Component
blocks	SQL Stored Procedures
blocks	Transport Agent
blocks	Web Shell
blocks	IIS Components
blocks	Terminal Services DLL
blocks	Implant Internal Image
blocks	Steal Application Access Token
blocks	Data from Cloud Storage
blocks	Transfer Data to Cloud Account
blocks	Steal Web Session Cookie
blocks	Pre-OS Boot
blocks	System Firmware
blocks	Bootkit
blocks	ROMMONkit
blocks	TFTP Boot
blocks	Create or Modify System Process
blocks	Launch Agent
blocks	Systemd Service
blocks	Windows Service
blocks	Launch Daemon
blocks	Event Triggered Execution
blocks	Screensaver
blocks	Windows Management Instrumentation Event Subscription
blocks	Unix Shell Configuration Modification
blocks	LC_LOAD_DYLIB Addition
blocks	Accessibility Features
blocks	AppInit DLLs
blocks	PowerShell Profile
blocks	Emond
blocks	Installer Packages
blocks	Authentication Package
blocks	Time Providers
blocks	Security Support Provider
blocks	Kernel Modules and Extensions
blocks	Re-opened Applications
blocks	LSASS Driver
blocks	Shortcut Modification
blocks	XDG Autostart Entries
blocks	Abuse Elevation Control Mechanism
blocks	Setuid and Setgid
blocks	Bypass User Account Control
blocks	Sudo and Sudo Caching
blocks	Elevated Execution with Prompt
blocks	TCC Manipulation
blocks	Use Alternate Authentication Material
blocks	Application Access Token
blocks	Pass the Hash
blocks	Pass the Ticket
blocks	Unsecured Credentials
blocks	Credentials In Files
blocks	Credentials in Registry
blocks	Shell History
blocks	Private Keys
blocks	Cloud Instance Metadata API
blocks	Group Policy Preferences
blocks	Container API
blocks	Subvert Trust Controls
blocks	Gatekeeper Bypass
blocks	SIP and Trust Provider Hijacking
blocks	Install Root Certificate
blocks	Mark-of-the-Web Bypass
blocks	Code Signing Policy Modification
blocks	Compromise Host Software Binary
blocks	Windows Credential Manager
blocks	Password Managers
blocks	Modify Authentication Process
blocks	Domain Controller Authentication
blocks	Password Filter DLL
blocks	Pluggable Authentication Modules
blocks	Network Device Authentication
blocks	Network Provider DLL
blocks	Conditional Access Policies
blocks	Adversary-in-the-Middle
blocks	Name Resolution Poisoning and SMB Relay
blocks	ARP Cache Poisoning
blocks	DHCP Spoofing
blocks	Evil Twin
blocks	Steal or Forge Kerberos Tickets
blocks	Golden Ticket
blocks	Silver Ticket
blocks	Kerberoasting
blocks	AS-REP Roasting
blocks	Inter-Process Communication
blocks	Component Object Model
blocks	Dynamic Data Exchange
blocks	XPC Services
blocks	Archive Collected Data
blocks	Archive via Utility
blocks	Disk Wipe
blocks	Disk Content Wipe
blocks	Disk Structure Wipe
blocks	Remote Service Session Hijacking
blocks	SSH Hijacking
blocks	RDP Hijacking
blocks	Hidden Users
blocks	Run Virtual Instance
blocks	VBA Stomping
blocks	Resource Forking
blocks	Data Manipulation
blocks	Stored Data Manipulation
blocks	Transmitted Data Manipulation
blocks	Runtime Data Manipulation
blocks	Phishing
blocks	Spearphishing Attachment
blocks	Spearphishing Link
blocks	System Services
blocks	Service Execution
blocks	Lateral Tool Transfer
blocks	Non-Standard Port
blocks	Protocol Tunneling
blocks	Encrypted Channel
blocks	Symmetric Cryptography
blocks	Asymmetric Cryptography
blocks	Hijack Execution Flow
blocks	DLL
blocks	Dylib Hijacking
blocks	Executable Installer File Permissions Weakness
blocks	Dynamic Linker Hijacking
blocks	Path Interception by PATH Environment Variable
blocks	Path Interception by Search Order Hijacking
blocks	Path Interception by Unquoted Path
blocks	Services File Permissions Weakness
blocks	KernelCallbackTable
blocks	AppDomainManager
blocks	Modify Cloud Compute Infrastructure
blocks	Create Snapshot
blocks	Create Cloud Instance
blocks	Delete Cloud Instance
blocks	DNS
blocks	Phishing for Information
blocks	Spearphishing Attachment
blocks	Spearphishing Link
blocks	Network Boundary Bridging
blocks	Network Address Translation Traversal
blocks	Modify System Image
blocks	Patch System Image
blocks	Downgrade System Image
blocks	Data from Configuration Repository
blocks	SNMP (MIB Dump)
blocks	Network Device Configuration Dump
blocks	Container Administration Command
blocks	Deploy Container
blocks	Escape to Host
blocks	Build Image on Host
blocks	Container and Resource Discovery
blocks	Debugger Evasion
blocks	Plist File Modification
blocks	Serverless Execution
blocks	Power Settings

Secure Controls Framework -
The Secure Controls Framework® (SCF)

"The SCF is the Common Controls Framework™ (CCF), the world's most comprehensive cybersecurity and data privacy metaframework - it is also free to use. The entire concept is building secure, compliant and resilient capabilities in the most efficient and cost-effective manner possible.

The SCF is more than just a unified control catalog, since its included content creates a playbook for Governance, Risk & Compliance (GRC) capabilities. Used globally by organizations of every size, the SCF is a robust and scalable solution for security, compliance and resilience controls. As a comprehensive security framework, the SCF maps 1,400+ controls across 200+ laws, regulations, and industry frameworks so you can implement once and comply everywhere.

Like it or not, cybersecurity is a protracted war on an asymmetric battlefield, where the threats are everywhere and as defenders we have to make the effort to work together to help improve cybersecurity and data privacy practices, since we all suffer when massive data breaches occur or when cyber attacks have physical impacts. Hackers share information on attack methods with other hackers, so why shouldn’t the good guys share information on how to best protect an organization? We decided to take action and make a difference, since we feel it is too important to wait for someone else to fix the problems that exist.

The SCF is made up of volunteers, mainly specialists within the cybersecurity profession, who focus on GRC and the cybersecurity side of data privacy. These are auditors, engineers, architects, incident responders, consultants and other specialists who live and breathe these topics on a daily basis. The end product is "expert-derived content" that makes up the SCF." https://securecontrolsframework.com/

Terms & Conditions

The SCF End User License Agreement (EULA) governs the use of the Secure Controls Framework® (SCF) under the Creative Commons Attribution-No Derivatives 4.0 International Public License.