Addendum to Policy Letter 13: Audit Generation Functionality

["Daniel P. Faigin" <faigin@aero.org>]

I'm not going to address all of Jim's point, but I will answer one question.

On Fri, 9 Mar 2007 08:32:53 -0500 (EST), "Arnold, James L. Jr."
<JAMES.L.ARNOLD.JR@saic.com> said: 

> 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? 

Sure. Current DoD IA Policy is defined by DoDD 8500.1 and DoDI 8500.2. 8500.1
is high-level policy; it is captured in controls that apply to systems. These
controls are defined in DoDI 8500.2. You should be able to obtain copies from
http://iase.disa.mil/, or just do a web search. The appropriate controls are
selected based on the mission criticality and the information handled. With
respect to Audit, the following controls are of interest:

ECAR-1 Audit Record Contents (Public-Rel)

Audit records include:

*	User ID.
*	Successful and unsuccessful attempts to access security files.
*	Date and time of the event.
*	Type of event.

ECAR-2 Audit Record Contents (Sensitive) 

Audit records include:
*	User ID.
*	Successful and unsuccessful attempts to access security files.
*	Date and time of the event.
*	Type of event.
*	Success or failure of event.
*	Successful and unsuccessful logons.
*	Denial of access resulting from excessive number of logon attempts.
*	Blocking or blacklisting a user ID, terminal or access port and the
	reason for the action. 
*	Activities that might modify, bypass, or negate safeguards controlled
	by the system. 

ECAR-3 Audit Record Contents (Classified)

Audit records include:
*	User ID.
*	Successful and unsuccessful attempts to access security files
*	Date and time of the event.
*	Type of event.
*	Success or failure of event.
*	Successful and unsuccessful logons.
*	Denial of access resulting from excessive number of logon attempts.
*	Blocking or blacklisting a user ID, terminal or access port, and the
	reason for the action. 
*	Activities that might modify, bypass, or negate safeguards controlled
	by the system. 
*	Data required to audit the possible use of covert channel mechanisms.
*	Privileged activities and other system-level access.
*	Starting and ending time for access to the system.
*	Security relevant actions associated with periods processing or the
	changing of security labels or categories of information. 

ECAT-1 Audit Trail Monitoring, Analysis, and Reporting (MAC-III, Sensitive, Public-Rel)

Audit trail records from all available sources are regularly reviewed for
indications of inappropriate or unusual activity. Suspected violations
of IA policies are analyzed and reported in accordance with DoD
information system IA procedures. 

ECAT-2 Audit Trail Monitoring, Analysis, and Reporting (MAC-I, MAC-II, Classified)

An automated, continuous on-line monitoring and audit trail creation
capability is deployed with the capability to immediately alert personnel of
any unusual or inappropriate activity with potential IA implications, and with
a user configurable capability to automatically disable the system if serious
IA violations are detected. 

There are more controls that address audit in other areas, such as how long
audit is maintained, where records are stored, etc.

For civil (non DoD Government) there are similar requirements captured in NIST
800-53, which is also control based. Satisfaction of these controls is a
requirement of FISMA, and FISMA compliance is required. 

Personally, I think it is important that products of NSA be suitable to serve
NSA customers, who are the DoD and US Government, and thus should support
compliance with applicable controls.