Re: PD 0131: Create Object Audit Event and CAPP Compliance

[Olin Sibert <osibert@orionsec.com>]

Another argument from over 20 years ago rears its ugly head.
At least, I think I first encountered it in 1983, and I doubt
it was young even then--and the rationale followed pretty
much the same reasoning: "That's what the words say, and even
though we don't have a good technical argument for them, we
have to do what the words say, and invent convoluted reasons
for why the words must have been written that way, because,
well, that's what the words say".  At least in the 1985
edition of the TCSEC, the Audit requirement was amended to
require auditing "other security-relevant events".

However, rather than micro-analyzing the words of authors
decades gone writing about technologies far less diverse
than today's, it might be useful to consider this issue from
viewpoints like:
  - Does it support the goals of auditing?
  - Does it provide a valuable facility?
  - Does it simplify compliance?
  - Is it unreasonably burdensome?

The "pro" side of the argument says that object creation
should be audited so that the analyst (or analysis program)
can understand the complete life-cycle of the object--for
example, when, by whom, and how was it created?  Did the
same user/subject create it as subsequently used it?  Was
it created immediately before use, or did it lie in wait
hoping that someone would stumble upon it?  (Note that the
latter situation has been the root cause of quite a few
exploitable OS vulnerabilities over the years.)

While it's true that none of those questions directly
relate to unauthorized disclosure of information, I think
it's very hard to argue that they are forensically
irrelevant.  Indeed, it's hard to see how most audit
data "directly relates" to unauthorized disclosure, since
if the information flow was actually unauthorized, the
access control mechanisms would most likely have prevented
it in the first place!  Much of the value in audit data is
to support a chain of inferences about unauthorized
_behavior_, not disclosure as such.

Also, as Unix veterans know, creation is also often by far
the most convenient time to associate a human-meaningful
name with the object--a subsequent "introduction into the
address space" may only provide a system-meaningful
identifier that is challenging (at best) to translate
to something that a human can interpret.  A previous
creation event can be an essential tool for making that
association.

Audit is a balancing act: you want to collect information
that has value but not so much information as to make the
audit data unacceptably expensive to store and process.
Since you don't know, when you're collecting it, how it
will be used and by whom, the designer (and specifier)
should generally err on the side of caution, and be
guided by potential utility.

In this case, does the implementation or operational
burden outweigh the potential utility?  Are there
sufficiently numerous examples where this requirement
might be unreasonably burdensome to warrant rejecting the
requirement, without being able to make similar arguments
for other audit requirements?  Those seem like the real
issues here.

Cheers -- Olin Sibert