PD 0136: Using CCv2.x PPs with CCv3.1 STs: Handling of FPT_SEP and FPT_RVM

["Observation Decisions Review Board" <faigin@aero.org>]

The ODRB has just issued the following PD. Any comments or corrections to this 
PD will be considered at the next ODRB meeting.

PD 0136: Using CCv2.x PPs with CCv3.1 STs: Handling of FPT_SEP and FPT_RVM

ISSUE

When evaluating a Common Criteria v3.1 Security Target, how does one
handle a claim of profile compliance to a CC v2.x profile? In
particular, the question is what is to be done with the FPT_SEP and
FPT_RVM components when an ST under CC v3.1 claims compliance with a CC
v2.x PP containing SEP and RVM.  

RESOLUTION

The ADV_ARC family is the CC v3.1 equivalent of FPT_SEP and FPT_RVM. The
CC v3.1 ST should include ADV_ARC.1 (or a higher level, if warranted by
the EAL), and this should be documented as demonstrably corresponding to
FPT_SEP and FPT_RVM by using the correspondence from the rationale. 

RATIONALE

The creation of the ADV_ARC family from what had been FPT_SEP and
FPT_RVM is perhaps the most drastic difference between versions 2 and 3
of the CC. The ARC family levies requirements on the TOE itself, not on
the description/evidence of the TOE. This notion was not in v2, which
meant that a TOE could presumably be constructed so that its security
could be bypassed or corrupted. This is also why this notion, in v3, is
no longer captured in functional requirements. 

In version 2, the security architecture requirements were functional, so
there were no requirements for (or guidance on) its description. As a
Part 3 requirement (v3.1), there must be a description provided, and
there is opportunity to explain how the description should be made. 

The "D" elements, developer action elements, such as ADV_ARC.1.1D, are
worded as requirements on the developer, and address how the developer
must design the TSF and provide evidence of that design. Consequently,
there is no direct mapping to them from CC v2. The remaining "C"
elements, content and presentation elements, address the characteristics
of the TSF, and how the design evidence demonstrates those
characteristics are present. The CC V2 Functional elements have the
following mappings to the ADV_ARC "C" elements: 

	FPT_RVM.1.1 -> ADV_ARC.1.5C
		From CC v2.3:

		FPT_RVM.1.1 The TSF shall ensure that TSP enforcement
		functions are invoked and succeed before each function
		within the TSC is allowed to proceed. 

		From CC v3.1:

		ADV_ARC.1.5C - The security architecture description
		shall demonstrate that the TSF prevents bypass of the
		SFR-enforcing functionality. 

	FPT_SEP.1.1 -> ADV_ARC.1.3C and ADV_ARC.1.4C
		From CC v2.3:

		FPT_SEP.1.1 The TSF shall maintain a security domain for
		its own execution that protects it from interference and
		tampering by untrusted subjects.  

		From CC v3.1:

		ADV_ARC.1.3C - The security architecture description
		shall describe how the TSF initialisation process is
		secure. 

		ADV_ARC.1.4C - The security architecture description
		shall demonstrate that the TSF protects itself from
		tampering. 

	Together, 1.3C and 1.4C prevent tampering from all potential
	sources, whether from elsewhere in the TSF, from outside the
	TSF, or from the initialization code (which might be considered
	inside or outside the TSF). 

	FPT_SEP.1.2 -> ADV_ARC.1.2C
		From CC v2.3:

		FPT_SEP.1.2 The TSF shall enforce separation between the
		security domains of subjects in the TSC.  

		From CC v3.1:

		ADV_ARC.1.2C The security architecture description shall
		describe the security domains maintained by the TSF
		consistently with the SFRs. 

Until the CC v2.1 PPs are recast into v3, it is appropriate to use
ADV_ARC in the ST, and include an argument of correspondence.