[Public Interpretations Database]

I-0463: Platform Inclusion In A TOE With FPT_SEP

 
TYPE:                 Guidance
NUMBER:               I-0463
STATUS:               Sent to CCEVS Management and CCIMB for Review

TITLE:                Platform Inclusion In A TOE With FPT_SEP

FIRST POST:            [cc-cmt 00252]
MOST RECENT REPOST:    [cc-cmt 00368]

RELATED TO:           <None>
CCIMB ENTRY:          CCIMB-INTERP-0239,CCIMB-INTERP-0251

ISSUE:

Must the underlying platform (hardware, software) be included in a TOE that includes FPT_SEP as one of the TOE's SFRs?

STATEMENT

All TOE Objectives (which map to Security Functional Requirements) must be met by the TSF. It is not acceptable to meet a TOE Objective by a requirement allocated to the IT environment.

Hence, if FPT_SEP is included as an objective for the TOE, then one of the following conditions should be met:

  1. The relevant portions of the underlying platform should be included.

  2. An argument should be made that FPT_SEP is satisfied independent of the relevant portions of the underlying platform.

  3. The FPT_SEP requirement should be refined to be explicit about what the TOE is providing combined with an explicit specification about what the environment does.

SPECIFIC INTERPRETATION

No criteria changes required. This guidance is supported by the CEM Work Unit ASE_REQ.1-20 as interpreted by CCIMB-INTERP-0058.

SUPPORT:

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.

Similarly, FPT_SEP.1.2 talks about enforcing separation between the security domains of subjects in the TSC (which is typically interpreted to refer to process address spaces, for operating systems). If this is allocated to the TOE but not 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, FPT_SEP should be allocated to the IT Environment (Operational Environment), or 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 refined appropriately.