Security Objectives for the TOE

Updated 11 March 2024

This section is omitted for Direct Rationale PPs and PP-Modules.

CC:2022: "The TOE provides security functionality to solve a certain part of the problem defined by the SPD. This part-wise solution is called the security objectives for the TOE and consists of a set of objectives that the TOE shall achieve in order to solve its part of the problem."

The Security Objectives for the TOE Section can be declared in one of two ways:

   <section title="Security Objectives for the TOE" id="sec-uniqueId">

   <sec:Security_Objectives_for_the_TOE">

In XML, the TOE Security Objectives section consists of an <SOs> element that contains one or more <SO> elements.

Each <SO> element has a name attribute and an optional id. The id is only needed if there is a reason to refer to the <SO> by other than its name elsewhere in the document. Which is very unlikely.

The SO name should be of the form O.OBJECTIVE_NAME where the name is unique in the document. Ideally, Objective names should be common across all PPs so that they can be maintained in a library. So you should try to use Objectives that you've seen before.

Each <SO> element includes a description of the Objective, one or more <addressed-by> elements referencing the SFRs that support the Objective, and a rationale explaining how each SFR supports the Objective. The rationales are used to auto-generate the TOE Security Functional Requirements Rationale section.

The SFRs are not referenced by id, but rather by their CC name as in the example below. SFRs that are selection-based or optional can be noted as such.

	<SO name="O.MITIGATE_FUNDAMENTAL_FLAWS">
  	  <description>The TOE must have a capability for mitigating or fixing fundamental flaws through update 
		or some other technical or operational means. This includes specifications of:<h:ul>
		<h:li>Requirements for updateability of TOE firmware.</h:li></h:ul>
	  </description>
	  <addressed-by>FPT_TUD_EXT.1</addressed-by>
             <rationale>Supports the objective through requiring that a TOE be either updateable or immutable.</rationale>
	  <addressed-by>FPT_TUD_EXT.2 (sel-based)</addressed-by>
             <rationale>Supports the objective through specifying an authenticated firmware update mechanism.</rationale>
	  <addressed-by>FPT_TUD_EXT.3 (sel-based)</addressed-by>
             <rationale>Supports the objective through specifying a firmware update mechanism with delayed authentication.</rationale>
  	  <addressed-by>FPT_TUD_EXT.4 (sel-based)</addressed-by>
             <rationale>Supports the objective through specifying a secure local firmware update mechanism.</rationale>		  
	</SO>