RE: Addendum to Policy Letter 13: Audit Generation Functionality
A fact of life is that CCEVS, the US CC evaluation scheme, is no longer
a joint NIST/NSA activity. It is now solely an NSA activity with regard
to scheme operations and the setting of scheme policy.
CCEVS has decided that CCEVS exists to meet the needs of NSA customers.
It appears that needs of non-NSA customers will be met when those needs
coincide with DoD needs.
* Opinions are not intended to reflect an official position of JHU/APL *
* Gary Stoneburner *
* Johns Hopkins University Applied Physics Laboratory *
* 11100 Johns Hopkins Road, MS 17-N406 *
* Laurel, MD 20723-6099 *
* Phone: 240-228-2628 (WA DC), 443-778-2628 (Baltimore) *
* Fax: 240-228-6391 (WA DC), 443-778-6391 (Baltimore) *
* Gary.Stoneburner@jhuapl.edu *
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Dawn Adams
Sent: Friday, March 09, 2007 2:07 PM
To: Multiple recipients of list
Subject: RE: Addendum to Policy Letter 13: Audit Generation
Unfortunately, I am unable to read the specific addendum as the web page
is down for repair, but the threads have given me an idea what is being
My 2 cents:
I agree with Mr. Forsberg. I have read the other threads as well. I
appreciate Mr. Faigin's security concerns but I have a table of SFRs
from the CC Part 2 with associated audit and management suggestions.
The CC says "should" and "may" not shall. Mr. Faigin has described the
US CC scheme interestingly - the products are not from NSA. The scheme
is administered by NSA and is part of a larger community (the CCRA
signatories). CC is, and always has been, a commercial scheme and
without vendors there is no scheme. Creating a climate in which vendors
are perpetually uncertain if they will be accepted into evaluation does
not seem reasonable. I thought the whole point of the CC exercise was to
allow government use of COTS products and to evaluate the said products.
Any more specific requirements should be addressed in a PP generated by
the interested consumer. PPs have always been the weak link and not the
foundation they were supposed to be. (let's not go there!)
There is a separate commercial market that also realizes the value of CC
evaluations and promotes them - the financial industry for one. The
addendum and other recent policies seem to place the vendor in the
unenviable position of guessing what the CC requirements (tailored for
government) are or will be at the end of their development cycle. The
vendor is the major player here and is paying handsomely to play. Yet,
at every turn, it appears that there could be further restrictions. I
hope the whole CC process does not fade into oblivion. I have seen it
make a difference in the security of the development process of some
products and I am proud of that.
Furthermore, the critical infrastructure, first responders, DoD, other
government agencies and industry have varying requirements. Surely a CC
evaluation should serve as a basic building block for all of these
concerns and not have to be the solution to everything. The nature of CC
evaluations is assurance testing not conformance testing and there is a
big difference. If there is a need in the US government for conformance
testing then maybe a different scheme should be used for that. With a CC
evaluation you know, as the consumer, what you are getting to a specific
level of assurance and the consumer must do some kind of risk management
to accept or not accept a CC evaluated product into their environment.
The CC is fairly objective and if changes are made that introduces
subjectivity, on the vendor's part, the evaluator's part or more
importantly, on the validator's part, how will this improve the scheme?
And what service does it provide to anyone - especially the vendor who
must rise to the challenge of possibly incurring new development costs?
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Hal
Sent: March 9, 2007 10:26 AM
To: Multiple recipients of list
Subject: Re: Addendum to Policy Letter 13: Audit Generation
* PGP Signed by an unverified key: 03/09/07 at 10:20:19
As written, this should be an addendum to Policy Letter 10 (See
Sections A.4 and A.5,
Policy Letter 10). Additionally, as with Policy Letter 10, this
is an imposition by CCEVS
of security functionality upon a TOE. The previous mechanism for
the imposition of
requirements upon a TOE was called the Protection Profile (PP).
However, given the
history of the implementation of the PP paradigm, I imagine it
was deemed more
effective to use CCEVS policy edict as the mechanism to specify
requirements. Consequently for de facto PP/Policy Letter
compliance - you will
comply or your product will not be evaluated! (Note: I am
surprised that there is no
overt ASE work unit to replace ASE_PPC.1 - say maybe ASE_PLC.1
Further, as Jim pointed out the age old system engineering
concept of derived
requirements crept in with the specification of having to store
the audit data generated.
I just cannot wait to see the other unintended consequences such
as having to audit
the use of FAU_GEN.1 - the beauty of the infinite loop, or the
auditing the use of FPT_STM.1
- auditing the retrieval of the time for the timestamp of the
audit record to verify that the time
stamp on the audit record was truly in fact the time retrieved
from the HW (remember
FPT_STM.1 requires the inclusion of H/W). These examples would
be the case if the Policy
Letter was strictly adhered to - NOTE: my comparison to the PP
paradigm is not lost on this
issue either - there will have to be further clarification by
the author (the old Observation
Report/Observation Decision mechanism - author intent).
Now no one take me wrong - security is a good thing! However I
contend that the CC,
at least up to the publishing of Version 3.1, was NEVER intended
to be a specification
on HOW to implement some organization's perspective of what good
mechanisms/etc. are - read Part 1 of the CC, nowhere does it
specify that there are required
security functions. The only place that any justification for
this policy can be generated
from is the text in Paragraphs 7 and 8, CC Part 1, where the
concept of "meaningfulness"
of an evaluation is put forth. However, even in paragraph 8, the
consumer is the by definition
must be the ultimate judge.
Finally, the publishing of this addendum would appear to be
absolutely meaningless given
the current Scheme policy of accepting only medium-plus
robustness PP-compliant TOEs for
evaluation. Uh-oh, that is unless there are members of the
current crop of medium-plus robustness
PPs do not include these auditing requirements, and what a
predicament for CCEVS that
Deputy Director / Technical Director
CSC Common Criteria Testing Laboratory
7231 Parkway Drive
Hanover, Maryland 21076
This is a PRIVATE message. If you are not the intended
recipient, please delete without copying and kindly advise us by e-mail
of the mistake in delivery. NOTE: Regardless of content, this e-mail
shall not operate to bind CSC to any order or other contract unless
pursuant to explicit written agreement or government initiative
expressly permitting the use of e-mail for such purpose.
firstname.lastname@example.org wrote on 03/09/2007 08:32:53 AM:
> I have a some questions/comments about the recently posted
> Policy #13
> While the posted document doesn't have any date information,
> page indicates 1/25/2007 as a publication date. However, as of
> the addendum was still being developed and no subsequent
notice seems to
> have been proactively provided by the CCEVS. As such, I'm
> anyone happens to know when it was actually published?
> Given that the addendum doesn't provide its own terms of
> assume that it is applicable for all subsequent Evaluation
> Package submissions in accordance with Policy #13 proper. This
> consistent with the CCEVS statement (at a meeting on
1/31/2007) that the
> policy addendum would not be retroactive.
> Beyond the application of the policy addendum, I have specific
> about the addendum.
> "Every TOE is expected to provide the functionality of
> generation (i.e.
> FAU_GEN is claimed in the ST) for the auditable events
> every functional
> requirement claimed in the ST."
> This statement fairly clearly indicates that if a given TOE
> capability to audit events related to the SFRs being claimed
> TOE, claims must also be made about those auditable events.
> consistent with the objectives of Policy #13 to basically make
> evaluation more meaningful by ensuring expected functions
> unclaimed. However, the wording is not exactly right in that
it seems to
> indicate that the TOE must provide functionality that it has
> auditable events). If the TOE didn't have that functionality,
> obviously the events would not be auditable. It seems that the
> should indicate that the TOE must 'claim (in the form of SFRs)
> audit generation...' since the current statement is not
> the parenthetical. Note that I don't think the intent is to
> to add new functionality (i.e., that they don't already
> audit 'worthy' events, since Policy #13 includes no objectives
> to changing or improving products - only the claims associated
> "This need for the audit record generation is based upon the
> it is imperative that
> security events are capable of being detected and associated
> that create them.
> These events can likely be detected only by those portions of
> that provide the
> associated security functionality."
> The addendum boldly asserts that the need to audit is
> wondering whether anyone has any references to the applicable
DoD or IC
> directives, etc. requiring accountability? Such a policy
should be based
> on actual requirements and given that most policies are
applied based on
> intent as opposed to the written rules, it would be very
> understand the source of this new requirement. In particular,
I find it
> curious that it would be deemed imperative to audit 'every'
SFR. Is it
> really important for a single administrator TOE to audit
> actions? What is the imperative need for auditing ones self?
> running abstract machine or self tests? I think it definitely
> that some potentially auditable events are more important or
> than others.
> "The only exception to this is in cases where something in the
> environment can be
> reasonably expected to detect the security event and produce
> record. In such
> cases the ST must include a description of how the TOE
> expected to
> fulfill this responsibility."
> So basically this policy seems to be imposing an
> policy on behalf of every intended environment. However, this
> consistent with the stated objectives of Policy #13 to
> meaningful set of the security functionality offered by the
> there is truly some desire to impose certain organizational
> to address certain threats) across the board, the CC offers
> Profiles to accomplish that. Creating a 'stealth' Protection
> policy statement/addendum and precedent at a time is somewhat
> underhanded and is certainly not the best way to achieve
> is being sought.
> "This Addendum adds only the requirement for audit generation.
> generated audit
> records either must be stored within the TOE (FAU_STG is also
> the ST), or
> else must be off-loaded into the environment. If audit storage
> protection is to be
> provided by the environment, this must be described in ST
> Assumptions made
> by the TOE and in the Environment Description (in terms of
> for the
> Environment, and - if present - SFRs for the Environment)."
> I think it is already clear that we are talking about
> seems this addendum is identifying a flaw in the CC where
> FAU_GEN should be dependent on FAU_STG. It is curious, though,
> addendum is only concerned about generation and storage. For
> what if audit records are generated into a protected buffer in
> and that buffer is about 1MB and is continuously overwritten?
> like a whole reasonable audit solution should be expected,
> handling overflows, review, and probably selection since while
> addendum indicates perhaps lots of things should be auditable
> a great many things that are impractical to audit due to
> while this addendum indicates SFRs need to be auditable, it
does not go
> so far as to recommend an audit level and as such it seems the
> developers are free to determine for themselves what
> audit about each SFR (particularly for those SFRs where the CC
> identify anything auditable).
* Halvar W Forsberg null <email@example.com>
* Issuer: U.S. Government - Unverified
Date Index |
Thread Index |
Problems or questions? Contact firstname.lastname@example.org