RE: Addendum to Policy Letter 13: Audit Generation Functionality

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

I appreciate the argument that the products should meet the DoD
requirements.
Producing products that serve CCEVS customers who pay the bills definitely
needs to be a major consideration.
However, if available security products do not include these features and
the DoD still wants or needs the product, wouldn't it be better to have the
product evaluted by CCEVS than to not have that product evaluated because it
does not audit everything?

I'm not sure CCEVS policies are the correct place to mandate security
features for products that are produced in the general marketplace.
The use of PPs and RFCs appear to be a better mechanism for mandating
security featuers in products to be used by the DoD.

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


-----Original Message-----
From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Daniel P. Faigin
Sent: Friday, March 09, 2007 11:38 AM
To: Multiple recipients of list
Subject: RE: Addendum to Policy Letter 13: Audit Generation Functionality


On Fri, 9 Mar 2007 12:11:13 -0500 (EST), "Williamson, Robert L. Jr."
<ROBERT.L.WILLIAMSON.JR@saic.com> said:

> It appears to me that the purpose of audit seems missing in this
> discussion. Furthermore, I believe all Government requirements require
> some interpretation.

In the case of the 8500.2 requirements, you should look at the DIACAP
Knowledge Base. That defines the validation procedures to establish whether
a
system (and I use that word intentionally, as opposed to "product") is
compliant with a control. 

Of course, you'll easily discover problems with those procedures. I have,
and
and working on some white papers to highlight those problems and work them
to
resolution (this is all non-CC stuff).

(I'm getting on my soapbox here, and this is more with a C&A hat on than any
CCEVS related hat)

If the goal is to have CCEVS validate products that serve the customers who
are paying their bills, control compliance should be considered. The
products
should serve to support the ability of the overall system to meet the
controls. For example, if passwords are used, the system should provide the
ability to enforce that DoD-password rules are enforced (see control
IAIA). Otherwise, usage of the product in the DoD creates difficulties and
requires waivers. Similarly, if the product provides auditing, it should
audit
at a level suitable to provide the information required in the ECAR
controls.

(climbs down off soapbox)

Daniel