[Public Interpretations Database]

PD-0151: Acceptable Demonstrable Assurance for the IDS System PP v1.7 (BR)

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-06-01
Last Modified 2009-06-01

Issue

A question has arisen regarding what it means to be compliant with the U.S. Government Protection Profile Intrusion Detection System System For Basic Robustness Environments, Version 1.7, July 25, 2007. This PP requires demonstrable conformance, not strict conformance. For reference, demonstrable compliance in ccv3.1 is defined as follows:

demonstrable conformance: there is no subset-superset type relation between the PP and the ST. The PP and the ST may contain entirely different statements that discuss different entities, use different concepts etc. However, the ST shall contain a rationale on why the ST is considered to be "equivalent or more restrictive" than the PP (see Section D.3). Demonstrable conformance allows a PP author to describe a common security problem to be solved and provide generic guidelines to the requirements necessary for its resolution, in the knowledge that there is likely to be more than one way of specifying a resolution. Demonstrable conformance is also suitable for a TOE type where several similar PPs already exist (or likely to exist in the future), thus allowing the ST author to claim conformance to all these PPs simultaneously, thereby saving work. (para 436, Part 1)

Paragraph 444 and 445 provide additional details on what is required for demonstrable conformance:

Demonstrable conformance is orientated to the PP-author who requires evidence that the ST is a suitable solution to the generic security problem described in the PP. Where there is a clear subset-superset type relation between PP and ST in the case of strict conformance, the relation is less clear-cut in the case of demonstrable conformance. The general statement is that the ST must be equivalent or more restrictive than the PP. An ST is equivalent or more restrictive than a PP if:

  • all TOEs that meet the PP also meet ST, and

  • all operational environments that meet the ST also meet the PP.

or, informally, the ST shall levy the same or more, restrictions on the TOE and the same or less restrictions on the operational environment of the TOE.

This general statement can be made more specific for various sections of the ST:

  • Security problem definition: The conformance rationale in the ST shall demonstrate that the security problem definition in the ST is equivalent (or more restrictive) than the security problem definition in the PP. This means that:

    • all TOEs that would meet the security problem definition in the ST also meet the security problem definition in the PP;

    • all operational environments that would meet the security problem definition in the PP would also meet the security problem definition in the ST.

  • Security objectives: The conformance rationale in the ST shall demonstrate that the security objectives in the ST is equivalent (or more restrictive) than the security objectives in the PP. This means that:

    • all TOEs that would meet the security objectives for the TOE in the ST also meet the security objectives for the TOE in the PP;

    • all operational environments that would meet the security objectives for the operational environment in the PP would also meet the security objectives for the operational environment in the ST.

  • SFRs: The conformance rationale in the ST shall demonstrate that the SFRs in the ST are equivalent (or more restrictive) than the SFRs in the PP. This means that all TOEs that would meet the SFRs in the ST would also meet the SFRs in the PP;

  • SARs: The ST shall contain all SARs in the PP, but may claim additional or hierarchically stronger SARs. The completion of operations in the ST must be consistent with that in the PP; either the same completion will be used in the ST as that in the PP or a completion that makes the SAR more restrictive (the rules of refinement apply).

The following are examples of potential deviations from the Protection Profile requirements:

  1. Local and Remote Authentication. The current PP is written to levy the FIA requirements (identification and authentication) on the TOE, meaning these must be completely internal functions. It should be possible to be able to support not only local authentication, but authentication via a LDAP or Radius server in the operational environment (which provides support for the DOD 8500.2 DCBP control).

  2. Remote Notification. The current PP has a requirement to send alarms when intrusion events occur, and most systems provide these alerts by electronic mail, SNMP, or Syslog. However, the PP does not note any operational environment requirements for these alerts. It should be permissible to include the ability to interface with external SNMP, SMTP, and Syslog servers in the operational environment to support delivery of these alerts outside the TOE.

  3. Centralized Time. An appliance may appropriately have reliable time coming initially from the administrator. It is also desirable to support interface with a remote NTP server for centralized time synchronization, which improves the overall accuracy of a system's audit records.

  4. PD-0097. PD-0097 was written on a previous version of the profile, and permitted exchange of some SFRs that were designed for communication with IDS components in the operational environment with the SFRs that were appropriate for internal TOE communication for a distributed TOE. This PD has not been revalidated as applicable for the v3.1 profiles.

  5. Policy 13 Addendum. The Policy 13 addendum requires products submitted for evaluation to include all functionality for their product type as defined by the appropriate PP, and it also appears to require that additional security related product features should be included within the TOE boundary so that the product as advertised is the same as the product as evaluated.

Resolution

  1. Local and Remote Authentication - The ST can include more than the PP requirements as long as it does not violate the demonstrable conformance requirement. The PP as stated is the minimum requirements.

  2. Remote Notification - Based on the following PP requirement, the ST can define where the alarm's destination is located:

    IDS_RCT.1.1 The System shall send an alarm to [assignment: alarm destination] and take [assignment: appropriate actions] when an intrusion is detected. (EXT)

    Application Note: There must be an alarm, though the ST should refine the nature of the alarm and define its target (e.g., administrator console, audit log). The Analyser may optionally perform other actions when intrusions are detected; any such actions should be defined in the ST. An intrusion in this requirement applies to any conclusions reached by the analyser related to past, present, and future intrusions or intrusion potential.

  3. Centralized Time - The PP states OE.TIME The IT Environment will provide reliable timestamps to the TOE. FPT_STM.1 Reliable time stamps should have been designated to the IT environment. Therefore, it is acceptable to get the timestamps from the TOE and/or from an external NTP server as long as the appropriate requirements are included in the ST.

  4. PD-0097 - As stated in the Forward to the PP, "CC version 3.1 used the final CC version 2.3 Security Functional Requirements (SFR)s as the new set of SFRs for version 3.1. Some minor changes were made to the SFRs in version 3.1, including moving a few SFRs to Security Assurance Requirements (SAR)s. There may be other minor differences between some SFRs in the version 2.3 PP and the new version 3.1 SFRs. These minor differences were not modified to ensure the author's original intent was preserved." Therefore, all PDs written for CC version 2.x SFR are still appropriate where applicable.

  5. Policy 13 Addendum - As long as the ST does not violate the "demonstrable conformance" definition to be "equivalent or more restrictive" than the PP, the additional features can be included. However, the ST author shall provide the rationale on why the ST is considered "equivalent or more restrictive" with these additional features.

Support

The resolutions support ST variations from the PP so long as they are more restrictive (in the case of ST SFRs) or more encompassing (in the case of SARs and objectives). An example of a more restrictive SFR would be if the PP required single-factor authentication and the ST implemented two- or three-factor authentication. A more encompassing SAR may include additional audit information while containing the basics required in the PP.

Modification History:

2009-06-01
PD issued (April/May 2009 ODRB Meeting, Agenda Item 3.a.ii)

References:

  • None

Related NIs:

  • None

Related CCIMB-INTERPs:

  • None

Source OD: 0282