PD-0053: Issues Related to Software Only TOEs

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.

Issue

1. Can a TOE which is a software-only product (i.e., does not include any hardware) be compliant with a profile whose TOE requirements include components such as FAU_STM, FPT_SEP and FPT_RVM?

2. Can an ST claim conformance to a profile if the ST allocates requirements to the IT environment that are identified as TOE requirements in the PP?

3. It is not clear how the ACM_CAP.4 and the ASE_PPC.1.2E requirements are to be applied for a software-only TOE. The sponsor/developer's concern is that if PP requirements are allocated to the IT environment, then ACM_CAP and ASE_PPC levy requirements on the developer for control over, or evidence about components (e.g., hardware) that are not under his control.

Resolution

1. Note that profiles often do not mandate hardware and, in fact, does not distinguish between hardware, software, and/or firmware. The PP must be viewed as a specification for the capabilities and behavior required of a compliant product. Although it is not mandated that hardware be included, this position does not guarantee that attempting to meet the PP requirements completely in software will necessarily be easy. Compliance with several key requirements, in particular FPT_RVM, are relatively easy to argue from the basis of features in hardware but considerably more difficult to argue/demonstrate based on software architecture. In short, if the TOE requires the existence of hardware protection mechanisms to satisfy PP requirements, then the TOE shall include the hardware.

2. A TOE that allocates PP requirements levied on the TOE to the IT environment is non-compliant. By definition, such a TOE does not provide all of the required features and/or assurances required by the PP.

3. The ACM_CAP.4 and the ASE_PPC.1.2E requirements apply as written; with the stipulation that the TOE is PP-compliant (i.e., there are no PP requirements that are outside the TOE), then the configuration management requirements are sufficient to provide confidence that the security behavior of the TOE is preserved across modifications. Also, ASE_PPC.1.2E is not seen to be a problem, given that the TOE is a complete and accurate instantiation of the PP requirements.

Support

As noted above, a protection profile is seen as a specification for features and behavior required of a TOE. The architecture selected for the TOE and the form that the TOE takes are arbitrary; the only criterion is compliance with the PP SFRs and assurance requirements. In short, the PP does not preclude a solution that is software-only. A software-only solution is neither inconceivable nor technically unachievable. In fact, precedent exists for such products. However, this position neither implies nor guarantees that a solution that does not include (proper) underlying hardware is necessarily easy to achieve. Quite the opposite. Key requirements, in particular FPT_RVM and FPT_SEP, typically rely on fundamental hardware protection mechanisms (e.g., support for domains, memory & process management). Providing the same or equivalent protection mechanisms in software requires an appropriate software architecture, not normally found in commonly available commercial products. As a consequence, an application product that is a set of appropriate utilities, hosted on an underlying operating system platform which, in turn, relies on the base hardware for fundamental protection mechanisms is unlikely to satisfy the totality of the protection profile requirements without including the hardware.

The PP specifies the capabilities and behavior required of a compliant product. Allocating requirements to the IT environment means that those requirements are not satisfied by the TOE. Additionally, it means that requirements such as testing and configuration control cannot be applied to security mechanisms that are required by the PP, but not provided by the TOE. By definition, allocating PP requirements to the environment is an admission that the TOE is not a complete instantiation of the PP; some required features and/or capabilities are outside the TOE. Consequently, such a TOE is, by definition, non-compliant with the PP.

As for the ACM_CAP.4 and ASE_PPC.1 requirements, they are not seen to be a problem unless the TOE allocates PP requirements to the IT environment. As noted above, when PP requirements are allocated to the IT environment:

• The TOE is not a complete instantiation of the PP (ASE_PPC.1).

• Some of the features and assurances required to completely comply with the PP are outside the control of the developer. Thus, configuration management procedures and controls (ACM_CAP) are not (i.e., can not) be applied to all features and/or assurances necessary to assure PP compliance across product versions.

However, with the stipulation that the TOE is a complete instantiation of the PP requirements, then there is no particular problem seen in satisfying the referenced components.

Modification History:

2004-08-12

Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

• CC v2.1 August 1999

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0189