This family covers the identification of information flow control SFPs; and, for each, specifies the scope of control of the SFP.
Examples of security policies that might satisfy this objective are:
- Bell and La Padula Security model [B&L];
- Biba Integrity model [Biba];
- Non-Interference [Gogu1,Gogu2].
User notes
The components in this family are capable of identifying the information flow control SFPs to be enforced by the traditional Mandatory Access Control mechanisms that would be found in a TOE. However, they go beyond just the traditional MAC mechanisms and can be used to identify and describe non-interference policies and state-transitions. It further defines the subjects under control of the policy, the information under control of the policy, and operations which cause controlled information to flow to and from controlled subjects for each information flow control SFP in the TOE. The functionality that defines the rules of an information flow control SFP will be defined by other families such as FDP_IFF and FDP_RIP. The access control SFPs named here in FDP_IFC are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an "information flow control SFP."
These components are quite flexible. They allow the domain of flow control to be specified and there is no requirement that the mechanism be based upon labels. The different elements of the information flow control components also permit different degrees of exception to the policy.
Each SFP covers a set of triplets: subject, information, and operations that cause information to flow to and from subjects. Some information flow control policies may be at a very low level of detail and explicitly describe subjects in terms of processes within an operating system. Other information flow control policies may be at a high level and describe subjects in the generic sense of users or input/output channels. If the information flow control policy is at too high a level of detail, it may not clearly define the desired IT security functions. In such cases, it is more appropriate to include such descriptions of information flow control policies as objectives. Then the desired IT security functions can be specified as supportive of those objectives.
In the second component (FDP_IFC.2 Complete information flow control), each information flow control SFP will cover all possible operations that cause information covered by that SFP to flow to and from subjects covered by that SFP. Furthermore, all information flows will need to be covered by a SFP. Therefore for each action that causes information to flow, there will be a set of rules that define whether the action is allowed. If there are multiple SFPs that are applicable for a given information flow, all involved SFPs must allow this flow before it is permitted to take place.
An information flow control SFP covers a well-defined set of operations. The SFPs coverage may be "complete" with respect to some information flows, or it may address only some of the operations that affect the information flow.
An access control SFP controls access to the objects that contain information. An information flow control SFP controls access to the information, independent of its container. The attributes of the information, which may be associated with the attributes of the container (or may not, as in the case of a multi-level database) stay with the information as it flows. The accessor does not have the ability, in the absence of an explicit authorisation, to change the attributes of the information.
Information flows and operations can be expressed at multiple levels. In the case of a ST, the information flows and operations might be specified at a system-specific level: TCP/IP packets flowing through a firewall based upon known IP addresses. For a PP, the information flows and operations might be expressed as types: email, data repositories, observe accesses, etc.
The components in this family can be applied multiple times in a PP/ST to different subsets of operations and objects. This will accommodate TOEs that contain multiple policies, each addressing a particular set of objects, subjects, and operations.