Addendum to Policy Letter 13: Audit Generation Functionality

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

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