RE: Addendum to Policy Letter 13: Audit Generation Functionality
Daniel says: "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."
Not quite, Daniel. SP 800-53 does have auditing controls in the initial
baselines for low, moderate, and high systems. However, these are, in
accordance with the process explicitly defined in SP 800-53, to be used
as a starting point for determining the needed controls for a given
system, not a definition of minimum requirements.
In fact, for auditing: if a given system component does not already
provide, off the shelf, the auditing capability; then the audit
requirement can be tailored out for that component if the organization
explicitly accepts any resulting impact to the indivdiuals, the
organization, its assets, other organizations, or the nation.
Moreover, there is no 'audit every security function' requirement in SP
800-53.
A fundamental difference between the NIST guidance and standards and the
DoD policy is that the former is built around the concept of requiring
an organization to explicitly define the residual risks and explicitly
accept them. The later is build around the concept of defining in
policy what consitutes 'good enough' protection and requiring that the
organization comply with this definition.
Cheers,
Gary
PS: As one of the authors of SP 800-53 Rev 1, I think I have an idea of
what it says and what it intends. :-)
************************************************************************
* Opinions are not intended to reflect an official position of JHU/APL *
************************************************************************
* Gary Stoneburner *
* Johns Hopkins University Applied Physics Laboratory *
* 11100 Johns Hopkins Road, MS 17-N406 *
* Laurel, MD 20723-6099 *
* Phone: 240-228-2628 (WA DC), 443-778-2628 (Baltimore) *
* Fax: 240-228-6391 (WA DC), 443-778-6391 (Baltimore) *
* Gary.Stoneburner@jhuapl.edu *
************************************************************************
-----Original Message-----
From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Daniel P.
Faigin
Sent: Friday, March 09, 2007 10:44 AM
To: Multiple recipients of list
Subject: Addendum to Policy Letter 13: Audit Generation Functionality
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.
Date Index |
Thread Index |
Problems or questions? Contact list-master@nist.gov