RE: Addendum to Policy Letter 13: Audit Generation Functionality

["Michelle Ruppel" <maruppel@saffiresys.com>]

My statements below assume that the intent of the Addendum is to require that all TOEs claim FAU_GEN.1 or an explicit requirement that is an equivalent and that the TOE generate audit records for all auditable events associated with ALL TOE SFRs.

 

I'm concerned about the impact of requirement. I agree that, in most cases, all products should audit. However, I imagine that there are situations where that may not be desired or feasible and exceptions may be needed.

 

I believe that many of the products on the EVP do not perform audit generation for all auditable events associated with all of their TOE SFRs. Does this mean that these products will not be able to renew their certification with CCEVS for new versions of the product? What happens if a DoD customer wants a product evaluated that does not meet this CCEVS requirement?

 

Has any research been performed to determine how many products on the market that are used by DoD actually meet this requirement for extensive auditing?

I'm concerned that this new requirement will greatly reduce the number of products that can obtain a CC certification from CCEVS. I'm not convinced that most of the security products on the market today and in use by DoD meet this extensive auditing requirement. Assuming that is correct, is the intent to not allow these product to obtain CC certification from CCEVS?

 

Michelle Ruppel
Saffire Systems
maruppel@saffiresys.com
217-359-7763

---

From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Hal W Forsberg
Sent: Friday, March 09, 2007 9:26 AM
To: Multiple recipients of list
Subject: Re: Addendum to Policy Letter 13: Audit Generation Functionality

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