This FAQ is designed to answer the most common questions about evaluations of, and evaluations related to, Protection Profiles within the CCEVS. We have attempted to be as clear, concise and accurate as possible. Comments and questions on this FAQ may be directed to niap@niap-ccevs.org.

• Questions concerning Use of (or Compliance to) PPs
• Questions concerning Robustness of PPs
• Questions concerning Flaws in PPs

Questions concerning Use of (or Compliance to) PPs

Does a PP have to have been evaluated/validated for compliance to it to be claimed?

Yes, the CCEVS will only allow sponsors of evaluations to claim conformance to validated protection profiles.

See also Scheme Policy Letter 3

How can a PP be successfully evaluated and validated, yet contain flaws?

Because a PP is evaluated without any kind of specific context in mind, its evaluation was conducted only in a theoretical or abstract basis. An ST evaluation provides a concrete instantiation which can help to better identify shortcomings in the abstract description of the PP.

What happens when, during an ST/TOE evaluation, a problem is discovered with a validated PP?

Whenever any kind of problem is found during an evaluation, the evaluator produces an Observation Report, which describes the problem (see also the Observation Report process). The resulting Observation Decision provides the guidance from the PP author on how the PP should be applied; this may include what amount to correction/clarification sheets for the PP. These corrections are also issued as Precedence Decisions (PDs) and can be found within the CCEVS PD database.

How do I deal with problems related to unevaluated PPs (or PPs that would fail evaluation) when they are used by ongoing ST/TOE evaluations?

When PPs are evaluated, the scheme keeps track of the responsible person or party in case any questions related to the PP should arise. If the PP is not evaluated, there is no such contact known to the scheme, so there is no definitive answer of what the PP author intended. In such cases, the Chief Validator will make an uninformed, yet educated, opinion that then serves as the Precedent Decision for that PP.

How does one deal with a PP that is sound, but overly-prescriptive in implementation detail?

PPs describe what is needed by the author; presumably the author knows what is required. However, the evaluator is still at liberty to submit an OR against the wording of the PP. The author, when consulted by the Chief Validator, may agree that the wording is overly prescriptive, or may maintain that the wording is accurate. The resulting OD (and PD) will reflect this outcome.

How does a vendor obtain a truly up-to-date version of a PP?

All validated versions of all PPs, together with any other PPs in which the Scheme has an interest, are available on the CCEVS website (together with any updates). For all others, the PP author should be consulted.

Can an evaluated TOE later claim compliance to PP (such as when the PP comes out after the TOE evaluation has completed?)

Yes, but this would technically be a new evaluation (or, more properly, a re-evaluation with a total reuse of the original results) because there is a change to the conformance claim. (Maintenance, by contrast, keeps the same conformance claim, as can be seen on the VPL).

Therefore:

1. the lab needs to perform the compliance work (ASE_PPC) and produce the ETR.
2. there needs to be a new ST to reflect the PP compliance claim. (This could likely be done by adding an annex to the original ST)
3. the new ST's identified TOE needs to be identical to the original TOE; the date should be made current (to the date the PP compliance claim is made)
4. CCEVS will issue a new certificate that cites the same TOE, the new date, and the new PP claim.
5. the VPL will add a new entry noting PP compliance. (The result is two entries with the same TOE; the compliance columns will differ)
6. the new VPL entry page (the one you get to when you click on the entry in the VPL) will point to the updated ST.

If compliance to a PP is made, and the PP is subsequently updated, can compliance to the new version of the PP be given automatically?

It would depend upon how the PP has changed. If the scope of acceptability is broadened such that anything meeting the original version of the PP would meet the updated version (as is the case with Errata Sheets), then the compliance claim can be updated through maintenance. The developer would simply note in the IAR that the only change is a broadening of PP acceptability.

If the scope of acceptability has been narrowed or changed so there is no predictable relationship between meeting the original PP and meeting the new one (as is the case with PDs), then the IAR would have to analyze the changes in the PP to assess their impact upon compliance and determine whether the new claim might be made under maintenance or would require a new evaluation.

The above presupposed there were no changes to the TOE. Of course, any changes to the TOE would have to be addressed independently.

Back to Top

Questions concerning Robustness of PPs

What is robustness?

The robustness of an evaluated product is the level of confidence in the protection provided to the security services it supports.

A characterization of the strength of a security function, mechanism, service or solution, and the assurance (or confidence) that it is implemented and functioning correctly. The Department of Defense has three levels of robustness: Ref: DoDI 8500.2 paragraph E2.1.47

• Basic Robustness. Security services and mechanisms that equate to best commercial practices
• Medium Robustness. Security services and mechanisms that provide for layering of additional safeguards above good commercial practices.
• High Robustness. Security services and mechanisms that provide the most stringent protection and rigorous security countermeasures.

How are the robustness levels defined?

The robustness level of a product is the result of two factors: the trustworthiness of the users who will be presumed to be using the product, and the sensitivity of the data being protected by the product.

This is shown graphically below:

As value increases while trustworthiness decreases, robustness increases. Robustness decreases when trustworthiness increases, or as asset value decreases.

There are three levels of robustness. These are relatively characterized; they are not decisively specified.

Is each robustness level simply a set of assurance requirements?

No. Robustness is a combination of the strength of mechanism (i.e. functional requirements) and assurance requirements.

What characterizes/differentiates the robustness levels?

At basic robustness, the amount of protection is minimal (either because of the low value of the assets, or of the trustworthiness of the users, or both). There are minimum functionality requirements that must be address from the basic robustness Consistency Instruction Manual (CIM) . Assurance is, at a minimum, EAL2 (v2.3) augmented with AVA_MSU.1 and ALC_FLR.2 or EAL2 (v3.1) augmented with ALC_FLR.2.

At medium robustness, the presumed environment is more hostile, or the assets are more valuable, or both. Consequently, the lowest level of functionality is likely not appropriate. There are minimum functionality requirements that must be address from the medium robustness (CIM) that must be addressed. For example, I&A of users will likely have to be performed on the basis of individuals; groups of users will be inadequate. (This will obviously depend upon the technology type of the TOE.) For all cases, medium robustness requires the TOE provide self-protection and non-bypassability. Assurance is approximately EAL4: EAL4 (v2.3) with explicitly-stated versions of ADV_FSP.2, ADV_HLD.2, ADV_LLD.1, augmented with ADV_IMP.2, ALC_FLR.2, ATE_DPT.2, AVA_VLA.2, and the explicitly-stated component ADV_ARC, and (if the TOE includes cryptographic functionality) an explicitly-stated versions of AVA_CCA.1 or EAL4 (v3.1), augmented with ADV_FSP.5, ADV_TDS.4, ADV_INT.3, ALC_FLR.2, ATE_DPT.3, AVA_VAN.4, and (if the TOE includes cryptographic functionality) an explicitly-stated versions of AVA_CCA_(EXT).1. The characteristics of medium robustness are further explained in the Consistency Instruction Manual for development of US Government Protection Profiles for use in Medium Robustness Environments. It should be noted that some early PPs were created before the definitions of Robustness were completely codified; consequently, some are called “Medium Robustness” despite being only EAL2 assurance. These are denoted as such on the list of Validated PPs.

High robustness is used to protect valuable assets in a very hostile environment. Consequently, the functionality must be the strongest. Functionality for High robustness protection profile would have to address, at a minimum, the functionality of basic and medium robustness and additional minimal functionality based on the technology. Since high robustness must have very strong functionality, each PP will be developed and evaluated on a case by case basis. However, the functional assurance requirements are greater than EAL6.

The general approach is that, as robustness increases, the quantity of unknowns decreases: the TOE boundary would approach the entire product, the requirements pushed out to the environment would decrease, the number of stated assumptions would decrease, the number and severity of threats would increase, etc.

Are all technology/product types applicable to all robustness levels?

All IA or IA enabled products types are applicable to robustness levels. Even though robustness levels are applicable to all IA or IA enabled products, there may be some technologies that do not have robustness levels defined.

How is the claim that a PP is appropriate for a given robustness level verified?

A PP is a set of user defined requirements for use in a certain environment that must adhere to organizational policies. The author of the PP in concert with the users of the products that will claim compliance to that PP will determine the given robustness. There is also a PP Review Board that ensures that every PP with a Robustness Level adheres to the rules set forth in the Consistency Instruction Manuals (CIM). It also ensures the minimal functional requirements in the CIM have been addressed by the author of the PP.

It should be noted that some early PPs were created before the definitions of Robustness levels were completely codified or the Consistency Instruction Manuals were written; consequently, some are called “Medium Robustness” despite being only EAL2 assurance. These are denoted as such on the list of Validated PPs.

Can a TOE/ST claim a robustness level without conforming to a PP?

No. Since robustness includes minimal functionality as well as defined assurance requirements, without a PP the required minimal functionality or minimal assurance would not be documented for a TOE/ST to claim compliant.

How are the robustness definitions affected by the evolution of the CC?

The robustness levels were originally defined in terms of the requirements in CCv2.1/2.3. This includes both functional requirements from CC Part 2 and assurance requirements from CC Part 3.

Now that version 3.1 is officially released, the robustness level definitions (and the Consistency Instruction Manuals) will likewise be updated into versions corresponding to CC v3.1 to include refinements and clarifications.

How does the Robustness Consistency Instruction Manuals Relate to Robustness?

The Consistency Instruction Manuals (CIM) for the different levels of robustness are designed to help Protection Profile developers by providing the minimum functionality that should be considered at the different levels of robustness and the list of assurance requirements that are required at the specific robustness level.

Back to Top

Questions concerning Flaws in PPs

Who determines whether a PP is in fact flawed?

The PP author (if known). When PPs are evaluated, CCEVS keeps track of the responsible person or party in case any questions related to the PP should arise. If the PP is not evaluated, there is no such contact known to the scheme, so there is no definitive answer of what the PP author intended. In such cases, the Chief Validator will make an uninformed, educated, opinion for that PP.

If a PP is flawed, who determines the approved flaw remediation?

The PP author (if known). When PPs are evaluated, CCEVS keeps track of the responsible person or party in case any questions related to the PP should arise. If the PP is not evaluated, there is no such contact known to the scheme, so there is no definitive answer of what the PP author intended. In such cases, the Chief Validator will make an uninformed, yet educated, opinion that then serves as the Precedent Decision for that PP. Whenever the PP is updated, CCEVS forwards to the author any PD related to the PP that has been written.

If a PP is flawed, who determines the time for flaw remediation?

The timeframe for updating PPs is entirely up to the author.

If a PP is shown to be flawed, can an ST claim compliance with the PP by adhering to the approved flaw remediation?

Yes. Once the intent of the PP author has been determined (either from the author or by the Chief Validator making an educated decision), the resulting PD serves as an update to the PP. Compliance is claimed against the PP with these PDs (virtually) incorporated: in the introductory part of the ST where the PP is cited, the PDs are also listed.

If a PP is shown to be flawed, can an ST still claim compliance to the original PP? Or must the vendor incorporate the relevant PD when claiming conformance?

Because the PD serves as a correction to the PP, the PD must be incorporated.

How are updates/corrections to a PP made?

An update to an evaluated PP might come about in two ways: within the scope of an evaluation of a TOE against the PP, or outside the scope of such a TOE evaluation.

1. Within the Scope of a TOE Evaluation

   During the course of evaluations that claim PP compliance, a problem (ambiguity, inconsistency, lack of clarity etc.) may be found with the PP itself. This problem, like any other technical issue arising within an evaluation, is submitted to the scheme as an Observation Report (OR). In response to such a problem, an update is formulated in consultation with the PP owner and posted by the Observation Decision Review Board (ODRB) as a Precedent Decision (PD) [the PDs produced by the ODRB record all precedent decisions, not only those related to PPs].

   The PD contains textual changes for the PP, as well as an explanation of the reason for those changes. This is already performed as part of the ODRB charter. In formulating the PD, the ODRB verifies that it (in concert with other PDs related to the PP) is consistent and that the impact of implementing the changes does not negatively impact the PP. In cases where the PD reveals a need to substantially change the PP, the PP author is notified.

   The PD might broaden or reduce (or have no effect upon) the applicability of the PP. That is, there is no predictable relationship between meeting the original PP and meeting the new one.

2. Outside the Scope of a TOE Evaluation

   Problems may also be found with the PP outside the scope of an evaluation, such as when it is reviewed for academic or intellectual curiosity, or when the PP owner discovers that the PP is worded to be incorrectly constrictive and then decides on a resolution. The PP owner, in concert with the PPRB, issues an Errata Sheet, which broadens the scope of acceptability such that anything meeting the original version of the PP would meet the updated version.

When correcting a flawed PP, what is the difference between an Errata Sheet and a PD (Precedent Decision)?

An errata sheet will be used to update a flawed PP when the scope of the PP is broadened to allow additional flexibility without the need for additional SFRs or SARs. That is, anything meeting the PP without the Errata Sheets would also meet the PP with the Errata Sheets.

A PD is used to correct a specific problem that may require additional SFRs or SARs to narrow the scope of the PP or to clarify a specific requirement that may also require addition SFRs or SARs.

How are updates/corrections to a PP associated with the PP?

As a result of an Errata Sheet, the PP version number is fractionally incremented (e.g. from 1.2 to 1.3). The Errata Sheet is affixed to the PP as an Appendix; the introduction to the PP will note the presence of the Errata Sheet Appendix.

The existence of a PD does not affect the version number of the PP.

The information sheet for the PP will note when there is an errata sheet or PD associated with the PP. Any PD identifier will be linked to the PD within the CCEVS database (http://www.niap-ccevs.org/PD/index.html).

Can all changes to PPs be made through PP maintenance?

The responses to the two preceding questions describe the process for maintaining PPs in response to (using the Assurance Continuity parlance) "minor changes". Changes that are of "major" impact, such as those that introduce new functionality, would be beyond the scope of "maintenance" defined herein and would therefore require a new PP and new PP evaluation.

Back to Top