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.
Cheers,
Gary
************************************************************************
* 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 *
************************************************************************
-----Original Message-----
From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] 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
Functionality
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
discussed.
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?
Dawn Adams
CC Evaluator
EWA-Canada
dadams@ewa-canada
-----Original Message-----
From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Hal
W Forsberg
Sent: March 9, 2007 10:26 AM
To: Multiple recipients of list
Subject: Re: Addendum to Policy Letter 13: Audit Generation
Functionality
* 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
NSA security
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
(Policy Letter
Compliance).
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
security practices/
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
could/should be.
Halvar Forsberg
Deputy Director / Technical Director
CSC Common Criteria Testing Laboratory
7231 Parkway Drive
Hanover, Maryland 21076
(443) 445-8445
hforsber@csc.com
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------------
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.
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------------
cc-cmt@nist.gov wrote on 03/09/2007 08:32:53 AM:
>
> I have a some questions/comments about the recently posted
addendum to
> Policy #13
>
(http://www.niap-ccevs.org/cc-scheme/policy/ccevs/policy-ltr-13_addendum
> _v2.pdf).
>
> While the posted document doesn't have any date information,
its hosting
> page indicates 1/25/2007 as a publication date. However, as of
1/31/2007
> the addendum was still being developed and no subsequent
notice seems to
> have been proactively provided by the CCEVS. As such, I'm
wondering if
> anyone happens to know when it was actually published?
>
> Given that the addendum doesn't provide its own terms of
application, I
> assume that it is applicable for all subsequent Evaluation
Acceptance
> Package submissions in accordance with Policy #13 proper. This
would be
> 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
comments
> about the addendum.
>
> "Every TOE is expected to provide the functionality of
security audit
> generation (i.e.
> FAU_GEN is claimed in the ST) for the auditable events
associated with
> every functional
> requirement claimed in the ST."
>
> This statement fairly clearly indicates that if a given TOE
has the
> capability to audit events related to the SFRs being claimed
about that
> TOE, claims must also be made about those auditable events.
This seems
> consistent with the objectives of Policy #13 to basically make
the
> evaluation more meaningful by ensuring expected functions
don't go
> unclaimed. However, the wording is not exactly right in that
it seems to
> indicate that the TOE must provide functionality that it has
(i.e.,
> auditable events). If the TOE didn't have that functionality,
then
> obviously the events would not be auditable. It seems that the
statement
> should indicate that the TOE must 'claim (in the form of SFRs)
security
> audit generation...' since the current statement is not
equivalent to
> the parenthetical. Note that I don't think the intent is to
require TOEs
> to add new functionality (i.e., that they don't already
implement) for
> audit 'worthy' events, since Policy #13 includes no objectives
related
> to changing or improving products - only the claims associated
with
> products.
>
> "This need for the audit record generation is based upon the
fact that
> it is imperative that
> security events are capable of being detected and associated
with users
> that create them.
> These events can likely be detected only by those portions of
the TSF
> that provide the
> associated security functionality."
>
> The addendum boldly asserts that the need to audit is
imperative. I'm
> 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
helpful to
> 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
administrator
> actions? What is the imperative need for auditing ones self?
What about
> running abstract machine or self tests? I think it definitely
the case
> that some potentially auditable events are more important or
interesting
> than others.
>
> "The only exception to this is in cases where something in the
TOE
> environment can be
> reasonably expected to detect the security event and produce
the audit
> record. In such
> cases the ST must include a description of how the TOE
environment is
> expected to
> fulfill this responsibility."
>
> So basically this policy seems to be imposing an
organizational security
> policy on behalf of every intended environment. However, this
is not
> consistent with the stated objectives of Policy #13 to
evaluate a
> meaningful set of the security functionality offered by the
TOE. If
> there is truly some desire to impose certain organizational
polices (or
> to address certain threats) across the board, the CC offers
Protection
> Profiles to accomplish that. Creating a 'stealth' Protection
Profile one
> policy statement/addendum and precedent at a time is somewhat
> underhanded and is certainly not the best way to achieve
whatever goal
> is being sought.
>
> "This Addendum adds only the requirement for audit generation.
These
> generated audit
> records either must be stored within the TOE (FAU_STG is also
claimed in
> the ST), or
> else must be off-loaded into the environment. If audit storage
and
> protection is to be
> provided by the environment, this must be described in ST
under the
> Assumptions made
> by the TOE and in the Environment Description (in terms of
Objectives
> for the
> Environment, and - if present - SFRs for the Environment)."
>
> I think it is already clear that we are talking about
generation. It
> seems this addendum is identifying a flaw in the CC where
seemingly
> FAU_GEN should be dependent on FAU_STG. It is curious, though,
that this
> addendum is only concerned about generation and storage. For
example,
> what if audit records are generated into a protected buffer in
the TOE
> and that buffer is about 1MB and is continuously overwritten?
It seems
> like a whole reasonable audit solution should be expected,
including
> handling overflows, review, and probably selection since while
this
> addendum indicates perhaps lots of things should be auditable
there are
> a great many things that are impractical to audit due to
volume. Also,
> 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
specifically to
> audit about each SFR (particularly for those SFRs where the CC
doesn't
> identify anything auditable).
>
>
>
* Halvar W Forsberg null <hforsber@csc.com>
* Issuer: U.S. Government - Unverified
Date Index |
Thread Index |
Problems or questions? Contact list-master@nist.gov