Annex F
(informative)

User data protection (FDP)

This class contains families specifying requirements for TOE security functions and TOE security function policies related to protecting user data. This class differs from FIA and FPT in that FDP specifies components to protect user data, FIA specifies components to protect attributes associated with the user, and FPT specifies components to protect TSF information.

The class does not contain explicit requirements for traditional Mandatory Access Controls (MAC) or traditional Discretionary Access Controls (DAC); however, such requirements may be constructed using components from this class.

FDP does not explicitly deal with confidentiality, integrity, or availability, as all three are most often intertwined in the policy and mechanisms. However, the TOE security policy must adequately cover these three objectives in the PP/ST.

A final aspect of this class is that it specifies access control in terms of "operations". An operation is defined as a specific type of access on a specific object. It depends on the level of abstraction of the PP/ST author whether these operations are described as "read" and/or "write" operations, or as more complex operations such as "update the database".

The access control policies are policies that control access to the information container. The attributes represent attributes of the container. Once the information is out of the container, the accessor is free to modify that information, including writing the information into a different container with different attributes. By contrast, an information flow policies controls access to the information, independent of the 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 moves. The accessor does not have the ability, in the absence of an explicit authorisation, to change the attributes of the information.

This class is not meant to be a complete taxonomy of IT access policies, as others can be imagined. Those policies included here are simply those for which current experience with actual systems provides a basis for specifying requirements. There may be other forms of intent that are not captured in the definitions here.

For example, one could imagine a goal of having user-imposed (and user-defined) controls on information flow (e.g. an automated implementation of the NO FOREIGN handling caveat). Such concepts could be handled as refinements of, or extensions to the FDP components.

Finally, it is important when looking at the components in FDP to remember that these components are requirements for functions that may be implemented by a mechanism that also serves or could serve another purpose. For example, it is possible to build an access control policy ( FDP_ACC) that uses labels ( FDP_IFF.1) as the basis of the access control mechanism.

A TOE security policy may encompass many security function policies (SFPs), each to be identified by the two policy oriented components FDP_ACC, and FDP_IFC. These policies will typically take confidentiality, integrity, and availability aspects into consideration as required, to satisfy the TOE requirements. Care should be taken to ensure that all objects are covered by at least one SFP and that there are no conflicts arising from implementing the multiple SFPs.

Figures F.1 and F.2 show the decomposition of this class into its constituent components.

    


Figure F.1 - User data protection class decomposition

    


Figure F.2 - User data protection class decomposition (cont.)

 

When building a PP/ST using components from the FDP class, the following information provides guidance on where to look and what to select from the class.

The requirements in the FDP class are defined in terms of a security function (abbreviated SF) that will implement a SFP. Since a TOE may implement multiple SFPs simultaneously, the PP/ST author must specify the name for each SFP, so it can be referenced in other families. This name will then be used in each component selected to indicate that it is being used as part of the definition of requirements for that function. This allows the author to easily indicate the scope for operations such as objects covered, operations covered, authorised users, etc.

Each instantiation of a component can apply to only one SFP. Therefore if an SFP is specified in a component then this SFP will apply to all the elements in this component. The components may be instantiated multiple times within a PP/ST to account for different policies if so desired.

The key to selecting components from this family is to have a well defined TOE security policy to enable proper selection of the components from the two policy components; FDP_ACC and FDP_IFC. In FDP_ACC and FDP_IFC respectively, all access control policies and all information flow control policies are named. Furthermore the scope of control of these components in terms of the subjects, objects and operations covered by this security function. The names of these policies 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 "access control SFP" or an "information flow control SFP". The rules that define the functionality of the named access control and information flow control SFPs will be defined in the FDP_ACF and FDP_IFF families (respectively).

The following steps are guidance on how this class is applied in the construction of a PP/ST:

a)    Identify the policies to be enforced from the FDP_ACC, and FDP_IFC families. These families define scope of control for the policy, granularity of control and may identify some rules to go with the policy.

b)    Identify the components and perform any applicable operations in the policy components. The assignment operations may be performed generally (such as with a statement "All files") or specifically ("The files "A", "B", etc.) depending upon the level of detail known.

c)    Identify any applicable function components from the FDP_ACF and FDP_IFF families to address the named policy families from FDP_ACC and FDP_IFC. Perform the operations to make the components define the rules to be enforced by the named policies. This should make the components fit the requirements of the selected function envisioned or to be built.

d)    Identify who will have the ability to control and change security attributes under the function, such as only a security administrator, only the owner of the object, etc. Select the appropriate components from Class FMT Security management and perform the operations. Refinements may be useful here to identify missing features, such as that some or all changes must be done via trusted path.

e)    Identify any appropriate components from the Class FMT Security management for initial values for new objects and subjects.

f)    Identify any applicable rollback components from the FDP_ROL family.

g)    Identify any applicable residual information protection requirements from the FDP_RIP family.

h)    Identify any applicable import or export components, and how security attributes should be handled during import and export, from the FDP_ITC and FDP_ETC families.

i)    Identify any applicable internal TOE communication components from the FDP_ITT family.

j)    Identify any requirements for integrity protection of stored information from the FDP_SDI family.

k)    Identify any applicable inter-TSF communication components from the FDP_UCT or FDP_UIT families.