FDP_IFF.2 Hierarchical security attributes
User application notes
This component requires that all information flow control SFPs in the TSP use hierarchical security attributes that form a lattice.
For example, it should be used when at least one of the information flow control SFPs in the TSP is based on labels as defined in the Bell and LaPadula security policy model [B&L] and form a hierarchy.
It is important to note that the hierarchical relationship requirements identified in FDP_IFF.2.5 need only apply to the information flow control security attributes for the information flow control SFPs that have been identified in FDP_IFF.2.1. This component is not meant to apply to other SFPs such as access control SFPs.
Like the preceding component, this component could also be used to implement a privilege policy that covers rules that allow for the explicit authorisation or denial of information flows.
If it is the case that multiple information flow control SFPs are to be specified, and that each of these SFPs will have their own security attributes that are not related to one another, then the PP/ST author should iterate this component once for each of those SFPs. Otherwise a conflict might arise with the sub-items of FDP_IFF.2.5 since the required relationships will not exist.
Operations
Assignment:
In FDP_IFF.2.1 the PP/ST author should specify the minimum number and type of security attributes that the function will use in the specification of the rules. For example, such attributes may be things such as subject identifier, subject sensitivity level, subject clearance level, information sensitivity level, etc. The minimum number of each type of security attribute should be sufficient to support the environmental needs.
In FDP_IFF.2.1 the PP/ST author should specify the minimum number and type of security attributes that the function will use in the specification of the rules. For example, such attributes may be things such as subject identifier, subject sensitivity level, subject clearance level, information sensitivity level, etc. The minimum number of each type of security attribute should be sufficient to support the environmental needs.
In FDP_IFF.2.2 the PP/ST author should specify for each operation, the security attribute-based relationship that must hold between subject and information security attributes that the TSF will enforce. These relationships should be based upon the ordering relationships between the security attributes.
In FDP_IFF.2.3 the PP/ST author should specify any additional information flow control SFP rules that the TSF is to enforce. If there are no additional rules then the PP/ST author should specify "none".
In FDP_IFF.2.4 the PP/ST author should specify any additional SFP capabilities that the TSF is to enforce. If there are no additional rules then the PP/ST author should specify "none".
In FDP_IFF.2.5, the PP/ST author should specify the rules, based on security attributes, that explicitly authorise information flows. These rules are in addition to those specified in the preceding elements. They are included in FDP_IFF.2.5 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that always grants the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify "none".
In FDP_IFF.2.6, the PP/ST author should specify the rules, based on security attributes, that explicitly deny information flows. These rules are in addition to those specified in the preceding elements. They are included in FDP_IFF.2.6 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that always denies the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify "none".