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.
This family is based upon the concept of arbitrary controls on the interaction of subjects and objects. The scope and purpose of the controls is based upon the attributes of the accessor (subject), the attributes of the container being accessed (object), the actions (operations) and any associated access control rules.
User notes
The components in this family are capable of identifying the access control SFPs (by name) to be enforced by the traditional Discretionary Access Control (DAC) mechanisms. It further defines the subjects, objects and operations that are covered by identified access control SFPs. The rules that define the functionality of an access control SFP will be defined by other families, such as FDP_ACF and FDP_RIP. The names of the access control SFPs defined in FDP_ACC 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."
The access control SFP covers a set of triplets: subject, object, and operations. Therefore a subject can be covered by multiple access control SFPs but only with respect to a different operation or a different object. Of course the same applies to objects and operations.
A critical aspect of an access control function that enforces an access control SFP is the ability for users to modify the attributes involved in access control decisions. The FDP_ACC family does not address these aspects. Some of these requirements are left undefined, but can be added as refinements, while others are covered elsewhere in other families and classes such as FMT Class FMT: Security management.
There are no audit requirements in FDP_ACC as this family specifies access control SFP requirements. Audit requirements will be found in families specifying functions to satisfy the access control SFPs identified in this family.
This family provides a PP/ST author the capability to specify several policies, for example, a fixed access control SFP to be applied to one scope of control, and a flexible access control SFP to be defined for a different scope of control. To specify more than one access control policy, the components from this family can be iterated 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 operations and objects. In other words, the PP/ST author should specify the required information in the ACC component for each of the access control SFPs that the TSF will enforce. For example, a TOE incorporating three access control SFPs, each covering only a subset of the objects, subjects, and operations within the TOE, will contain one FDP_ACC.1 Subset access control component for each of the three access control SFPs, necessitating a total of three FDP_ACC.1 components.
FDP_ACC.1 Subset access control
User application notes
The terms object and subject refer to generic elements in the TOE. For a policy to be implementable, the entities must be clearly identified. For a PP, the objects and operations might be expressed as types such as: named objects, data repositories, observe accesses, etc. For a specific system these generic terms (subject, object) must be refined, e.g. files, registers, ports, daemons, open calls, etc.
This component specifies that the policy cover some well-defined set of operations on some subset of the objects. It places no constraints on any operations outside the set - including operations on objects for which other operations are controlled.
Operations
Assignment:
In FDP_ACC.1.1, the PP/ST author should specify a uniquely named access control SFP to be enforced by the TSF.
In FDP_ACC.1.1, the PP/ST author should specify the list of subjects, objects, and operations among subjects and objects covered by the SFP.
FDP_ACC.2 Complete access control
User application notes
This component requires that all possible operations on objects, that are included in the SFP, are covered by an access control SFP.
The PP/ST author must demonstrate that each combination of objects and subjects is covered by an access control SFP.
Operations
Assignment:
In FDP_ACC.2.1, the PP/ST author should specify a uniquely named access control SFP to be enforced by the TSF.
In FDP_ACC.2.1, the PP/ST author should specify the list of subjects and objects covered by the SFP. All operations among those subjects and objects will be covered by the SFP.
This family describes the rules for the specific functions that can implement an access control policy named in FDP_ACC which also specifies the scope of control of the policy.
User notes
This family provides a PP/ST author the capability to describe the rules for access control. This results in a system where the access to objects will not change. An example of such an object is "Message of the Day", which is readable by all, and changeable only by the authorised administrator. This family also provides the PP/ST author with the ability to describe rules that provide for exceptions to the general access control rules. Such exceptions would either explicitly allow or deny authorisation to access an object.
There are no explicit components to specify other possible functions such as two-person control, sequence rules for operations, or exclusion controls. However, these mechanisms, as well as traditional DAC mechanisms, can be represented with the existing components, by careful drafting of the access control rules.
A variety of acceptable access control SFs may be specified in this family such as:
- Access control lists (ACLs)
- Time-based access control specifications
- Origin-based access control specifications
- Owner-controlled access control attributes
FDP_ACF.1 Security attribute based access control
User application notes
This component provides requirements for a mechanism that mediates access control based on security attributes associated with subjects and objects. Each object and subject has a set of associated attributes, such as location, time of creation, access rights (e.g., Access Control Lists (ACLs)). This component allows the PP/ST author to specify the attributes that will be used for the access control mediation. This component allows access control rules, using these attributes, to be specified.
Examples of the attributes that a PP/ST author might assign are presented in the following paragraphs.
An identity attribute may be associated with users, subjects, or objects to be used for mediation. Examples of such attributes might be the name of the program image used in the creation of the subject, or a security attribute assigned to the program image.
A time attribute can be used to specify that access will be authorised during certain times of the day, during certain days of the week, or during a certain calendar year.
A location attribute could specify whether the location is the location of the request for the operation, the location where the operation will be carried out, or both. It could be based upon internal tables to translate the logical interfaces of the TSF into locations such as through terminal locations, CPU locations, etc.
A grouping attribute allows a single group of users to be associated with an operation for the purposes of access control. If required, the refinement operation should be used to specify the maximum number of definable groups, the maximum membership of a group, and the maximum number of groups to which a user can concurrently be associated.
This component also provides requirements for the access control security functions to be able to explicitly authorise or deny access to an object based upon security attributes. This could be used to provide privilege, access rights, or access authorisations within the TOE. Such privileges, rights, or authorisations could apply to users, subjects (representing users or applications), and objects.
Operations
Assignment:
In FDP_ACF.1.1, the PP/ST author should specify an access control SFP name that the TSF is to enforce. The name of the access control SFP, and the scope of control for that policy are defined in components from FDP_ACC.
In FDP_ACF.1.1, the PP/ST author should specify the security attributes and/or named groups of security attributes that the function will use in the specification of the rules. For example, such attributes may be things such as the user identity, subject identity, role, time of day, location, ACLs, or any other attribute specified by the PP/ST author. Named groups of security attributes can be specified to provide a convenient means to refer to multiple security attributes. Named groups could provide a useful way to associate "roles" defined in FMT_SMR Security management roles, and all of their relevant attributes, with subjects. In other words, each role could relate to a named group of attributes.
In FDP_ACF.1.2, the PP/ST author should specify the SFP rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects. These rules specify when access is granted or denied. It can specify general access control functions (e.g. typical permission bits) or granular access control functions (e.g. ACLs).
In FDP_ACF.1.3, the PP/ST author should specify the rules, based on security attributes, that explicitly authorise access of subjects to objects that will be used to explicitly authorise access. These rules are in addition to those specified in FDP_ACF.1.1. They are included in FDP_ACF.1.3 as they are intended to contain exceptions to the rules in FDP_ACF.1.1. An example of rules to explicitly authorise access is based on a privilege vector associated with a subject that always grants access to objects covered by the access control SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify "none".
In FDP_ACF.1.4, the PP/ST author should specify the rules, based on security attributes, that explicitly deny access of subjects to objects. These rules are in addition to those specified in FDP_ACF.1.1. They are included in FDP_ACF.1.4 as they are intended to contain exceptions to the rules in FDP_ACF.1.1. An example of rules to explicitly deny access is based on a privilege vector associated with a subject that always denies access to objects covered by the access control SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify "none".
This family describes specific functions that can be used to authenticate `static' data.
User notes
Components in this family are to be used when there is a requirement for `static' data authentication, i.e. where data is to be signed but not transmitted. (Note that the FCO_NRO family provides for non-repudiation of origin of information received during a data exchange.)
FDP_DAU.1 Basic data authentication
User application notes
This component may be satisfied by one-way hash functions (cryptographic checksum, fingerprint, message digest), to generate a hash value for a definitive document that may be used as verification of the validity or authenticity of its information content.
Operations
Assignment:
In FDP_DAU.1.1, the PP/ST author should specify the list of objects or information types for which the TSF shall be capable of generating data authentication evidence.
In FDP_DAU.1.2, the PP/ST author should specify the list of subjects that will have the ability to verify data authentication evidence for the objects identified in the previous element. The list of subjects could be very specific, if the subjects are known, or it could be more generic and refer to a "type" of subject such as an identified role.
FDP_DAU.2 Data authentication with identity of guarantor
User application notes
This component additionally requires the ability to verify the identity of the user that provided the guarantee of authenticity (e.g. a trusted third party).
Operations
Assignment:
In FDP_DAU.2.1, the PP/ST author should specify the list of objects or information types for which the TSF shall be capable of generating data authentication evidence.
In FDP_DAU.2.2, the PP/ST author should specify the list of subjects that will have the ability to verify data authentication evidence for the objects identified in the previous element as well as the identity of the user that created the data authentication evidence.
This family defines functions for exporting user data from the TOE such that its security attributes either can be explicitly preserved or can be ignored once it has been exported. Consistency of these security attributes are addressed by FPT_TDC Inter-TSF TSF data consistency .
FDP_ETC is concerned with limitations on export and association of security attributes with the exported user data.
User notes
This family, and the corresponding Import family FDP_ITC, address how the TOE deals with user data transferred into and outside its control. In principle this family is concerned with the export of user data and its related security attributes.
A variety of activities might be involved here:
a) exporting of user data without any security attributes;
b) exporting user data including security attributes where the two are associated with one another and the security attributes unambiguously represent the exported user data.
If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate these components once for each named SFP.
FDP_ETC.1 Export of user data without security attributes
User application notes
This component is used to specify the export of user data without the export of its security attributes.
Operations
Assignment:
In FDP_ETC.1.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when exporting user data. The user data that this function exports is scoped by the assignment of these SFPs.
FDP_ETC.2 Export of user data with security attributes
User application notes
The user data is exported together with its security attributes. The security attributes are unambiguously associated with the user data. There are several ways of achieving this association. One way that this can be achieved is by physically collocating the user data and the security attributes (e.g. the same floppy), or by using cryptographic techniques such as secure signatures to associate the attributes and the user data. FTP_ITC Inter-TSF trusted channel could be used to assure that the attributes are correctly received at the other Trusted IT Product while FPT_TDC Inter-TSF TSF data consistency can be used to make sure that those attributes are properly interpreted. Furthermore, FTP_TRP Trusted path could be used to make sure that the export is being initiated by the proper user.
Operations
Assignment:
In FDP_ETC.2.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when exporting user data. The user data that this function exports is scoped by the assignment of these SFPs.
In FDP_ETC.2.4, the PP/ST author should specify any additional exportation control rules or "none" if there are no additional exportation control rules. These rules will be enforced by the TSF in addition to the access control SFPs and/or information flow control SFPs selected in FDP_ETC.2.1.
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.
FDP_IFC.1 Subset information flow control
User application notes
This component requires that an information flow control policy apply to a subset of the possible operations in the TOE.
Operations
Assignment:
In FDP_IFC.1.1, the PP/ST author should specify a uniquely named information flow control SFP to be enforced by the TSF.
In FDP_IFC.1.1, the PP/ST author should specify the list of subjects, information, and operations which cause controlled information to flow to and from controlled subjects covered by the SFP. As mentioned above, the list of subjects could be at various levels of detail depending on the needs of the PP/ST author. It could specify users, machines, or processes for example. Information could refer to data such as email or network protocols, or more specific objects similar to those specified under an access control policy. If the information that is specified is contained within an object that is subject to an access control policy, then both the access control policy and information flow control policy must be enforced before the specified information could flow to or from the object.
FDP_IFC.2 Complete information flow control
User application notes
This component requires that all possible operations that cause information to flow to and from subjects included in the SFP, are covered by an information flow control SFP.
The PP/ST author must demonstrate that each combination of information flows and subjects is covered by an information flow control SFP.
Operations
Assignment:
In FDP_IFC.2.1, the PP/ST author should specify a uniquely named information flow control SFP to be enforced by the TSF.
In FDP_IFC.2.1, the PP/ST author should specify the list of subjects and information that will be covered by the SFP. All operations that cause that information to flow to and from subjects will be covered by the SFP. As mentioned above, the list of subjects could be at various levels of detail depending on the needs of the PP/ST author. It could specify users, machines, or processes for example. Information could refer to data such as email or network protocols, or more specific objects similar to those specified under an access control policy. If the information that is specified is contained within an object that is subject to an access control policy, then both the access control policy and information flow control policy must be enforced before the specified information could flow to or from the object.
This family describes the rules for the specific functions that can implement the information flow control SFPs named in FDP_IFC, which also specifies the scope of control of the policies. It consists of two "trees:" one addressing the common information flow control function issues, and a second addressing illicit information flows (i.e. covert channels) with respect to one or more information flow control SFPs. This division arises because the issues concerning illicit information flows are, in some sense, orthogonal to the rest of an SFP. Illicit information flows are flows in violation of policy; thus they are not a policy issue.
User notes
In order to implement strong protection against disclosure or modification in the face of untrusted software, controls on information flow are required. Access controls alone are not sufficient because they only control access to containers, allowing the information they contain to flow, without controls, throughout a system.
In this family, the phrase "types of illicit information flows" is used. This phrase may be used to refer to the categorisation of flows as "Storage Channels" or "Timing Channels", or it can refer to improved categorisations reflective of the needs of a PP/ST author.
The flexibility of these components allows the definition of a privilege policy within FDP_IFF.1 and FDP_IFF.2 to allow the controlled bypass of all or part of a particular SFP. If there is a need for a predefined approach to SFP bypass, the PP/ ST author should consider incorporating a privilege policy.
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".
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".
FDP_IFF.3 Limited illicit information flows
User application notes
This component should be used when at least one of the SFPs that requires control of illicit information flows does not require elimination of flows.
For the specified illicit information flows, certain maximum capacities should be provided. In addition a PP/ST author has the ability to specify whether the illicit information flows must be audited.
Operations
Assignment:
In FDP_IFF.3.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.3.1 the PP/ST author should specify the types of illicit information flows that are subject to a maximum capacity limitation.
In FDP_IFF.3.1 the PP/ST author should specify the maximum capacity permitted for any identified illicit information flows.
FDP_IFF.4 Partial elimination of illicit information flows
User application notes
This component should be used when all the SFPs that requires control of illicit information flows require elimination of some (but not necessarily all) illicit information flows.
Operations
Assignment:
In FDP_IFF.4.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.4.1 the PP/ST author should specify the types of illicit information flows which are subject to a maximum capacity limitation.
In FDP_IFF.4.1 the PP/ST author should specify the maximum capacity permitted for any identified illicit information flows.
In FDP_IFF.4.2 the PP/ST author should specify the types of illicit information flows to be eliminated. This list may not be empty as this component requires that some illicit information flows are to be eliminated.
FDP_IFF.5 No illicit information flows
User application notes
This component should be used when the SFPs that require control of illicit information flows require elimination of all illicit information flows. However, the PP/ST author should carefully consider the potential impact that eliminating all illicit information flows might have on the normal functional operation of the TOE. Many practical applications have shown that there is an indirect relationship between illicit information flows and normal functionality within a TOE and eliminating all illicit information flows may result in less than desired functionality.
Operations
Assignment:
In FDP_IFF.5.1 the PP/ST author should specify the information flow control SFP for which illicit information flows are to be eliminated. The name of the information flow control SFP, and the scope of control for that policy are defined in components from FDP_IFC.
FDP_IFF.6 Illicit Information Flow Monitoring
User application notes
This component should be used when it is desired that the TSF provide the ability to monitor the use of illicit information flows that exceed a specified capacity. If it is desired that such flows be audited, then this component could serve as the source of audit events to be used by components from the FAU_GEN Security audit data generation family.
Operations
Assignment:
In FDP_IFF.6.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.6.1 the PP/ST author should specify the types of illicit information flows that will be monitored for exceeding a maximum capacity.
In FDP_IFF.6.1 the PP/ST author should specify the maximum capacity above which illicit information flows will be monitored by the TSF.
This family defines mechanisms for importing user data from outside the TSC into the TOE such that the user data security attributes can be preserved. Consistency of these security attributes are addressed by FPT_TDC Inter-TSF TSF data consistency .
FDP_ITC is concerned with limitations on import, user specification of security attributes, and association of security attributes with the user data.
User notes
This family, and the corresponding export family FDP_ETC, address how the TOE deals with user data outside its control. This family is concerned with assigning and abstraction of the user data security attributes.
A variety of activities might be involved here:
a) importing user data from an unformatted medium (e.g. floppy disk, tape, scanner, video or audit signal), without including any security attributes, and physically marking the medium to indicate its contents;
b) importing user data, including security attributes, from a medium and verifying that the object security attributes are appropriate;
c) importing user data, including security attributes, from a medium using a cryptographic sealing technique to protect the association of user data and security attributes.
This family is not concerned with the determination of whether the user data may be imported. It is concerned with the values of the security attributes to associate with the imported user data.
There are two possibilities for the import of user data: either the user data is unambiguously associated with reliable object security attributes (values and meaning of the security attributes is not modified), or no reliable security attributes (or no security attributes at all) are available from the import source. This family addresses both cases.
If there are reliable security attributes available, they may have been associated with the user data by physical means (the security attributes are on the same media), or by logical means (the security attributes are distributed differently, but include unique object identification, e.g. cryptographic checksum).
This family is concerned with importing user data and maintaining the association of security attributes as required by the SFP. Other families are concerned with other import aspects such as consistency, trusted channels, and integrity that are beyond the scope of this family. Furthermore, FDP_ITC is only concerned with the interface to the import medium. FDP_ETC is responsible for the other end point of the medium (the source).
Some of the well known import requirements are:
a) importing of user data without any security attributes;
b) importing of user data including security attributes where the two are associated with one another and the security attributes unambiguously represent the information being imported.
These import requirements may be handled by the TSF with or without human intervention, depending on the IT limitations and the organisational security policy. For example, if user data is received on a "confidential" channel, the security attributes of the objects will be set to "confidential".
If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate these components once for each named SFP.
FDP_ITC.1 Import of User Data Without Security Attributes
User application notes
This component is used to specify the import of user data that does not have reliable (or any) security attributes associated with it. This function requires that the security attributes for the imported user data be initialised within the TSF. It could also be the case that the PP/ST author specifies the rules for import. It may be appropriate, in some environments, to require that these attributes be supplied via a Trusted Path or a Trusted Channel mechanism.
Operations
Assignment:
In FDP_ITC.1.1, the PP/ST author should specify the access control SFP and/or information flow control SFP that will be enforced when importing user data from outside of the TSC. The user data that this function imports is scoped by the assignment of these SFPs.
In FDP_ITC.1.3, the PP/ST author should specify any additional importation control rules or "none" if there are no additional importation control rules. These rules will be enforced by the TSF in addition to the access control SFPs and/or information flow control SFPs selected in FDP_ITC.1.1.
FDP_ITC.2 Import of User Data with Security Attributes
User application notes
This component is used to specify the import of user data that has reliable security attributes associated with it. This function relies upon the security attributes that are accurately and unambiguously associated with the objects on the import medium. Once imported, those objects will have those same attributes. This requires FPT_TDC to ensure the consistency of the data. It could also be the case that the PP/ST author specifies the rules for import.
Operations
Assignment:
In FDP_ITC.2.1, the PP/ST author should specify the access control SFP and/or information flow control SFP that will be enforced when importing user data from outside of the TSC. The user data that this function imports is scoped by the assignment of these SFPs
In FDP_ITC.2.5, the PP/ST author should specify any additional importation control rules or "none" if there are no additional importation control rules. These rules will be enforced by the TSF in addition to the access control SFPs and/or information flow control SFPs selected in FDP_ITC.2.1.
This family provides requirements that address protection of user data when it is transferred between parts of a TOE across an internal channel. This may be contrasted with the FDP_UCT and FDP_UIT family, which provide protection for user data when it is transferred between distinct TSFs across an external channel, and FDP_ETC and FDP_ITC, which address transfer of data to or from outside the TSF's Control.
User notes
The requirements in this family allow a PP/ST author to specify the desired security for user data while in transit within the TOE. This security could be protection against disclosure, modification, or loss of availability.
The determination of the degree of physical separation above which this family should apply depends on the intended environment of use. In a hostile environment, there may be risks arising from transfers between parts of the TOE separated by only a system bus. In more benign environments, the transfers may be across more traditional network media.
If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate these components once for each named SFP.
FDP_ITT.1 Basic internal transfer protection
Operations
Assignment:
In FDP_ITT.1.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred.
Selection:
In FDP_ITT.1.1 the PP/ST author should specify the types of transmission errors that the TSF should prevent occuring for user data while in transport. The options are disclosure, modification, loss of use.
FDP_ITT.2 Transmission separation by attribute
User application notes
This component could, for example, be used to provide different forms of protection to information with different clearance levels.
One of the ways to achieve separation of data when it is transmitted is through the use of separate logical or physical channels.
Operations
Assignment:
In FDP_ITT.2.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred.
Selection:
In FDP_ITT.2.1 the PP/ST author should specify the types of transmission errors that the TSF should prevent occuring for user data while in transport. The options are disclosure, modification, loss of use.
Assignment:
In FDP_ITT.2.2, the PP/ST author should specify the security attributes, the values of which the TSF will use to determine when to separate data that is being trasmitted between physically-separated parts of the TOE. An example is that user data associated with the identity of one owner is transmitted separately from the user data associated with the identify of a different owner. In this case, the value of the identity of the owner of the data is what is used to determine when to separate the data for transmission.
FDP_ITT.3 Integrity monitoring
User application notes
This component is used in combination with either FDP_ITT.1 or FDP_ITT.2. It ensures that the TSF checks received user data (and their attributes) for integrity. FDP_ITT.1 or FDP_ITT.2 will provide the data in a manner such that it is protected from modification (so that FDP_ITT.3 can detect any modifications).
The PP/ST author has to specify the types of errors that must be detected. The PP/ST author should consider: modification of data, substitution of data, unrecoverable ordering change of data, replay of data, incomplete data, in addition to other integrity errors.
The PP/ST author must specify the actions that the TSF should take on detection of a failure. For example: ignore the user data, request the data again, inform the authorised administrator, reroute traffic for other lines.
Operations
Assignment:
In FDP_ITT.3.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred and monitored for integrity errors.
In FDP_ITT.3.1, the PP/ST author should specify the type of possible integrity errors to be monitored during transmission of the user data.
In FDP_ITT.3.2, the PP/ST author should specify the action to be taken by the TSF when an integrity error is encountered. An example might be that the TSF should request the resubmission of the user data. The SFP(s) specified in FDP_ITT.3.1 will be enforced as the actions are taken by the TSF.
FDP_ITT.4 Attribute-based integrity monitoring
This component is used in combination with FDP_ITT.2. It ensures that the TSF checks received user data, that has been transmitted by separate channels (based on values of specified security attributes), for integrity. It allows the PP/ST author to specify actions to be taken upon detection of an integrity error.
For example, this component could be used to provide different integrity error detection and action for information at different integrity levels.
The PP/ST author has to specify the types of errors that must be detected. The PP/ST author should consider: modification of data, substitution of data, unrecoverable ordering change of data, replay of data, incomplete data, in addition to other integrity errors.
The PP/ST author should specify the attributes (and associated transmission channels) that necessitate integrity error monitoring
The PP/ST author must specify the actions that the TSF should take on detection of a failure. For example: ignore the user data, request the data again, inform the authorised administrator, reroute traffic for other lines.
Operations
Assignment:
In FDP_ITT.4.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred and monitored for integrity errors.
In FDP_ITT.4.1, the PP/ST author should specify the type of possible integrity errors to be monitored during transmission of the user data.
In FDP_ITT.4.1, the PP/ST author should specify a list of security attributes that require separate transmission channels. This list is used to determine which user data to monitor for integrity errors., based on its security attributes and its transmission channel. This element is directly related to FDP_ITT.2 Transmission separation by attribute./p>
In FDP_ITT.4.2, the PP/ST author should specify the action to be taken by the TSF when an integrity error is encountered. An example might be that the TSF should request the resubmission of the user data. The SFP(s) specified in FDP_ITT.3.1 will be enforced as the actions are taken by the TSF.
This family addresses the need to ensure that deleted information is no longer accessible, and that newly-created objects do not contain information from previously used objects within the TOE. This family does not address objects stored off-line.
User notes
This family requires protection for information that has been logically deleted or released (not available to the user but still within the system and may be recoverable). In particular, this includes information that is contained in an object, as part of the TSF reusable resources, where destruction of the object does not necessarily equate to destruction of the resource or any contents of the resource.
It also applies to resources that are serially reused by different subjects within the system. For example, most operating systems typically rely upon hardware registers (resources) to support processes within the system. As processes are swapped from a "run" state to a "sleep" state (and vice versa), these registers are serially reused by different subjects. While this "swapping" action may not be considered an allocation or deallocation of a resource, FDP_RIP could apply to such events and resources.
FDP_RIP typically controls access to information that is not part of any currently defined or accessible object; however, in certain cases this may not be true. For example, object "A" is a file and object "B" is the disk upon which that file resides. If object "A" is deleted, the information from object "A" is under the control of FDP_RIP even though it is still part of object "B".
It is important to note that FDP_RIP applies only to on-line objects and not off-line objects such as those backed-up on tapes. For example, if a file is deleted in the TOE, FDP_RIP can be instantiated to require that no residual information exists upon deallocation; however, the TSF cannot extend this enforcement to that same file that exists on the off-line back-up. Therefore that same file is still available. If this is a concern, then the PP/ST author should make sure that the proper environmental objectives are in place to support administrative guidance to address off-line objects.
FDP_RIP and FDP_ROL can conflict when FDP_RIP is instantiated to require that residual information be cleared at the time the application releases the object to the TSF (i.e. upon deallocation). Therefore, the FDP_RIP selection of "deallocation" should not be used with FDP_ROL since there would be no information to roll back. The other selection, "unavailability upon allocation", may be used with FDP_ROL, but there is the risk that the resource which held the information has been allocated to a new object before the roll back took place. If that were to occur, then the roll back would not be possible.
There are no audit requirements in FDP_RIP because this is not a user-invokable function. Auditing of allocated or deallocated resources would be auditable as part of the access control SFP or the information flow control SFP operations.
This family should apply to the objects specified in the access control SFP(s) or the information flow control SFP(s) as specified by the PP/ST author.
FDP_RIP.1 Subset residual information protection
User application notes
This component requires that, for a subset of the objects in the TOE, the TSF will ensure that there is no available residual information contained in a resource allocated to those objects or deallocated from those objects.
Operations
Selection:
In FDP_RIP.1.1, the PP/ST author should specify the event, allocation of the resource to or deallocation of the resource from, that invokes the residual information protection function.
Assignment:
In FDP_RIP.1.1, the PP/ST author should specify the list of objects subject to residual information protection.
FDP_RIP.2 Full residual information protection
User application notes
This component requires that for all objects in the TOE, the TSF will ensure that there is no available residual information contained in a resource allocated to those objects or deallocated from those objects.
Operations
Selection:
In FDP_RIP.2.1, the PP/ST author should specify the event, allocation of the resource to or deallocation of the resource from, that invokes the residual information protection function.
This family addresses the need to return to a well defined valid state, such as the need of a user to undo modifications to a file or to undo transactions in case of an incomplete series of transaction as in the case of databases.
This family is intended to assist a user in returning to a well defined valid state after the user undoes the last set of actions, or, in distributed databases, the return of all of the distributed copies of the databases to the state before an operation failed.
FDP_RIP and FDP_ROL conflict when FDP_RIP enforces that the contents will be made unavailable at the time that a resource is deallocated from an object. Therefore, this use of FDP_RIP cannot be combined with FDP_ROL as there would be no information to roll back. FDP_RIP can be used only with FDP_ROL when it enforces that the contents will be unavailable at the time that a resource is allocated to an object. This is because the FDP_ROL mechanism will have an opportunity to access the previous information that may still be present in the TOE in order to successfully roll back the operation.
The rollback requirement is bounded by certain limits. For example a text editor typically only allows you roll back up to a certain number of commands. Another example would be backups. If backup tapes are rotated, after a tape is reused, the information can no longer be retrieved. This also poses a bound on the rollback requirement.
User application notes
This component allows a user or subject to undo a set of operations on a predefined set of objects. The undo is only possible within certain limits, for example up to a number of characters or up to a time limit.
Operations
Assignment:
In FDP_ROL.1.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when performing rollback operations. This is necessary to make sure that roll back is not used to circumvent the specified SFPs.
In FDP_ROL.1.1 the PP/ST author should specify the list of operations that can be rolled back.
In FDP_ROL.1.1 the PP/ST author should specify the list of objects that are subjected to the rollback policy.
In FDP_ROL.1.2 the PP/ST author should specify the boundary limit to which rollback operations may be performed. The boundary may be specified as a predefined period of time, for example, operations may be undone which were performed within the past two minutes. Other possible boundaries may be defined as the maximum number of operations allowable or the size of a buffer.
User application notes
This component enforces that the TSF provide the capability to rollback all operations; however, the user can choose to rollback only a part of them.
Operations
Assignment:
In FDP_ROL.2.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when performing rollback operations. This is necessary to make sure that roll back is not used to circumvent the specified SFPs.
In FDP_ROL.2.1 the PP/ST author should specify the list of objects that are subjected to the rollback policy.
In FDP_ROL.1.2 the PP/ST author should specify the boundary limit to which rollback operations may be performed. The boundary may be specified as a predefined period of time, for example, operations may be undone which were performed within the past two minutes. Other possible boundaries may be defined as the maximum number of operations allowable or the size of a buffer.
This family provides requirements that address protection of user data while it is stored within the TSC.
User notes
Hardware glitches or errors may affect data stored in memory. This family provides requirements to detect these unintentional errors. The integrity of user data while stored on storage devices within the TSC are also addressed by this family.
To prevent a subject from modifying the data, the FDP_IFF or FDP_ACF families are required (rather than this family).
This family differs from FDP_ITT Internal TOE transfer that protects the user data from integrity errors while being transferred within the TOE.
FDP_SDI.1 Stored data integrity monitoring
User application notes
This component monitors data stored on media for integrity errors. The PP/ST author can specify different kinds of user data attributes that will be used as the basis for monitoring.
Operations
Assignment:
In FDP_SDI.1.1 the PP/ST author should specify the integrity errors that the TSF will detect.
In FDP_SDI.1.1 the PP/ST author should specify the user data attributes that will be used as the basis for the monitoring.
FDP_SDI.2 Stored data integrity monitoring and action
User application notes
This component monitors data stored on media for integrity errors. The PP/ST author can specify which action should be taken in case an integrity error is detected.
Operations
Assignment:
In FDP_SDI.2.1 the PP/ST author should specify the integrity errors that the TSF will detect.
In FDP_SDI.2.1 the PP/ST author should specify the user data attributes that will be used as the basis for the monitoring.
In FDP_SDI.2.2 the PP/ST author should specify the actions to be taken in case an integrity error is detected.
This family defines the requirements for ensuring the confidentiality of user data when it is transferred using an external channel between the TOE and another Trusted IT Product. Confidentiality is enforced by preventing unauthorised disclosure of user data in transit between the two end points. The end points may be a TSF or a user.
User notes
This family provides a requirement for the protection of user data during transit. In contrast, FTP_ITC handles TSF data.
FDP_UCT.1 Basic data exchange confidentiality
User application notes
The TSF has the ability to protect from disclosure some user data which is exchanged.
Operations
Assignment:
In FDP_UCT.1.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when exchanging user data. The specified policies will be enforced to make decisions about who can exchange data and which data can be exchanged.
Selection:
In FDP_UCT.1.1, the PP/ST author should specify whether this element applies to a mechanism that transmits or receives user data.
This family defines the requirements for providing integrity for user data in transit between the TSF and another Trusted IT Product and recovering from detectable errors. At a minimum, this family monitors the integrity of user data for modifications. Furthermore, this family supports different ways of correcting detected integrity errors.
User notes
This family defines the requirements for providing integrity for user data in transit; while FPT_ITI handles TSF data.
FDP_UIT and FDP_UCT are duals of each other, as FDP_UCT addresses user data confidentiality. Therefore, the same mechanism that implements FDP_UIT could possibly be used to implement other families such as FDP_UCT and FDP_ITC.
FDP_UIT.1 Data exchange integrity
User application notes
The TSF has a basic ability to send or receive user data in a manner such that modification of the user data can be detected. There is no requirement for a TSF mechanism to attempt to recover from the modification.
Operations
Assignment:
In FDP_UIT.1.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced on the transmitted data or on the received data. The specified policies will be enforced to make decisions about who can transmit or who can receive data, and which data can be transmitted or received.
Selection:
In FDP_UIT.1.1, the PP/ST author should specify whether this element applies to a TSF that is transmitting or receiving objects.
In FDP_UIT.1.1 the PP/ST author should specify whether the data should be protected from modification, deletion, insertion or replay.
In FDP_UIT.1.2 the PP/ST author should specify whether the errors of the type: modification, deletion, insertion or replay are detected.
FDP_UIT.2 Source data exchange recovery
User application notes
This component provides the ability to recover from a set of identified transmission errors, if required, with the help of the other trusted IT product. As the other trusted IT product is outside the TSC, the TSF cannot control its behaviour. However, it can provide functions that have the ability to cooperate with the other trusted IT product for the purposes of recovery. For example, the TSF could include functions that depend upon the source trusted IT product to re-send the data in the event that an error is detected. This component deals with the ability of the TSF to handle such an error recovery.
Operations
Assignment:
In FDP_UIT.2.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when recovering user data. The specified policies will be enforced to make decisions about which data can be recovered and how it can be recovered.
In FDP_UIT.2.1, the PP/ST author should specify the list of integrity errors from which the TSF, with the help of the source trusted IT product, is be able to recover the original user data.
FDP_UIT.3 Destination data exchange recovery
User application notes
This component provides the ability to recover from a set of identified transmission errors. It accomplishes this task without help from the source trusted IT product. For example, if certain errors are detected, the transmission protocol must be robust enough to allow the TSF to recover from the error based on checksums and other information available within that protocol.
Operations
Assignment:
In FDP_UIT.3.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when recovering user data. The specified policies will be enforced to make decisions about which data can be recovered and how it can be recovered.
In FDP_UIT.3.1, the PP/ST author should specify the list of integrity errors from which the receiving TSF, alone, is able to recover the original user data.