PP Problems: External Standards

["Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>]

This is one of a series of posts that deal with the topic of apparent
problems in protection profiles. The U.S. Government is currently in the
process of producing and reproducing a wide range of protection profiles to
be used in conjunction with recent policies regarding the government use of
evaluated products.
 
Examination of the draft Protection Profile Consistency Guidance for Medium
Robustness (Medium Robustness Guide) and also some of the products of that
guide, at least one of which is currently undergoing evaluation, has
revealed a number of apparent problems. Since this is a technical forum, I
will limit my comments/questions to those of a technical nature and will not
go into any usability, practicality, or reality related issues.
 
While this forum is not intended to deal with publications other than the CC
and CEM, my issues are related to the application of the CC.
 
 
The following example was found in a U.S. Government Medium Robustness
Protection Profile. This seems to be an evolving problem with substantial
reference to external standards in existing and evolving Medium Robustness
PPs and most likely the evolving Medium Robustness Guide. Note that there
are a number of issues identified below.
 
-------------------------------------------

>From the PP:
 
"FCS_BCM_EXP.1.1 - The cryptographic module shall be FIPS PUB 140-2
validated."
 
-------------------------------------------

QUESTION: Is the explicit PP requirement legal or not?
 
   - While not apparent from the example, the PP contains no rationale that
the CC assurance requirements apply to this explicit requirement. As such,
the PP needs to have that rationale in order to be complete. Note that it is
not clear how the CC assurance requirements can apply to determining the
state of being validated by some process outside the CC. In other words, an
evaluation team should be able to follow the CEM to determine whether this
requirement is satisfied. Should the design documentation explain this? Must
the developer have a test to demonstrate this security function? etc.
 
   - According to Part 2 of the CC, paragraph 1, "[SFRs] describe the
desired security behavior expected of a Target of Evaluation (TOE) and are
intended to meet the security objectives as stated in a PP or an ST. These
requirements describe security
properties that users can detect by direct interaction with the TOE (i.e.
inputs, outputs) or by the TOE's response to stimulus." Basically, I do not
believe that whether a product has been validated by some other process
against some other standard is a security function. Hence, this is not a
legal security functional requirement by definition. It certainly is a good
user requirement, but it doesn't seem to belong nestled among SFRs.
 
   - If this requirement actually indicates that the CC evaluation team must
determine conformance with FIPS PUB 140-2, we have a different problem.
Specifically, that publication is now part of the PP by reference and as
such the entire publication is now subject to the APE_REQ and APE_SRE
requirements. If there are aspects of the publication that are not security
functional in nature there would at least be a consistency problem. Also, it
seems unlikely that the publication conforms to the presentation style of
the CC. As noted above, the explicitly stated requirement rationale is
incomplete and would need to address the entire requirement (including the
publication).
 
COMMENTS:

Note also that while this example addresses explicit requirements, it should
also apply to external standard conformance in assignments of existing CC
requirements. However, identification of a failure is not so clear cut in
this case since there aren't any requirements about the format of
assignments, for example. However, if an assignment results in a SFR that
doesn't apply to any security function of the TOE - it would be an illegal
assignment by definition (of security function or SFR). Additionally, the
APE_REQ requirements would necessarily apply to any external standards
brought into the PP. At the very least, the requirements must be complete,
coherent, and consistent both internally and with the rest of the PP.

The bottom line is that the CC was not designed to allow external
requirements to "simply" be plugged into PPs and STs. CC evaluation teams
must be able to appropriately deal with PP (and subsequently ST)
requirements using the CEM and that is certainly not the case for arbitrary
external standard that might be desired by a PP author. I'd suggest that if
it is important to include an external standard in a PP for CC evaluation,
the standard should be translated into the CC. More importantly, this
translation should be performed by the PP author rather than by a CC
evaluation team in the process of struggling with how to evaluate something
new and exciting. Regardless, the CC does not have any provision for a PP to
require (and a CC evaluation team to evaluate) that a product has been
validated against any standard external or not. For example, a PP cannot
simply include a SFR indicating that a TOE was evaluated against another PP
- rather the PP must include the requirements of that other PP and require
that the TOE be evaluated against them. This is the CC model.
 
 
Note that the issue of external standards was not previously a significant
concern since Interpretation 427 indicates that the ST must identify how
conformance was determined and provides as examples third party evaluation,
evaluation team evaluation, or developer assertion. Hence, the ST only had
to be honest and no additional burden was necessarily placed on the
developer or the evaluation team. That interpretation has recently been
questioned by CCEVS and it appears that it might be withdrawn, leaving
evaluation teams to address external standards head-on. While I don't
necessarily agree with Interpretation 427, I do not believe it is reasonable
to assume that CC evaluation teams can appropriately deal with arbitrary
standards.