Re: I-0434: 3rd Party Hardware/Software And Assurance

["NIAP Interpretations Board" <faigin@aero.org>]

The NIB agrees with Mr. Knoke (Thu, 15 May 2003 comment) that the Statement 
should also address hardware and firmware. We have reworked the interpretation 
to refer consistently to third-party components. 

The NIB agrees with various commenters that the role that a third-party 
hardware, software, or firmware component plays -- part of the TOE, part of the 
TSF, part of the non-TOE IT environment -- affects whether and how the third-
party component is evaluated.

The NIB observed that, while all of the CC, Part 2, requirements seems to 
address the TSF, several of the CC, Part 3, requirements levy requirements on 
the TOE (e.g., ACM, AGD, ALC, AVA_MSU).  Therefore, if the third-party 
component is part of the TOE, those requirements will need to be met. In this 
regard, the NIB agrees with Mr. Henefield's comment (Fri, 16 May 2003) that, 
once a TOE developer implements open source code -- or executable code for that 
matter -- into their product and enters the code into their CM system, we would 
expect the TOE developer's ACM and ALC procedures to apply to that source code.

The NIB agrees with Mr. Naaman's comment (Sat, 21 Jun 2003) that, "if the third-
party component does not provide any security functionality -- then it will not 
in any case be a part of the TSF, so the question is only whether it can/must 
be included as part of the TOE." The NIB also thought that Mr. Naaman did a 
good job in analyzing how such a component could be handled in most of the EAL4 
security assurance requirements-provided that the implementation representation 
of the third-party component is the component itself.  The NIB encourages 
readers to review this particular comment.

The NIB also recognizes the issues of using already-evaluated third-party 
components and agreed with Mr. Arnold (Fri, 16 May 2003) that the notion of 
composition should exist and be supported.  The NIB also agrees that the notion 
of balanced assurance, if accepted, might also apply.  However, balanced 
assurance should be based on risk and not on the ease with which the needed 
evaluation documentation can be obtained.  Furthermore, as Mr. Naaman 
commented, balanced assurance should be valid "only for parts of the TOE for 
which it can be shown that a different level of assurance is appropriate in 
terms of solving the security problem." Finally, the NIB emphasizes that it is 
the PP or ST author-and not the evaluator-who determines the balanced assurance 
for a TOE.

The NIB also recognizes, as Ms. Ruppel indicated (Tue, 24 Jun 2003), that many 
of the PPs to which many IT developers must claim conformance require third-
party products to be part of the TOE, and notes that, if PP authors would 
allocate the requirements to the IT environment, then developers could decide 
which requirements would be met by the TOE and which by the IT environment and 
correctly claim conformance. If PP conformance is not being claimed, the 
developer could re-draw the TOE boundaries and eliminate TOE and PP components 
that are problematic.

The NIB feels that, since the developer may choose to use third-party hardware, 
software or firmware, the developer must obtain or develop the necessary 
assurance documentation for such components. If the developer cannot obtain 
that documentation, he will need to decide whether to develop the documents, 
use a different component, or exclude the component.

The NIB determined that the clause, "unless the PP or ST indicates otherwise," 
needs to be appended to the Statement.