Re: I-0434: 3rd Party Hardware/Software And Assurance
- Subject: Re: I-0434: 3rd Party Hardware/Software And Assurance
- From: "NIAP Interpretations Board" <firstname.lastname@example.org>
- Date: Thu, 31 Jul 2003 19:30:05 -0700
- Content-description: Mail message body
- Content-transfer-encoding: 7BIT
- Content-type: text/plain; charset=US-ASCII
- Priority: normal
- Reply-to: email@example.com
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.
Date Index |
Thread Index |
Problems or questions? Contact firstname.lastname@example.org