[Public Interpretations Database]

I-0373: FPT_SEP.2 And FPT_SEP.3 Are Not Hierarchical

 
TYPE:                 NIAP Interpretation
NUMBER:               I-0373
STATUS:               Formally Superseded

TITLE:                FPT_SEP.2 And FPT_SEP.3 Are Not Hierarchical
SUPERSEDED BY:        
     I-0424           FPT_SEP.2 And FPT_SEP.3 Are Not Hierarchical

EFFECTIVE:            2000-03-27
SUPERSEDED:           2000-12-05

SOURCE REFERENCE:     CC v2.1 Part 2 Subclause 10.11 FPT_SEP
                      CC v2.1 Part 2 Subclause J.11 FPT_SEP
RELATED TO:           <None>
CCIMB ENTRY:          CCIMB-INTERP-0110

STATEMENT

The following interprets the entire FPT_SEP family:

FPT_SEP.2 and FPT_SEP.3 permit some or all access control and information flow SFPs to be in a distinct domain and are not hierarchical.

RECOMMENDED CRITERIA CHANGES

To address this interpretation, the following changes should be made to FPT_SEP: (additions marked thusly; deletions marked thusly):

  • FPT_SEP.2.3 should be changed to: " ... in a security domains for ..."

  • FPT_SEP.3.3 should be changed to: "... in a security domains for their own..."

  • A new component, FPT_SEP.4, should be created that is the same as FPT_SEP.3, except that element FPT_SEP.4.3 should be changed to: " ... each in a security domain for its ..."

  • The hierarchy should be modified so that both FPT_SEP.2 and FPT_SEP.3 are hierarchical to FPT_SEP.1, and the new component FPT_SEP.4 is hierarchical to both FPT_SEP.2 and FPT_SEP.3.

SUPPORT:

According to Section 2.1.2.3 in Part 2, "A component is hierarchical to another if it offers more security." The problem is that FPT_SEP.2, depending on the instantiation, does not necessarily provide less security than FPT_SEP.3. It could be instantiated to provide the same security as FPT_SEP.3. Hence, FPT_SEP.3 cannot be hierarchical to FPT_SEP.2.

To correct this problem, adjust the hierarchy to make FPT_SEP.3 hierarchical to FPT_SEP.1, not FPT_SEP.2. To make clear that placing each access control and information flow SFP into a separate domain provides more security than having two or more SFPs in a single domain, an additional component is added that is hierarchical to both FPT_SEP.2 and FPT_SEP.3 that has each SFP in its own domain.

This change further corrects the inconsistency between CC Part 2 and the CC Part 2 Annex in making clear that FPT_SEP.2 and FPT_SEP.3 may have more than a single domain for the SFPs.

Note that both components (FPT_SEP.2 and FPT_SEP.3) allow for distinct domains per SFP, and that both components are silent with respect to non-data protection SFPs.