Actually, this statement was amended in a later Industrial Security
Letter...
The comments from the ISL have been incorporated into our NISPOM docs
and include the following:
8.602. Audit Capability
(c) Successful and unsuccessful accesses to security-relevant
objects and directories, including creation, open, close,
modification, and deletion.
55. Question: Paragraph 8-602a(1)(c) can generate upwards to 100
audit entries for each successful access to security-relevant
objects and/or directories. From a security standpoint, is this
information of enough importance to generate voluminous amounts of
auditing data?
Answer: No. Only unsuccessful accesses need to be audited.
Now I can easily imagine that Sarbanes-Oxley or HIPPA may require
auditing successful accesses to SROs, but the NISPOM no longer requires
it...
-Randy Zagar
[EMAIL PROTECTED] wrote:
Date: Fri, 26 Jan 2007 15:14:10 -0500
From: "Wieprecht, Karen M." <[EMAIL PROTECTED]>
Subject: RE: close(2) not being audited?
To: "Steve Grubb" <[EMAIL PROTECTED]>, <[email protected]>
Cc: "Todd, Charles" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Actually, the exact wording says:
"Successful and unsuccessful accesses to security-relevant objects and
directories"
It does not specify exactly how that should be collected, but the
NISPOM does request that the audit record include who tried to access
it, what they tried to access, the time and date of the access attempt,
what command they were trying to run (rm, chmod, etc.), and if they
were successful or not. What happens behind the scenes after the
operating system takes over the request may not be of as much interest
unless collecting that info helps to provide the above details to the
audit record.
-Karen Wieprecht
--
Randy Zagar Sr. Unix Systems Administrator
E-mail: [EMAIL PROTECTED] Applied Research Laboratories
Phone: 512 835-3131 Univ. of Texas at Austin
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
