Commit b69aee5a authored by Sammy Haddad's avatar Sammy Haddad
Browse files

New assessment requirements for secure by defauflt req.

parent 58e1cf8d
Loading
Loading
Loading
Loading
+247 −6
Original line number Diff line number Diff line
@@ -1052,6 +1052,8 @@ _Proposed ESR code: IM_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (i).

The primary impact of a PKI product on its environment is the unavailability of its services. PKI systems are passive systems that respond to requests from external entities. Therefore, minimizing the impact on other systems relies on the combination of requirements identified in clause 5 that collectively ensure the PKI product correctly manages the Public Key Certificate (PKC) lifecycle and provides the appropriate level of trust to dependent systems.

## 5.11 Minimisation of attack surfaces

_Proposed ESR code: MAS_
@@ -1059,8 +1061,8 @@ _Proposed ESR code: MAS_
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (j).

- REFERENCE: 	REQ-PKI-MAS-01
  - REQUIREMENT: TODO Only interfaces identified for each use case in Annex U shall be implemented.
  - RATIONALE: XXX
  - REQUIREMENT: Only interfaces identified for each use case in Annex U shall be implemented.
  - RATIONALE: Only interfaces implementing functions provided by each use case are necessary.
  - APPLICABILITY: All use cases.


@@ -1109,20 +1111,20 @@ To limit certificate forgery or misuse of certificate content, this section defi

  - RATIONALE: Only valid certifcates as defined by the product service provider policies shall be generated by the product.

  - APPLICABILITY: All use cases where the product has a certificate generation service, issuing public-key certificates.
  - APPLICABILITY: All use cases.

- REFERENCE: REQ-PKI-EMM-06
  - REQUIREMENT: The product shall disallow the keyUsage extension to simultaneously include values from both of:
    - digitalSignature, contentCommitment, keyCertSign, cRLSign; and
    - keyEncipherment, dataEncipherment, keyAgreement.
  - RATIONALE: The same public key may not be used for signature verification, and encryption or key agreement. Only valid certifcates as defined by the PKI service provider policies shall be generated by the product.
  - APPLICABILITY: TODO All use cases where the product has a certificate generation service, issuing public-key certificates.
  - APPLICABILITY: All use cases.

- REFERENCE: REQ-PKI-EMM-07
  - REQUIREMENT: The product shall verify that the prospective certificate subject possesses the private key that corresponds to the public key in the certificate request before issuing a certificate, unless the public/private key pair was generated by the product and never left the certificate issuance service.
  - RATIONALE: A subject bringing forth his own public key should prove ownership of the corresponding private key. The product may generate a key pair and associated public key, and later communicate the private key to the correct subject in a secure manner. This may notably be done for other components of the product itself needing public-key certificates. The same private key should not be owned by distinct subjects, including other services of the product; if the private key was generated by the product but already provided to the subject once, the subject can and should prove its ownership.

  - APPLICABILITY: All use cases where the product has a certificate generation service, issuing public-key certificates.
  - APPLICABILITY: All use cases.

### 5.12.2 Certificate status

@@ -1357,6 +1359,244 @@ The assessment criteria for each security requirements are described in a struct

## 6.3 Secure by default configuration

- REFERENCE: ACC-PKI-SBDC-01
  -OBJECTIVE:
    Determine whether the product only maintains network configuration data necessary for communication with PKI system elements required by the applicable use case and does not maintain unnecessary network configuration information.

  - PREPARATION:
    - Product architecture and deployment documentation.
    - List of PKI system components and interfaces to connect to.
    - Access to configuration files, administrative guides, and installation procedures.
  
  - ACTIVITIES:
    1. Review the product design and configuration documentation.
    2. Identify all stored network configuration parameters.
    3. Verify that each configured endpoint, interface, protocol, and network parameter is required to support the applicable PKI use case.
    4. Verify that no unused, unnecessary, or undocumented network configuration data are maintained.
    5. Confirm that administrators cannot configure network connections unrelated to the PKI functions provided by the product.

  - VERDICT:
    - SUCCESS:
      - All maintained network configuration data are necessary for communication with PKI elements required by the applicable use case.
      - No unnecessary network endpoints, protocols, interfaces, or configuration parameters are maintained.
    - FAIL:
      - The product maintains network configuration data unrelated to the applicable PKI functions.
      - Unnecessary interfaces or endpoints are configured or can be configured without operational justification.

  - EVIDENCE:
    - Product architecture documentation.
    - Configuration files and parameter listings.
    - Assessment records demonstrating the review of network configuration parameters.

- REFERENCE: ACC-PKI-SBDC-02
  - OBJECTIVE:

  - Determine whether the product maintains only the configuration data required to implement the PKC management functions applicable to the use case.

  - PREPARATION:

  - Obtain Annex U use case definitions.
  - Obtain product configuration documentation.
  - Obtain a list of implemented PKC management functions and associated configuration parameters.

  - ACTIVITIES:

  1. Review the applicable use case requirements.
  2. Identify all PKC management functions implemented by the product.
  3. Review all PKC-related configuration parameters.
  4. Verify that each configuration item supports an identified PKC management function.
  5. Verify that unnecessary PKC management functions and associated configuration data are not maintained.

  - VERDICT:

    - SUCCESS:

    - All PKC configuration parameters support identified certificate management functions required by the applicable use case.
    - No unnecessary PKC management functions or associated configuration data are maintained.
    - FAIL:

    - Configuration data are maintained for PKC functions not required by the applicable use case.
    - Unnecessary PKC management capabilities are present.

  - EVIDENCE:

  - Use case analysis.
  - Product functional specifications.
  - Configuration documentation.
  - Assessment records mapping configuration parameters to PKC functions.

- REFERENCE: ACC-PKI-SBDC-03

  - OBJECTIVE:

  - Determine whether the product only stores and processes user data required to perform certificate management functions.

  - PREPARATION:

  - Obtain data flow diagrams.
  - Obtain database schemas and storage specifications.
  - Obtain descriptions of certificate management operations.
  - Identify user data processed by the product.

  - ACTIVITIES:

  1. Review the certificate management workflows.
  2. Identify all categories of user data collected, stored, processed, and transmitted.
  3. Verify that each category of user data is necessary to support certificate management functions.
  4. Verify that unnecessary user information is neither stored nor processed.
  5. Review logs and temporary storage mechanisms to ensure unnecessary user data are not retained.

  - VERDICT:

    - SUCCESS:

    - All maintained and processed user data are necessary to perform certificate management functions.
    - No unnecessary user data are collected, processed, or retained.
    - FAIL:

    - User data unrelated to certificate management are collected, processed, or retained.
    - Excessive or unnecessary data are stored by the product.

  - EVIDENCE:

  - Data flow diagrams.
  - Database schemas.
  - Data dictionaries.
  - Configuration and logging documentation.
  - Assessment records demonstrating data mapping.


- REFERENCE: ACC-PKI-SBDC-04


  - OBJECTIVE:

  - Determine whether all key generation operations are performed exclusively by approved Secure Cryptographic Devices (SCDs) or remote Key Management Systems (KMSs) implementing cryptographic mechanisms conformant with Annex K.

  - PREPARATION:

  - Obtain the cryptographic architecture documentation.
  - Obtain documentation for the SCD or KMS.
  - Obtain cryptographic algorithm specifications and configuration information.
  - Identify all key generation functions.

  - ACTIVITIES:

  1. Review the product's cryptographic architecture.
  2. Identify all key generation operations.
  3. Verify that keys are generated only by approved SCDs or remote KMSs.
  4. Verify that no software-based key generation mechanism exists outside the SCD or KMS.
  5. Verify that the cryptographic mechanisms used by the SCD or KMS conform to Annex K requirements.

  - VERDICT:

    - SUCCESS:

    - All key generation operations are delegated exclusively to approved SCDs or remote KMSs.
    - The cryptographic mechanisms employed conform to Annex K requirements.
    - FAIL:

    - Keys can be generated outside an SCD or KMS.
    - The SCD or KMS uses non-approved cryptographic mechanisms.

  - EVIDENCE:

  - Cryptographic architecture documentation.
  - SCD/KMS specifications and certifications.
  - Configuration files.
  - Assessment records demonstrating key generation paths.


- REFERENCE: ACC-PKI-SBDC-05


  - OBJECTIVE:

  - Determine whether communications with the SCD or KMS are securely established and whether interfaces are correctly implemented and invoked.

  - PREPARATION:

  - Obtain interface specifications.
  - Obtain communication protocol documentation.
  - Obtain configuration information for SCD/KMS connections.
  - Obtain error handling and operational procedures.

  - ACTIVITIES:

  1. Review the communication architecture between the product and the SCD or KMS.
  2. Verify that communication channels are authenticated and protected.
  3. Verify the use of secure protocols and cryptographic protections.
  4. Verify that SCD/KMS interfaces are correctly invoked according to the interface specifications.
  5. Verify handling of communication failures and abnormal conditions.

  - VERDICT:

    - SUCCESS:

    - Communications with the SCD or KMS are securely established and maintained.
    - Interfaces are implemented and invoked according to their specifications.
    - Communication failures are securely handled.
    - FAIL:

    - Communication channels are not adequately protected.
    - Interface calls deviate from specifications.
    - Communication failures lead to insecure states.

  - EVIDENCE:

  - Interface specifications.
  - Communication protocol documentation.
  - Configuration files.
  - Test results and interface traces.
  - Assessment records.


- REFERENCE: ACC-PKI-SBDC-06


  - OBJECTIVE:

  - Determine whether secret keys are protected against persistent plaintext storage and are exposed in plaintext only temporarily for authorised cryptographic operations.

  - PREPARATION:

  - Obtain key management architecture documentation.
  - Obtain storage architecture documentation.
  - Obtain cryptographic configuration information.
  - Identify all secret key types and storage locations.

  - ACTIVITIES:

  1. Review the product's key management design.
  2. Identify all locations where secret keys may reside.
  3. Verify that secret keys are stored only within an SCD or encrypted using approved algorithms and independently managed keys.
  4. Verify that plaintext secret keys are not persistently stored.
  5. Verify that plaintext exposure is temporary and limited to individual operations or authorised batches of operations.
  6. Review memory handling and key destruction procedures.

  - VERDICT:

    - SUCCESS:

    - Secret keys are never persistently stored in plaintext.
    - Secret keys are stored within an SCD or protected using approved encryption mechanisms and independently managed keys.
    - Plaintext key exposure is temporary and operationally limited.
    - FAIL:

    - Secret keys are persistently stored in plaintext.
    - Keys are stored using unapproved protection mechanisms.
    - Plaintext keys remain accessible beyond authorised operations.

  - EVIDENCE:

  - Key management architecture documentation.
  - Storage architecture and configuration documentation.
  - Cryptographic specifications.
  - Source code review records, if available.
  - Memory analysis and test results.
  - Assessment records demonstrating key handling and destruction procedures.


## 6.4 Secure updates
- REFERENCE: ACC_PKI_SU_01
  - OBJECTIVE:
@@ -1831,7 +2071,8 @@ REFERENCE: ACC_PKI_DM_04

- REFERENCE: ACC_PKI_EMM_05

  - OBJECTIVE: Verify that the product requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-5.3-04.
  - OBJECTIVE: Verify that the product requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-PKI-EMM-03
and REQ-PKI-EMM-04.

  - PREPARATION: Document the circumstances in which the certificate generation service may issue a public-key certificate.