RE: I-0434: 3rd Party Hardware/Software And Assurance
It is my understanding that if the 3rd party product is part of the TOE,
then it is subject
to all the assurance requirements of the ST. The amount of detail required
is based on the
significance of the product's role in implementing the security
requirements,
not whether it is third party. The challenges of implementing this in
practice
were the motivating factor of my original email. When a third party product
plays a significant
role in policy enforcement, such as cryptographic toolkits, this can be very
difficult.
I can only assume that the PP authors are not always aware of what
requirements
are provided by 3rd party products. The PPs may not be written with 3rd
party
products in mind. The reality of what is required to meet many of the PPs
requires the ST to
include 3rd party products in the TOE.
Michelle A. Ruppel
Saffire Systems
P.O. Box 11154
Champaign, IL 61826
217-359-7763 Fax: 217-359-8753
> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of
> Shari Galitzer
> Sent: Wednesday, June 25, 2003 10:09 AM
> To: Multiple recipients of list
> Subject: RE: I-0434: 3rd Party Hardware/Software And Assurance
>
>
> Thanks for this note, it helps put focus on the area I'm
> looking for guidance.
>
> When you say, 'The degree of analysis of the third party
> product is dependent on the role it plays in satisfying the
> requirements.' it makes sense. However, the policy isn't
> clear to me for the assurance requirements that apply to the
> TOE, e.g., ACM_SCP.1.1C, ALC_DVS.1.1C, and ALC_TAT.1. Is it
> possible for an ST wanting to claim compliance to a TOE that
> requires the entire platform (e.g., 'medium robustness' TOE)
> to exclude a 3rd party component from an assurance
> requirement and present a case that the assurance claim isn't
> compromised (possibly with mechanisms that allow a component
> to be considered a black box for that assurance requirement)?
> Is it expected/required that the PP author provide guidance
> on 3rd party components, their role in security functions and
> assurance requirements?
>
> Thanks a lot,
> Shari Galitzer
> CygnaCom Solutions, Inc.
> an Entrust company
> Phone: 608-251-6414 Fax: 608-441-6902
> http://www.cygnacom.com
>
>
>
> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov]On Behalf Of
> James Donndelinger
> Sent: Wednesday, June 25, 2003 6:38 AM
> To: Multiple recipients of list
> Subject: Re: I-0434: 3rd Party Hardware/Software And Assurance
>
>
> I'm somewhat confused. The PPs do not care about third party products or
> what relationships vendors have with one another. The only thing a PP
> cares about is that the requirements the PP authors have deemed to be
> appropriate for their technology are met. It makes no sense to me to
> allow an ST to decide which PP requirements they'll meet in their TOE
> and which they'll levy on the IT environment. If that was allowed, PPs
> have no purpose - just let vendors write STs. If the PP authors what the
> TOE to include the "supporting security functions", such as audit and
> timestamping , why would it be acceptable for a vendor to state that "we
> don't do audit so we'll just levy that on the IT environment"? If a PP
> author only cares that the TOE generate auditable events and decides the
> TOE doesn't have to store the audit data, protect it, or provide a
> method for review than they can levy the requirements on the IT
> environment, but this choice is theirs to make, not an ST author.
>
> Third party products must be treated as though it is provided by the
> first party. The degree of analysis of the third party product is
> dependent on the role it plays in satisfying the requirements. If I have
> a firewall product and I'm relying on a third party product to provide
> my NIC, I would say that the NIC potentially plays a critical role in
> the TOE's ability to satisfy the requirements and would warrant close
> scrutiny. If a third party product is providing process management
> functions, I would venture to guess that that would probably not play a
> significant role in policy enforcement and would require less analysis.
> The detail required in design documentation, the rigor of the analysis
> and amount of testing required depends upon the role played in policy
> enforcement, not whether the component is developed by the ST author or
> a third party.
>
> ~Jim
>
> Michelle A. Ruppel wrote:
>
> >As Randy implies below, the reason this is such an important
> issue is
> >that in some cases the PPs require (intentionally or not)
> third party
> >products to be part of the TOE. If the
> >vendor wants to claim PP compliance, the ST author does not
> have the choice
> >of putting the
> >third party product in the environment (look at the IDS PPs
> for an example).
> >In addition,
> >when the PP requires an assurance level above EAL2, the assurance
> >requirements cannot be met
> >without cooperation from the third party vendor.
> >
> >The PPs should allow the vendor to decide what is in the TOE
> and what
> >is in the IT environment by allowing supporting requirements
> to be met
> >by either the TOE or IT environment.
> >For example, the IDS PPs would not allow IDS-specific requirements
> >to be delegated to the environment, but would allow
> supporting security
> >functions, such as
> >audit & time stamping, to be delegated to the environment.
> The goal is to
> >get a realistic
> >approach that can actually be evaluated by any product vendor.
> >
> >I'm not sure what the ramification of this may be, but here are some
> >thoughts:
> >Perhaps what the PP authors and consumers really need/want is some
> >assurance provided by the vendor for the third party
> products used or
> >delivered by the vendor. Has the concept of assurance on the third
> >party products in the IT environment ever been considered?
> >For example, does the vendor test the third party product as
> it relates to
> >the vendor's product?
> >Does the vendor use any CM measures on the product delivered
> by the third
> >party?
> >What is the process used for deciding that the third party
> product can be
> >used with the vendor's product?
> >
> >The overall assurance level is better if vendors provide
> assurance on
> >third party products. Unless the third party vendor cooperates
> >completely, the third party product
> >assurance measures are not as strong as those that can be
> used when the
> >vendor has the source
> >code and controls the complete development process. For
> small businesss,
> >obtaining complete
> >cooperation from another third party can be very difficult, if not
> >impossible.
> >Allowing this distinction between types of assurance will
> allow the vendor's
> >product and its
> >supporting third party products to have different levels of
> assurance.
> >
> >Michelle A. Ruppel
> >Saffire Systems
> >P.O. Box 11154
> >Champaign, IL 61826
> >217-359-7763 Fax: 217-359-8753
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of
> Simpson,
> >>Randy
> >>Sent: Monday, June 23, 2003 8:13 AM
> >>To: Multiple recipients of list
> >>Subject: RE: I-0434: 3rd Party Hardware/Software And Assurance
> >>
> >>
> >>
> >>It would appear to me that if we think of the CC and its
> evaluation as
> >>truth in advertising, then the key is not requiring
> assurance on the
> >>environment elements - (although PP writers may do so!),
> but in being
> >>explicit as to what in the environment the TOE relies upon.
> Where the
> >>Toe begins and ends and where the environment takes over is
> one of the
> >>hardest things an ST writer can undertake. We do not have a
> >>clear enough requirement to state this in the ST, and that is
> >>where it belongs. The clear definition of the physical and
> >>logical scope and boundary of the TOE must include not only
> >>the line of demarcation, but what is required of the
> >>environment. Further, it is incumbent upon PP writers to be
> >>explicit here for the making of PP conformance claims in the
> >>ST. This last glitch may be why so many PP claims are
> >>dropped during evaluation.
> >>
> >>It is a curious note that if we find a security breach in the
> >>environment during testing, what do we do? It is not a
> vulnerability
> >>in the TOE. Right now everyone relying on any version of Windows
> >>takes all its warts with it.
> >>
> >>
> >>-----Original Message-----
> >>From: Knoke, Jim [mailto:Jim.Knoke@DigitalNet.com]
> >>Sent: Monday, June 23, 2003 8:38 AM
> >>To: Multiple recipients of list
> >>Subject: RE: I-0434: 3rd Party Hardware/Software And Assurance
> >>
> >>
> >>
> >>
> >>
> >>
> >>>Perhaps what we need instead of alternative assurance is new
> >>>interpretations for the existing assurance classes. Can we find
> >>>cases where the existing
> >>>requirements can be "softened" for the sort of components
> >>>you're talking
> >>>about?
> >>>
> >>>
> >>Yes, I agree that some interpretations that soften the
> requirements on
> >>certain kinds of components would help (but I'm not sure that will
> >>take it far enough). I like the examples Nir gives.
> However, I'm not
> >>sure the end result of the evaluation is really as high an
> assurance
> >>product as was intended by the scheme. We can change
> ADV_IMP to only
> >>require what is used by the vendor (e.g., a binary version of a
> >>library) from a third-party provider, but then much of the
> >>assurance benefit of ADV_IMP (analysis of design
> >>decomposition and verification of sound implementation
> >>practices??) seems to be down the drain. Maybe this could be
> >>"balanced" by "improved" assurance in some other area, such
> >>as testing.
> >>
> >>
> >>
> >>
> >>>So my question (after an admittedly long introduction) is
> - how far
> >>>can we go in terms of the existing assurance classes for a
> component
> >>>for which we
> >>>don't have the source code. Assume the following:
> >>>1. The third-party component is not an evaluated product;
> >>>2. The third-party component is included in the TOE;
> >>>3. The third-party component is not security-critical (i.e.
> >>>it is not a part
> >>>of the TSF).
> >>>
> >>>
> >>I'd prefer to strike assumption #3, but admittedly, that's a
> >>harder sell..
> >>
> >>
> >>
> >>
> >>>ACM_AUT talks about Implementation Representation, but should be
> >>>satisfied by including the component in the CM system.
> >>>The same goes for the rest of the ACM class. I couldn't find
> >>>any problem
> >>>there.
> >>>
> >>>
> >>Depending on the third-party component, at high assurance
> >>levels, it may get tricky to identify, accurately enough, the
> >>component and track changes to it. The security vendor would
> >>prefer not to lock down the evaluated configuration to an
> >>exact revision of the third-party component (since some
> >>components are revised often). Some third-parties (I am
> >>thinking of hardware vendors) are not too good about
> >>providing details of all the versions on the market and what
> >>the exact differences are between the versions.
> >>
> >>
> >>
> >>
> >>>ADO, ALC_FLR and ALC_LCD also seem to work, if the
> developer of the
> >>>TOE is taking responsibility for lifecycle management for this
> >>>component.
> >>>
> >>>
> >>I think _FLR could be a challenge since the vendor probably
> >>will not want to devote the resources to track all problems
> >>on a "popular" third-party component such as a CPU or library.
> >>
> >>
> >>
> >>
> >>>ALC_DVS refers to the development security for the entire TOE. I
> >>>couldn't see how to get around this. However, this family examines
> >>>the component
> >>>developer more than it does the component itself. Perhaps the
> >>>component
> >>>developer could cooperate in this regard with the TOE
> >>>developer and provide
> >>>the appropriate evidence to the evaluation lab.
> >>>
> >>>
> >>I think that is ok in theory, but in practice, if the
> >>third-party component comes out of Intel, for example, I
> >>think the little security vendor is going to be hard-pressed
> >>to get any cooperation from Intel. I don't think the scheme
> >>should be discouraging the use of Intel products in secure
> >>solutions, so I think they need to decide if they are just
> >>going to force C&A efforts to deal with composition issues or
> >>if they are going to "adjust" the CC requirements to allow
> >>the security vendors to (reasonably) include the third-party
> >>products in the CC evaluations.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
>
> --
> James Donndelinger
> The Aerospace Corporation
> 8840 Stanford Blvd
> Suite 4400
> Columbia, MD 21045
> (410) 312-1406
>
>
Date Index |
Thread Index |
Problems or questions? Contact list-master@nist.gov