RE: Addendum to Policy Letter 13: Audit Generation Functionality
Title: Message
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
*
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