Re: Addendum to Policy Letter 13: Audit Generation Functionality

[Hal W Forsberg <hforsber@csc.com>]

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).
> 
> 
>

S/MIME Cryptographic Signature