Direct Rationale Documents - commoncriteria/pp-template GitHub Wiki

11 March 2024

Direct Rationale is an "approach" to protection profiles that eschews Security Objectives. Rather than mapping Threats to Objectives and Objectives to SFRs, in Direct Rationale PPs, Threats are mapped directly to SFRs.

So, for Direct Rationale PPs, the Security Problem Definition contains Threats, Assumptions, and Operational Security Policies as before. There is still a Security Objectives section, but it contains only Security Objectives for the Operational Environment and the Security Objectives Rationale. There is no "Security Objectives for the TOE" section. The Security Objectives Rationale is auto-generated to display the mappings between Assumptions or OSPs and the Security Objectives for the Operational Environment.

The mapping of Threats to SFRs appears in the Security Functional Requirements Rationale section after the SFRs. This is where the mapping between Objectives and SFRs is displayed for standard approach documents.

The only way to indicate that a document is Direct Rationale is to set the cc-approach attribute of the <CClaimsInfo> element to "direct-rationale". See Conformance Claims 2024.

In Direct Rationale documents, threats are mapped to SFRs in a similar manner as threats are mapped to objectives in standard rationale PPs. The difference is that the <addressed-by> tag is used rather than the <objective-refer> tag. Each <addressed-by> tag is paired with a <rationale> tag.

For example

	<threat name="T.NETWORK_EAVESDROP">
		<description>An attacker is positioned on a communications channel or elsewhere on the
		        network infrastructure. Attackers may monitor and gain access to data exchanged between
			the application and other endpoints.</description>
		<addressed-by>FCS_CKM_EXT.1</addressed-by><rationale>This SFR addresses this threat by requiring that the TSF
                        rely on platform-provided key generation services.</rationale>
		<addressed-by>FCS_RBG_EXT.1</addressed-by><rationale>The PP addresses this threat by requiring 
                        that the TSF rely on platform-provided random bit generation services.</rationale> 
        </threat>

CC:2022 recommends--but does not require--that the Threat-to-SFR mapping be displayed in the Threats section after each threat. For documents written in NIAP XML, the mapping is displayed in the TOE SFR Rationale section. This is because it is the simplest way to do it given that the information was already being generated for the TOE SFR Rationale table.

Naturally, no Security Objectives are included in the PP or Module, so they are not displayed. The Objectives for the Operational Environment and mappings to Assumptions and Operational Security Policies are still displayed.

In PP-Modules, the Security Objectives Rationale table for each Base-PP is removed.