I-0482: Properties Of Default Values For Attributes

TYPE:                 NIAP Interpretation
NUMBER:               I-0482
STATUS:               Ready to Send to Management/CCIMB

TITLE:                Properties Of Default Values For Attributes

SOURCE REFERENCE:     CC v2.1 Part 2 Subclause 8.2 FMT_MSA.3
                      CC v2.1 Part 2 Subclause H.2 FMT_MSA.3
RELATED TO:
     I-0442           Restrictive Is Not Fully Defined Without Specification Of Attributes

ISSUE:

It seems that these terms are ambiguous. Permissive could mean to allow all possible accesses or information flows or alternately to allow only some of the possible accesses or information flows. Similarly, restrictive could mean to deny all possible accesses or information flows or to deny only some of the possible accesses or information flows.

Part 2 doesn't seem to offer any insight into precisely what these selection options are supposed to indicate. Barring any guidance, it seems one could assume that the specific nature of restrictive and/or permissive could vary from TOE to TOE, much like it is left up to an ST author to define what "reliability" means in relation to FPT_STM.1.

STATEMENT

RECOMMENDED CRITERIA CHANGES

The following changes are CC V2.1 Part 2 Subclause 8.2 FMT_MSA.3, as modified by I-0442:

FMT_MSA.3.1. The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide [selection: restrictive, permissive, [assignment: other property]] default values for the following security attributes that are used to enforce the SFP: [assignment: list of security attributes in the scope of the identified SFP to which the restrictive, permissive, other default value property should apply].

FMT_MSA.3.2. The TSF shall ensure that the default values for the attributes satisfy the following rules: [assignment: for each attribute, an unambiguous specification of default value property rules for that attribute].

FMT_MSA.3.23. For each of the following attributes, the The TSF shall allow the [assignment: the authorised identified roles] to specify alternative initial values to be specified by the indicated roles to override the default values for these attributes when an object or information is created.: [assignment: table of attributes and the authorised identified roles permitted to override the default values for those attributes]

The following is added to CC V2.1 Part 2 Subclause H.2, under Assignment:

In FMT_MSA.3.2, the PP/ST author should describe, for each attribute covered by this component, the desired characteristics of the default values. For example, this might specify that these values give minimal access (restrictive) or provide maximal access (permissive). The rules can also be used to describe inheritance of attributes. In any case, the rules should use clearly defined terminology.

The following is changed in CC V2.1 Part 2 Subclause H.2, under Assignment, paragraph 1033:

In FMT_MSA.3.23, the PP/ST author should specify provide a table that specifies, for each attribute for which default override capabilities are desired, the roles that are allowed to modify the default value of the security attributes. The possible roles are specified in FMT_SMR.1.

SUPPORT:

MSA.3.1 The TSF shall ensure that [assignment: security attribute] has a default value of [assignment: value] when the object, subject or information that it belongs to is created.

MSA.3.2 The TSF shall allow [assignment: subject] to change this default value.

However, this doesn't work well in the CC v2.1 paradigm where it needs to be tied to a policy to define the attributes. Further, it doesn't allow the PP/ST author to indicate the desired characteristics for the default, leaving it open for the ST author to select. Yet there are problems with retaining the stock cc v2.1 solution, which used ill-defined terms ("restrictive", "permissive"). The approach taken in this interpretation is the middle ground: allow the specification via assignment, yet still provide for default values.