[Public Interpretations Database]

PD-0149: Clarification of FMT_MOF.1(3) for TFWPP and VPNPPs


This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.


Effective Date: 2009-03-05
Last Modified 2009-03-05

Issue

The U.S. Government Virtual Private Network (VPN) Boundary Gateway Protection Profile For Medium Robustness Environments, Version 1.1, July 25, 2007 (pp_vpn_mr_v1.1) and the U.S. Government Traffic-Filter Firewall Protection Profile For Medium Robustness Environments, Version 1.1, July 25, 2007 (pp_fw_tf_mr_v1.1) both include the following requirement.

FMT_MOF.1(3) Management of security functions behavior (audit and alarms)

FMT_MOF.1.1(3) - The TSF shall restrict the ability to enable, disable, determine and modify the behavior of the functions [Security Audit (FAU_SAR)] to [an Administrator].

However, this is a poor completion of the assignment because there are many components in FAU_SAR, and it is unclear what functions are to be modified. It is also unclear as to what it means to "enable, disable, determine, and modify the behavior" of the various potential functions in those components.

Additionally, the Traffic Filter Firewall Protection Profile rationale provided for not including the dependency FMT_SMF clearly states not only does the functionality referenced in the FMT requirements have to be restricted but they have to be provided. It uses this as the argument for not explicitly including FMT_SMF. However, in the VPN PP, FMT_SMF.1 is included but only repeats all of the FMT related requirements by merging them all together and stating the functions must be restricted. This seems to imply that only if the functionality is provided that it must be restricted and does not mandate the functionality. There needs to be consistency in the interpretation of FMT_SMF.

Resolution

  1. FMT_MOF.1.1(3) should be interpreted that only the administrators can enable (turn-on) or disable (turn-off) the sorting or search features. "Turn-off" means that the audit records would be presented in a sequence based on when they were generated. "Modify the behavior" means that only the admin can determine whether the audit records are searched and sorted, and "determine" means the admin can tell how the search or sort is set up.

    To address this, the PP text is changed to the following:

    FMT_MOF.1(3) Management of security functions behavior (audit and alarms)

    FMT_MOF.1.1(3) - The TSF shall restrict the ability to enable, disable, determine and modify the behavior of the functions [FAU_SAR.3] to [an Administrator].

    Application Note: For the purposes of FMT_MOF.1.1(3), the following interpretations are made:

    Enable: Turn-on the sorting or search feature, so that all records (or an administrator-selected subset thereof) are presented in an order specified by the administrator.

    Disable: Turn-off the sorting or search feature, so that all records are presented in the order recorded.

    Modify the behavior of: Only the administrator may determine whether the audit records are searched and sorted.

    Determine: Only the administrator may specify the parameters for the searching or sorting.

  2. With respect to the differences on FMT_SMF: The intent is for FMT_SMF to provide an explicit listing of those management functions the TOE must provide for those functions not explicitly included elsewhere. In the case of the TFPP, it appears the basic management functions are covered elsewhere, thus supporting arguing away FMT_SMF. In the case of the VPN PP, the author chose to make those functions, and their restrictions, explicit. Both serve the same goal: to make it clear what management functions must be provided by the TOE.

    As both profiles require demonstrable performance, STs aiming for compliance with both need to ensure that this intent is met: that the specification of the management SFRs is sufficient to make clear which management functions the TOE must provide.

Support

  1. The intent of FMT_MOF is not to add additional requirements but to clarify restrictions on existing requirements. The modifications made provide those clarifications.

  2. The intent is for FMT_SMF to provide an explicit listing of those management functions the TOE must provide for those functions not explicitly included elsewhere. It appears that the existing profiles do this, so no change is required, just clarification.

Modification History:

2009-03-05
PD Created. January 2009 ODRB Agenda Item 3.a.i

References:

  • None

Related NIs:

  • None

Related CCIMB-INTERPs:

  • None

Source OD: 0278