Adding of audits requirements

  - APPLICABILITY: All use cases.

## 5.3 Secure by default configuration

_Proposed ESR code SBD_

### 5.3.1 General requirements

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

TODO

## 5.4 Secure updates

## 5.3.1 SDBC - Monitoring

_Proposed ESR code: SU_

 - REFERENCE:  REQ-PKI-SBDC-002

  - REQUIREMENT: The audit log signing event shall be performed by default once a day.

  - RATIONALE: The audit record intergrity ensure that all auditable events are traceable and misuse of the product functions can be traced.

  - APPLICABILITY: All use cases.

## 5.4 Secure updates

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

## 5.5 Authentication and access control

_Proposed ESR code: AAC_

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

- REFERENCE: REQ-PKI-AAC-01

  - APPLICABILITY: All use cases.

- REFERENCE: REQ-PKI-AAC-02

  - REQUIREMENT:The product shall manage different user profiles, allowing RBAC. This mechanism shall provide means to define specific user account capabilities for the following roles:

  - REQUIREMENT:The product shall manage different user profiles, allowing Role Based Access Conrol (RBAC). This mechanism shall provide means to define specific user account capabilities for the following privildege roles:

    - U.Administrator

    This shall include the capability to limit user profile rigths for the following product actions:

    This shall include at least the capability to limit user profile rigths for the following product actions and their associtated assets (TODO reference to UC description):

      - F.UserAccountManagement

      - F.Network_Configuration

      - F.AuditEventManagement

      - F.CertificateProfileManagement

    And their associtated assets (TODO reference to UC description)

      - F.NoneSCD_BasedKeyPairGen 

    - APPLICABILITY: UC1.

- REFERENCE: REQ-PKI-AAC-03

  - REQUIREMENT:The product shall manage different user profiles, allowing RBAC. This mechanism shall provide means to define specific user account capabilities for the following roles:

    - U.Administrator, U.Officer, U.Auditor

    This shall include the capability to limit user profile rigths for the following product actions when implemented:

    This shall include at least the capability to limit user profile rigths for the following product actions and their associtated assets (TODO reference to UC description):

     - F.UserAccountManagement

     - F.Network_Configuration

     - F.None_SCD_Based_KeyManagement

     - F.AuditEventManagement

     - F.LoggingOfSecurityEvents 

     - F.CertificateProfileManagement

     - F.RevocationManagement

     - F.OfficerRevocationApproval

    And their associtated assets (TODO reference to UC description)

  - APPLICABILITY: UC2, UC3, UC4 and UC5.

### 5.5.1 Monitoring

  - RATIONALE: The audit record intergrity and availability ensure that all auditable events are traceable and misuse of the product functions can be traced. 

  - APPLICABILITY: All use cases.

## 5.6 Confidentiality

_Proposed ESR code: CON_

  - NOTE: Any PKCs stored in the product are intended for public dissemination and have, depending on the particular certificate specification, explicit means of protecting the content, thus no requirements are placed on the product that define the format and protections inherent to the PKC.

  - APPLICABILITY: XXXX

## 5.7 Integrity

_Proposed ESR code: INT_

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

## 5.7.1 Monitoring 

- REFERENCE: REQ-PKI-INT-001

  - REQUIREMENT: The product shall periodically create an audit log signing event in which it computes a digital signature, keyed hash, or authentication code over the entries in the audit log. The digital signature, keyed hash, or authentication code shall be computed over, at least:

    - every entry that has been added to the audit log since the previous audit log signing event;  

    - the digital signature, keyed hash, or authentication code from the previous audit log signed event. The digital signature, keyed hash, or authentication code from the audit log signing event shall be included in the audit log.

  -	RATIONALE: All entries of the audit log, and the order and exhaustivity of batches of entries should impact authenticity checks of the audit log. The audit record integrity ensure that all auditable events are traceable and misuse of the product functions can be traced. 

  - NOTE:	An audit log signing event is performed even if no entry was added to the audit log since the last one.

  -	APPLICABILITY: UC3 and UC4

   - NOTE: Not all integrity protection mechanisms can be foreseen so for use cases with lower regulation of standardization constraints (UC1, UC2) other approaches can be valid and so not identified here. Acceptable mechanisms include: append-only log storage, file-system integrity monitoring, hash-chained log entries, or forwarding to a trusted external log management system. The choice should be proportionate to the risk profile.

  -	APPLICABILITY: UC1, UC2

 - REFERENCE:  REQ-PKI-INT-005

  - REQUIREMENT: The specified frequency at which the audit log signing event occurs shall be configurable.

  - RATIONALE: The audit record intergrity ensure that all auditable events are traceable and misuse of the product functions can be traced.

  - APPLICABILITY: All use cases.

## 5.8 Data minimisation