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

["Observation Decisions Review Board" <faigin@aero.org>]

The following PD (PD-0151) was developed by the ODRB during its April/
May meeting.  Comments on this PD are welcome and will be considered at
the next ODRB meeting.


TITLE	

Acceptable Demonstrable Assurance for the IDS System PP v1.7 (BR)


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. 

RATIONALE

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. 



--
Daniel Faigin, CISSP, Coordinator for the CCEVS ODRB
Please send any comments or questions on this post to faigin@aero.org, and 
indicate it is an ODRB issue.