FDP_IFF.1 Simple security attributes
User application notes
This component requires security attributes on information, and on subjects that cause that information to flow and subjects that act as recipients of that information. The attributes of the containers of the information should also be considered if it is desired that they should play a part in information flow control decisions or if they are covered by an access control policy. This component specifies the key rules that are enforced, and describes how security attributes are derived. For example, this component 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], but these security attributes do not form a hierarchy.
This component does not specify the details of how a security attribute is assigned (i.e. user versus process). Flexibility in policy is provided by having assignments that allow specification of additional policy and function requirements, as necessary.
This component also provides requirements for the information flow control functions to be able to explicitly authorise and deny an information flow based upon security attributes. This could be used to implement a privilege policy that covers exceptions to the basic policy defined in this component.
Operations
Assignment:
In FDP_IFF.1.1, the PP/ST author should specify the information flow control SFPs enforced by the TSF. The name of the information flow control SFP, and the scope of control for that policy are defined in components from FDP_IFC.
In FDP_IFF.1.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.1.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.
In FDP_IFF.1.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.1.4 the PP/ST author should specify any additional SFP capabilities that the TSF is to provide. If there are no additional capabilities then the PP/ST author should specify "none".
In FDP_IFF.1.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.1.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.1.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.1.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".