+Crypto-Agility Architecture
---+Entropy Source & Random Bit Generation
---+Stateful Hash-Based Signatures for Firmware & Code Signing
---+Approved Post-Quantum Cryptography (PQC) Algorithm Use
---+Post-Quantum Cryptography (PQC) Validation Requirements
---+Deprecated Cryptographic Algorithms
---+Post-Quantum Cryptography (PQC) Key Management
---+Quantum-Safe Public Key Infrastructure (PKI) Transition
---+Algorithm Negotiation Integrity
---+Hybrid / Composite Cryptography
---+Cryptographic Application Programming Interface (API) Abstraction
|
Crypto-Agility Architecture
Description
Mechanisms exist to validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Prefer cloud services and software that support algorithm updates without redesign
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Use cloud-native cryptographic services with configurable algorithm support
∙ Avoid hardcoded cryptographic algorithm dependencies
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Design systems for cryptographic algorithm replaceability
∙ Crypto-agility requirements in architecture reviews
∙ Abstraction of cryptographic operations from application logic
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Crypto-agility architecture validation in design reviews
∙ Cryptographic abstraction layer requirements
∙ Support for PQC key and signature sizes in protocols and libraries
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise crypto-agility architecture program
∙ Formal agility validation across protocols, libraries and hardware
∙ Cryptographic abstraction APIs enforced organization-wide
∙ Automated architecture compliance checking
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
SCR-CMM Level 2 criteria definitions are not available for this control:
▪ A reasonable person would conclude a well-defined and standardized process is required.
▪ At this level of maturity, the “requirements-driven” nature of performing the control is focused on a localized and/or regionalized implementation, not uniform and consistent across the organization.
▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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 validate design-level cryptographic agility across protocols, libraries, kernels and hardware to ensure Technology Assets, Applications and/or Services (TAAS) can support larger Post-Quantum Cryptography (PQC) key, signature and ciphertext sizes.
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.
1. Übersicht
| Bezeichnung |
Standard |
|
Entropy Source & Random Bit Generation
|
Description
Mechanisms exist to use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):
(1) Key generation;
(2) Nonce generation;
(3) Probabilistic algorithm inputs; and
(4) Key validation.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Use OS and cloud provider cryptographically secure random number generators
∙ Avoid custom entropy implementations
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Cryptographically secure PRNG from OS or validated cryptographic libraries
∙ NIST SP 800-90B guidance (https://csrc.nist.gov)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ FIPS 140-3 validated entropy sources
∙ Hardware Security Module (HSM) with validated RNG
∙ NIST SP 800-90B compliance
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ FIPS 140-3 validated HSMs for key generation
∙ Validated entropy sources aligned to NIST SP 800-90B
∙ Enterprise key management platform
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise HSM infrastructure with FIPS 140-3 validated entropy
∙ Quantum random number generators (QRNG) for enhanced entropy
∙ Centralized key management platform
∙ Continuous entropy source validation
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
Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
Level 2 Planned Tracked
Quantum Security (QTS) 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 QTS domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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 use validated entropy sources and random bit generators that comply with NIST SP 800-90B to support Post-Quantum Cryptography (PQC):
(1) Key generation;
(2) Nonce generation;
(3) Probabilistic algorithm inputs; and
(4) Key validation.
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.
|
|
Stateful Hash-Based Signatures for Firmware & Code Signing
|
Description
Mechanisms exist to enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:
(1) Firmware signing;
(2) Secure boot signing; and
(3) Other long-lifetime code-signing use cases.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Use vendor-managed firmware signing
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Use vendor-managed firmware signing
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Review code signing infrastructure for quantum vulnerability
∙ Plan migration to hash-based signatures for critical firmware
∙ NIST SP 800-208 guidance (https://csrc.nist.gov)
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Hash-based signature scheme deployment for firmware signing
∙ NIST SP 800-208 compliance for firmware and code signing
∙ State-management controls to prevent key reuse
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise hash-based signature infrastructure for firmware and code signing
∙ NIST SP 800-208 compliant implementation
∙ Automated state management to prevent one-time key reuse
∙ HSM-backed hash-based key management
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
Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
Level 2 Planned Tracked
Quantum Security (QTS) 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 QTS domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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 enforce stateful hash-based signature schemes in accordance with NIST SP 800-208 and require state-management controls necessary to prevent one-time key reuse for:
(1) Firmware signing;
(2) Secure boot signing; and
(3) Other long-lifetime code-signing use cases.
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 Post-Quantum Cryptography (PQC) Algorithm Use
|
Description
Mechanisms exist to define:
(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and
(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Monitor NIST PQC algorithm approvals (https://csrc.nist.gov/pqc)
∙ Adopt approved PQC algorithms as available in consumed services
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Reference NIST PQC approved algorithms in cryptography policy
∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Define approved PQC algorithm list
∙ NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) adoption
∙ FIPS 140-3 validated module requirements
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Formal approved PQC algorithm standard
∙ NIST FIPS 203/204/205 compliant implementations
∙ Required validation levels in cryptography policy
∙ Algorithm approval workflow for exceptions
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise approved PQC algorithm governance
∙ NIST FIPS 203/204/205 and CNSA 2.0 alignment
∙ Automated algorithm compliance enforcement
∙ Integration with cryptographic exception register
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
Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
Level 2 Planned Tracked
Quantum Security (QTS) 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 QTS domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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 define:
(1) Approved Post-Quantum Cryptography (PQC) algorithms, including asymmetric and symmetric algorithms; and
(2) Required validation levels for approved algorithms (e.g., FIPS 140-3 validated).
Level 4 Quantitatively Controlled
Quantum Security (QTS) 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
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.
|
|
Post-Quantum Cryptography (PQC) Validation Requirements
|
Description
Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to use FIPS 140-3 validated cryptographic modules, where applicable.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Use cloud provider services with FIPS 140-3 validated cryptographic modules
∙ Prefer managed services over self-hosted cryptography
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Use FIPS 140-3 validated cryptographic libraries and services
∙ NIST CMVP validation list (https://csrc.nist.gov/projects/cryptographic-module-validation-program)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ FIPS 140-3 validated module requirements for cryptographic operations
∙ Track NIST CMVP PQC validation certificates
∙ Policy mandate for validated modules where applicable
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Enterprise policy requiring FIPS 140-3 validated modules
∙ Validation tracking in cryptographic asset inventory
∙ HSM with FIPS 140-3 validation for key management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise FIPS 140-3 validation requirement enforcement
∙ Automated validation status tracking in cryptographic inventory
∙ HSM infrastructure with FIPS 140-3 Level 3 validation
∙ Continuous compliance monitoring for cryptographic module validation
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
Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
Level 2 Planned Tracked
Quantum Security (QTS) 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 QTS domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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) to use FIPS 140-3 validated cryptographic modules, where applicable.
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.
|
|
Deprecated Cryptographic Algorithms
|
Description
Mechanisms exist to identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Disable RC4, DES, 3DES and MD5 in systems and services
∙ Enforce TLS 1.2 minimum (disable TLS 1.0/1.1)
∙ Reference NIST SP 800-131A for deprecated algorithm guidance
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Deprecated algorithm disablement per NIST SP 800-131A
∙ TLS 1.2 minimum enforcement
∙ Retire RSA-1024 and similar weak key sizes
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Deprecated algorithm disablement across all systems
∙ NIST SP 800-131A and SP 800-57 compliance
∙ Vulnerability scanning for deprecated algorithm detection
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Formal deprecated algorithm disablement program
∙ Automated scanning for deprecated cryptographic use
∙ NIST SP 800-131A compliance tracking
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise deprecated algorithm removal program
∙ Automated detection and alerting for deprecated algorithm use
∙ NIST SP 800-131A and CNSA 2.0 compliance enforcement
∙ Continuous monitoring for deprecated algorithm introduction
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
Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
Level 2 Planned Tracked
Quantum Security (QTS) 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 QTS domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with QTS domain capabilities are documented and maintained by process owners.
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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 identify and disallow quantum-vulnerable and otherwise deprecated cryptographic algorithms.
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.
|
|
Post-Quantum Cryptography (PQC) Key Management
|
Description
Mechanisms exist to manage cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:
(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;
(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and
(3) Ensuring key generation uses quantum-safe entropy sources.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Shorten TLS certificate validity periods (e.g., 90-day certificates)
∙ Let's Encrypt for automated short-lived certificate management (https://letsencrypt.org)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ 90-day certificate validity enforcement
∙ Automated certificate lifecycle management
∙ Let's Encrypt or ACME protocol (https://letsencrypt.org)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Shortened certificate validity periods per PQC guidance
∙ Certificate lifecycle management platform
∙ PKI preparation for PQC roots of trust
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Enterprise certificate lifecycle management with shortened validity periods
∙ PKI infrastructure preparation for PQC transition
∙ HSM-backed key generation with quantum-safe entropy
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise PKI with PQC-ready architecture
∙ Automated certificate lifecycle management (e.g., Venafi, Keyfactor)
∙ HSM infrastructure with quantum-safe entropy sources
∙ Dual-root hybrid trust model support
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
SCR-CMM Level 2 criteria definitions are not available for this control:
▪ A reasonable person would conclude a well-defined and standardized process is required.
▪ At this level of maturity, the “requirements-driven” nature of performing the control is focused on a localized and/or regionalized implementation, not uniform and consistent across the organization.
▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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 cryptographic keys and certificates in a manner that supports Post-Quantum Cryptography (PQC) transition by:
(1) Shortening validity periods for quantum-vulnerable certificates to reduce exposure;
(2) Preparing Public Key Infrastructure (PKI) for PQC roots of trust or dual-root hybrid trust models; and
(3) Ensuring key generation uses quantum-safe entropy sources.
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.
|
|
Quantum-Safe Public Key Infrastructure (PKI) Transition
|
Description
Mechanisms exist to transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Rely on cloud provider and CA/Browser Forum quantum-safe transitions
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Monitor CA/Browser Forum and browser vendor PQC adoption timelines
∙ Plan reliance on public CA quantum-safe transition
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Assess internal PKI for PQC transition readiness
∙ Evaluate hybrid certificate support in PKI platforms
∙ Certificate authority PQC roadmap review
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Internal PKI PQC transition plan
∙ Hybrid certificate deployment for critical services
∙ Trust anchor migration planning to quantum-safe algorithms
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise quantum-safe PKI transition program
∙ Hybrid certificate infrastructure deployment
∙ Trust anchor migration to NIST FIPS 203/204/205 algorithms
∙ Integration with enterprise certificate lifecycle management
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
Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
Level 2 Planned Tracked
SCR-CMM Level 2 criteria definitions are not available for this control:
▪ A reasonable person would conclude a well-defined and standardized process is required.
▪ At this level of maturity, the “requirements-driven” nature of performing the control is focused on a localized and/or regionalized implementation, not uniform and consistent across the organization.
▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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 transition Public Key Infrastructure (PKI) trust anchors to quantum-safe algorithms.
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.
|
|
Algorithm Negotiation Integrity
|
Description
Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to prevent attackers from forcing quantum-vulnerable algorithms through:
(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);
(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and
(3) Monitoring for downgrade attempts.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Enforce TLS 1.3 (includes transcript integrity protection)
∙ Disable TLS 1.0/1.1 and weak cipher suites
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ TLS 1.3 enforcement
∙ Disable deprecated cipher suites
∙ Monitor for TLS downgrade attempts via web application firewall
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ TLS 1.3 with strong cipher suite enforcement
∙ Monitoring for algorithm downgrade attempts
∙ Disallow classical-only cipher suite negotiation where PQC is deployed
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ TLS 1.3 enforcement with integrity-protected handshake
∙ Algorithm downgrade monitoring and alerting
∙ Cipher suite allowlisting across enterprise TLS infrastructure
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise TLS cipher suite governance with automated enforcement
∙ Algorithm negotiation integrity monitoring at scale
∙ Automated detection of downgrade attempts
∙ Integration with network security monitoring and SIEM
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
Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
Level 2 Planned Tracked
SCR-CMM Level 2 criteria definitions are not available for this control:
▪ A reasonable person would conclude a well-defined and standardized process is required.
▪ At this level of maturity, the “requirements-driven” nature of performing the control is focused on a localized and/or regionalized implementation, not uniform and consistent across the organization.
▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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) to prevent attackers from forcing quantum-vulnerable algorithms through:
(1) Integrity-protected algorithm negotiation (e.g., TLS 1.3 handshake transcript);
(2) Disallowing negotiation of classical-only cipher suites once Post-Quantum Cryptography (PQC) is deployed; and
(3) Monitoring for downgrade attempts.
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.
|
|
Hybrid / Composite Cryptography
|
Description
Mechanisms exist to leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:
(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);
(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and
(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Rely on browser/cloud/VPN vendors enabling hybrid PQC key exchange (e.g., X25519MLKEM768 in TLS)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Monitor TLS library and browser vendor hybrid PQC support
∙ Plan adoption of hybrid modes when widely available
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Pilot hybrid cryptography for highest-risk external-facing services
∙ IETF hybrid draft standards monitoring
∙ Vendor hybrid mode support assessment
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Hybrid cryptography deployment for critical services
∙ ECDH + ML-KEM hybrid KEM support
∙ Hybrid certificate testing and deployment
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise hybrid cryptography deployment program
∙ Hybrid KEM (ECDH + ML-KEM) and hybrid signatures (ECDSA + ML-DSA)
∙ PKI infrastructure supporting dual-key/dual-certificate models
∙ Plan for classical algorithm sunset post-PQC confidence
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
Quantum Security (QTS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
Level 2 Planned Tracked
SCR-CMM Level 2 criteria definitions are not available for this control:
▪ A reasonable person would conclude a well-defined and standardized process is required.
▪ At this level of maturity, the “requirements-driven” nature of performing the control is focused on a localized and/or regionalized implementation, not uniform and consistent across the organization.
▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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 leverage hybrid/composite algorithms as a transition path to Post-Quantum Cryptography (PQC) solutions that:
(1) Support hybrid signatures (e.g., ECDSA + ML-DSA) and hybrid Key Encapsulation Mechanisms (KEMs) (e.g., ECDH + ML-KEM);
(2) Ensure certificate formats, Public Key Infrastructure (PKI) and trust anchors can support dual-key or dual-certificate models; and
(3) Plan for eventual removal of classical algorithms once PQC confidence is sufficient.
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.
|
|
Cryptographic Application Programming Interface (API) Abstraction
|
Description
Mechanisms exist to use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Use standard libraries/platform cryptography (e.g., OpenSSL, .NET, Java) rather than custom implementations
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Use established cryptographic libraries with abstraction (e.g., OpenSSL, BouncyCastle)
∙ Avoid direct algorithm calls; use library-level interfaces
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Cryptographic abstraction requirements in development standards
∙ Use of crypto-agility compatible libraries
∙ Abstract cryptographic operations from application code
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Enterprise cryptographic API abstraction standard
∙ Use of PKCS#11 or equivalent for hardware abstraction
∙ Crypto abstraction layer in enterprise development frameworks
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise cryptographic API abstraction framework
∙ Universal cryptographic interface standard across all applications
∙ PKCS#11 and provider-based abstraction architecture
∙ Automated compliance checking for cryptographic abstraction
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
SCR-CMM Level 2 criteria definitions are not available for this control:
▪ A reasonable person would conclude a well-defined and standardized process is required.
▪ At this level of maturity, the “requirements-driven” nature of performing the control is focused on a localized and/or regionalized implementation, not uniform and consistent across the organization.
▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).
Level 3 Well Defined
Quantum Security (QTS) 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 QTS 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 QTS domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain QTS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 QTS 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 use a universal interface that bridges established cryptographic Application Programming Interface (API) frameworks by abstracting complex cryptographic operations to support cryptographic agility.
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.
|
1.1 Referenzen
1.2 Identifizierte Anforderungen
1.3 Zugehörige Regulierungen
2. Identifizierte Anforderungen
Anforderungen
| Quelle |
Anforderung |
3. Zugehörige Regulierungen
Regulierungen
| Quelle |
Regulierung |
Verknüpfte Vorgänge
- Secure Controls Framework -
"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.
|