PD-0112: Can a non-hardware TOE claim conformance with FPT_SEP.1?

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

Can a non-hardware TOE claim conformance with FPT_SEP.1? If not, must the "Consistency Instruction Manual For development of US Government Protection Profiles (PP) For use in Basic Robustness Environments" guidance be followed when dealing with a TOE that does not include hardware?

Resolution

As noted in I-0463, the hardware usually needs to be included if FPT_SEP is being claimed. It is insufficient to claim a reliance upon the environment to provide the separation, because TOE requirements must be met by the TOE; environmental requirements may be met by the environment or the TOE.

The rule is: the TOE must meet its claimed SFRs without dependency on its environment. As an example, consider FAU_STG.1. Unless the TOE includes management of its own resources (e.g., the TOE includes the file system), FAU_STG.1 would be met by the environment rather than by the TOE. Other requirements that would likely be met only by including the operating system and hardware in the TOE are FPT_STM, FDP_RIP, and FPT_RVM.

Given that hardware (and usually operating system support) is necessary to completely meet the FPT_SEP requirements as currently written, there is still some support for separation that an application TOE can provide (such as taking advantage of distinct processes, file protections, and other services provided by the operating system). Unfortunately, the CC does not provide a "lite" version of SEP that could accommodate such conditions, hence the need to create explicit requirements as was done in the Basic Robustness guide.

It is worth noting that the same holds for FPT_RVM, FPT_STM, and FDP_RIP (see PD-0081): while a software-only TOE can contribute to meeting these SFRs, it cannot meet them completely, and so a similar explicit requirement should be used for each to spell out the TOE's contribution to meeting the CC requirement.

Support

In general, the rationale for this decision is similar to that of I-0463:

CEM Work Unit ASE_REQ.1-20 requires that the security requirements rationale provide a justification that every security objective for the TOE is satisfied by the TOE security requirements. There is no provision for security objectives for the TOE being satisfied by requirements on the IT environment.

Of particular interest is the FPT_SEP requirement. FPT_SEP.1.1 says, "The TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects". If this requirement is allocated to the application TOE, this means the application is 100% responsible for providing such protection, completely independent of the behavior of applications on the underlying abstract machine (operating system, hardware). For an operating system TOE, this means the TOE provides the protection independent of the behavior of anything else running on the hardware. Note that a vast majority of application TOEs are not capable of meeting this.

Similarly, FPT_SEP.1.2 is concerned with enforcing separation between the security domains of subjects in the TSC (which is typically interpreted to refer to process address spaces in the case of operating systems). If this element is allocated to the TOE but not to the hardware, this means the TOE must provide the capability independent of the hardware.

With respect to hardware being required to meet FPT_SEP: Although with current technology hardware support is always used to achieve domain separation and process separation, the ability to provide such separation through software mechanisms alone is conceivable. However, if hardware is excluded, there must be a clear argument that the hardware in no way contributes to the software's satisfaction of FPT_SEP, or there must be an explicit objective for the operational environment to provide the necessary support.

With respect to applications claiming FPT_SEP: In order to do so, one must be able to show that the application provides mechanisms that implement FPT_SEP independent of any operating system support. With current technology, however, operating system support is usually required to achieve FPT_SEP, and hence, (1) FPT_SEP should be allocated to the IT Environment (Operational Environment), or (2) the extent to which the operating system provides support for FPT_SEP should be detailed in the Objectives for the Operational Environment (IT Environment), and the FPT_SEP requirement on the TOE should be refined appropriately.

Modification History:

2004-11-22

PD Created. (October 2004 ODRB Agenda Item 3.a.ii)

2007-02-13

Typo corrected [February 2007 ODRB Agenda Item 4.d.ii]

References:

• CC v2.1 Part 2, FPT_SEP.1

Related NIs:

• I-0463: Platform Inclusion In A TOE With FPT_SEP

Related CCIMB-INTERPs:

• None

Source OD: 0237