Update of the risk analysis annex

# 5  Requirements for PKI products

## 5.1 Auditing

REFERENCE: 	REQ-5.1.5.1-01

REFERENCE: 	REQ-5.1-01

REQUIREMENT: The PKI shall record within each audit record at least the following information:

a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and

b) For each audit event type, based on the auditable event definitions in TODO, the additional information specified in TODO.

EXAMPLES:

APPLICABILITY:

REFERENCE: 	REQ-5.1.5.1-02

REFERENCE: 	REQ-5.1-02

REQUIREMENT: The PKI shall employ reliable time stamps.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.1-03

REFERENCE: REQ-5.1-03

REQUIREMENT: For audit events resulting from actions of identified users, the PKI shall be able to associate each auditable event with the identity of the user that caused the event.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.1-04

REFERENCE: REQ-5.1-04

REQUIREMENT: The PKI shall protect the stored audit records in the audit log from unauthorised deletion.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.1-05

REFERENCE: REQ-5.1-05

REQUIREMENT: The PKI shall be able to detect unauthorised modifications to the stored audit records during the audit.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.1-06

REFERENCE: REQ-5.1-06

REQUIREMENT: The PKI shall prevent auditable events, except those taken by the auditor, if the audit log is full.

RATIONALE: The audit log being full should not allow for old audit records to be lost or future auditable events to happen without record.

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.1-07

REFERENCE: REQ-5.1-07

REQUIREMENT: The PKI 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, :

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.1-08

REFERENCE: REQ-5.1-08

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

RATIONALE:

NOTE:

## 6.1 Auditing

REFERENCE: ASS-REQ-5.1.5.1-01

REFERENCE: ASS-REQ-6.1-01

OBJECTIVE: Verify that the PKI records within each audit record the required information, and that these records do not include any secret key or other secret parameter in plaintext form.

PREPARATION: Ability to trigger auditable events, and ability to audit events.

ACTIVITIES:

VERDICT: SUCCESS if all the verifications pass; else FAIL.

EVIDENCE: The way the events were triggered and at what time, and the corresponding audit records.

REFERENCE: ASS-REQ-5.1.5.1-02

REFERENCE: ASS-REQ-6.1-02

OBJECTIVE: Verify that the PKI employs reliable time stamps.

PREPARATION: Ability to trigger auditable events, and ability to audit events. Obtain access to a trusted time stamp origin. Determine how the PKI determines its time stamps.

ACTIVITIES: Trigger an auditable event. Access the corresponding audit record. Verify the date and time of the event to match the trusted time stamp origin.

b) arguments relating to the authentication of a trusted source (if applicable);

c) arguments relating to the monotonicity of local time information (if applicable).

REFERENCE: ASS-REQ-5.1.5.1-03

REFERENCE: ASS-REQ-6.1-03

OBJECTIVE: Verify that the PKI records within each audit record resulting from actions of identified users the corresponding user information.

PREPARATION: Ability to identify to the PKI as a given user. Ability to trigger auditable events as a user, and ability to audit events.

ACTIVITIES: Identify to the PKI as the given user. Trigger an auditable event as the given user. Access the corresponding audit record.

a) The identity of the given user used for the test;

a) the way the event was triggered and at what time, and the corresponding audit record.

REFERENCE: ASS-REQ-5.1.5.1-04

REFERENCE: ASS-REQ-6.1-04

OBJECTIVE: Verify PKI protections from unauthorised deletion to be active and functional.

PREPARATION:  Ability to identify to the PKI as a given user, unauthorised to perform audit record deletion. Ability to trigger auditable events as a user, and ability to audit events. Determine all actions that may result in deletion of an audit record. Depending on this list of actions, several distinct users with distinct authorizations may be used.

ACTIVITIES: Identify to the PKI as the given user. Trigger an auditable event as the given user. Access and copy audit records separately.

c) the way the actions were attempted, including the corresponding user identity;

d) the copies of existing audit records, before and after attempts.

REFERENCE: ASS-REQ-5.1.5.1-05

REFERENCE: ASS-REQ-6.1-05

OBJECTIVE: Verify the PKI's ability to detect unauthorised modifications to the stored audit records during the audit.

PREPARATION: Ability to trigger auditable events as a user, and ability to audit events. Ability to directly modify the contents of existing audit records.

ACTIVITIES: Trigger an auditable event. Access and copy the corresponding audit record separately.

b) the way the audit record was directly modified;

c) the way the last audit was attempted, and the corresponding response from the PKI.

REFERENCE: ASS-REQ-5.1.5.1-06

REFERENCE: ASS-REQ-6.1-06

OBJECTIVE: Verify the PKI's prevention of auditable events, except those taken by the auditor, if the audit log is full.

PREPARATION: Ability to trigger auditable events, and ability to audit events. The maximum size of the audit log may be reduced.

ACTIVITIES: Do not identify as an auditor to the PKI. Trigger auditable events until the audit log is full, or nearly so.

b) The size of the audit when full, or nearly so;

c) the way the additional event was attempted to be triggered, and the corresponding response from the PKI.

REFERENCE: ASS-REQ-5.1.5.1-07

REFERENCE: ASS-REQ-6.1-07

OBJECTIVE: Verify the use of an audit log signing event by the PKI.

PREPARATION: Ability to trigger auditable events, and ability to audit events.

Determine the configured frequency of the audit log signing event and date of the audit log signing event. The frequency of the audit log signing event may be reduced; the event shall not be triggered manually.

d) the way the audit record of the triggered event was modified;

d) the way the second-to-last signature, keyed hash or authentication code was modified.

REFERENCE: ASS-REQ-5.1.5.1-08

REFERENCE: ASS-REQ-6.1-08

OBJECTIVE: Verify the frequency of the audit log signing event by the PKI to be configurable.

PREPARATION: Ability to trigger auditable events, and ability to audit events. Ability to configure the frequency of the audit log signing event.

ACTIVITIES: Modify the frequency of the audit log signing event.

EVIDENCE:

# Annex B: <br>Title of annex

## B.1 First clause of the annex

## B.1.1 First subdivided clause of the annex

# Annex A Mapping with essential requirements of the CRA

# Annex P: <br>CIMC Threats

# Annex B Mappings

## B.1 Mapping of technical security requirements and assessment requirements

## B.2 Mapping of technical security requirements and risks factors

## B.3 Other relevant mappings, as appropriate

_Old text moved from SP1 threats section_

# Annex C Risk acceptance criteria and risk management methodology (informative) (PT1 6.3)

## C.1 Risk acceptance + risk management methodology

From Certificate Issuing and Management Components Protection Profile Version 1.5  11 August, 2011

Threats - Authorized Users

T.Administrative errors of omission - Administrators, Operators, Officers or Auditors fail to perform some function essential to security.

T.Administrators, Operators, Officers and Auditors commit errors or hostile actions – An Administrator, Operator, Officer or Auditor commits errors that change the intended security policy of the system or application or maliciously modify the system’s configuration to allow security violations to occur.

T.User abuses authorization to collect and/or send data - User abuses granted authorizations to improperly collect and/or send sensitive or security-critical data.

T.User error makes data inaccessible -  User accidentally deletes user data rendering user data inaccessible.

Threats - System

T.Critical system component fails - Failure of one or more system components results in the loss of system critical functionality. Threat agent in this case is the CIMC hardware. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

<div align="center">

<img src="media/ImpactScale.png" width="600">

<strong>Figure C.1.1</strong>

</div>

T.Flawed code - A system or applications developer delivers code that does not perform according to specifications or contains security flaws. Threat agent in this case is the PKI developer. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

<div align="center">

<img src="media/RiskCalculationMatrix.png" width="600">

<strong>Figure C.1.2</strong>

</div>

T.Malicious code exploitation - An authorized user, IT system, or hacker downloads and executes malicious code, which causes abnormal processes that violate the integrity, availability, or confidentiality of the system assets. Threat agent could be an authorized user, PKI itself, or an unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying

party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

<div align="center">

<img src="media/RiskFactorDep.png" width="600">

<strong>Figure C.1.3</strong>

</div>

T.Message content modification - A hacker modifies information that is intercepted from a communications link between two unsuspecting entities before passing it on to the intended recipient. Threat agent is an unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

<div align="center">

<img src="media/RiskFactorNet.png" width="600">

<strong>Figure C.1.4</strong>

</div>

Threats – Cryptography

<div align="center">

<img src="media/RiskFactorUsr.png" width="600">

<strong>Figure C.1.5</strong>

</div>

T.Disclosure of private and secret keys - A private or secret key is improperly disclosed. Threat agent is the authorized user or erroneous protocol. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

<div align="center">

<img src="media/LikelihoodScale.png" width="600">

<strong>Figure C.1.6</strong>

</div>

T.Modification of private/secret keys - A secret/private key is modified. Threat agent is the authorized user or erroneous protocol. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP

Responses.

<div align="center">

<img src="media/RiskFactorAva.png" width="600">

<strong>Figure C.1.7</strong>

</div>

T.Sender denies sending information - The sender of a message denies sending the message to avoid accountability for sending the message and for subsequent action or inaction. Threat agent is a subscriber to CIMC. Adverse action can be reduced trust in CIMC.

<div align="center">

<img src="media/RiskFactorIn.png" width="600">

<strong>Figure C.1.8</strong>

</div>

Threats – External Attacks

<div align="center">

<img src="media/RiskFactorOps.png" width="600">

<strong>Figure C.1.9</strong>

</div>

T.Hacker gains access - A hacker masquerades as an authorized user to perform operations that will be attributed to the authorized user or a system process or gains undetected access to a system due to missing, weak and/or incorrectly implemented access control causing potential violations of integrity, confidentiality, or availability. Threat agent is the unauthorized user.

<div align="center">

<img src="media/RiskAcceptanceThreshold.png" width="600">

<strong>Figure C.1.10</strong>

</div>

T.Hacker physical access - Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses. A hacker physically interacts with the system to exploit vulnerabilities in the physical environment, resulting in arbitrary security compromises. Threat agent is the unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

<div align="center">

<img src="media/RiskFactorConf.png" width="600">

<strong>Figure C.1.11</strong>

</div>

T.Social engineering - A hacker uses social engineering techniques to gain information about system entry, system use, system design, or system operation. Threat agent is the unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

<div align="center">

<img src="media/RiskFactorInt.png" width="600">

<strong>Figure C.1.12</strong>

</div>

<br />

<div align="center">

<img src="media/RiskFactorTra.png" width="600">

<strong>Figure C.1.13</strong>

</div>

## C.2 Risk Assessment 

## C.2.1 ID Asset

## C.2.2 ID Threat

## C.2.3 Estimate Risks (Risk factors)

## C.2.4 Evaluate Risks

# Annex: Bibliography