RE: PD 0131: Create Object Audit Event and CAPP Compliance
I've been listening and the last comment leads to this comment.
CAPP is, as the PD says, the CC rendition of TCSEC C2, a 20 year old
requirement set. In computer years that's ancient, there was no
Internet 20 years ago - local LANs were uncommon as well, and C2 says
little about networking.
If the capability claim is only compliance with a 20 year old
requirement set - well, that's really not much of a claim; especially
since that 20 year old requirement set was only intended for benign
environments :-).
While 'what does PP compliance mean?' is important for evaluation
against a claim of PP compliance; perhaps even more important is what
makes sense for achieving the security quality necessary to meet any
other capability claims for the ST.
Cheers,
Gary
PS: Seems like a point of diminishing returns and cost-ineffectiveness
would be reached pretty soon in an expenditure of evaluation effort
against a 20 year old requirement set intended only for benign
environments without consideration for networking and today's Internet.
************************************************************************
* 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 YOKOTA
HIROFUMI
Sent: Monday, February 26, 2007 3:41 AM
To: Multiple recipients of list
Subject: Re: PD 0131: Create Object Audit Event and CAPP Compliance
Let me correct my previous message.
I was saying "nice to have" interpretation. It was wrong.
In the seriousness of handling the CAPP interpretation, I agree that we
must interprete the CAPP along with the exact wording and your past
practice.
Regards,
Hirofumi Yokota.
----- Original Message -----
From: YOKOTA HIROFUMI <mailto:yokota-hirofumi@jqa.jp>
To: Multiple recipients of list <mailto:cc-cmt@nist.gov>
Sent: Monday, February 26, 2007 4:58 PM
Subject: Re: PD 0131: Create Object Audit Event and CAPP
Compliance
Nevertheless, auditing object creation would not be a bad idea.
If a threat on a subject ( might be an untrusted user) is
defined in the ST and assumed to be countered by the audit, it could be
justified.
Even if such a threat is not defined in the ST, yet, the audit
could help the analysis when mal-functions are observed regarding the
relavant operation.
So, it seems to me, auditing object creation is useful and
practical to interprete as a CAPP requirement.
Regards,
Hirofumi Yokota
----- Original Message -----
From: Nir Naaman <mailto:nir.naaman@metasec.com>
To: Multiple recipients of list <mailto:cc-cmt@nist.gov>
Sent: Sunday, February 25, 2007 12:54 AM
Subject: RE: PD 0131: Create Object Audit Event and CAPP
Compliance
I agree with Helmuth Kurth and Jim Arnold that object
creation is not necessarily required to be audited by CAPP.
The PD notes that the C2 requirements required the
auditing of the introduction of an object into a process's address
space. Helmut Kurth retorts that there could be systems where a named
object might be created without introducing it into the user's address
space. This is certainly conceivable, and assuming anybody can create a
named object (i.e. object creation is not controlled under FDP_ACF.1)
and that the object is created with default security attributes (i.e. is
not audited for FMT_MSA.3), a 'create object' operation without a
corresponding 'open object' operation is not required to be audited.
Named objects are those objects which are used to share
information among subjects acting on the behalf of different users, and
for which access to the object can be specified by a name or other
identity.
The PD is clearly basing the requirement for auditing of
the named object creation not on the object in question, but is
operating under the assumption that for a named object to be created,
another object must be modified to reference the newly created object,
and furthermore, that that other referencing object is covered by the
DAC policy (and therefore its modification must be audited).
This assumption is noted in both the PD Resolution:
"Object Creation is an operation that requires an access right (because
not everyone can create everywhere)", and in the issue discussion
itself: "Even if one takes the position that the formal object does not
yet exist, the act of creating of the object makes changes in security
attributes and values of TSF data, in particular the TSF data contained
in the directory that contains the newly created object(which itself is
the subject of an open and close)"
Strictly speaking, the only thing required to be audited
in this case is that an object was created in an identified directory,
but not which object. Still, with respect to published PPs, PDs are
considered authoritative corrections to the PP, so I read this as the
point of the PD - that the identity of the created object must also be
audited.
However, where a subject creates a named object in a
global namespace that is not access-controlled, and where the subject
does not perform any further controlled operations on that object, I
don't believe this scenario is covered by this PD, and therefore object
creation in this scenario is not required to be audited. This should be
true even if the object creation operation provided the default user
data contained in the object as an atomic operation, i.e. did not
require the subject to introduce the object into the user's address
space after it was created.
Nir
________________________________
From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov]
On Behalf Of Helmut Kurth
Sent: Friday, February 23, 2007 11:18 PM
To: Multiple recipients of list
Subject: Re: PD 0131: Create Object Audit Event
and CAPP Compliance
I agree with Jim Arnold. The TCSEC deliberately
talks about the "introduction of objects into a user's address space
(e. g. file open, program initiation)" as the events that are required
to be audited. I think the use of this terminology was deliberate. Look
also into section 5.3.2 of the Orange Book, which states for
accountability:
The third requirement is for dependable
audit capabilities. That
is, a trusted computer system must
provide authorized personnel
with the ability to audit any action
that can potentially cause
access to, generation of, or effect the
release of classified or
sensitive information.
Auditing here is clearly restricted to actions
that may provide unauthorized access to information. Whenever the
creation of an object also implies that it is introduced into the user's
address space and made accessible, I agree that this event needs to be
auditable at the C2 level. However in systems where those are different
events, I think the Orange Book at C2 only required the event of
"introducing the object into the user's address space" to be audited,
since this would allow to place information into the object and
therefore requires to be controlled by the access control policy. There
are systems where the two events are clearly separated and also subject
to different policies. In some of those systems, object creation is not
be restricted at all (i. e. is not an operation covered by the DAC
policy as defined in the FDPACC.1 requirement in CAPP), but access to
the object is, which may result in the situation where a newly created
object is not accessible by the user that created it. In those systems -
when looking at the C2 requirements - there is no potential access to,
generation of or release of sensitive information associated with the
generation of the object and the object is also not introduced into the
creator's address space. My interpretation of the C2 requirements of the
Orange Book is that in those systems the creation of objects does not
need to be audited.
Arnold, James L. Jr. wrote:
RESOLUTION
The CAPP was the created as the
CC version of the C2
requirements expressed in the
Orange Book (as the LSPP
recasts B1), which requires
object creation as auditable event.
I don't think the TCSEC actually
identifies object creation as an
auditable event.
The CAPP covers "all operations"
of controlled objects where
there need to be access rights.
Object Creation is an
operation that requires an
access right (because not everyone
can create everywhere).
Therefore, Creation is in the set of
"all operations" and should be
audited.
I don't think it is necessarily the case
that object creation requires
an access right or that object creation
is limited to specific users. I
can imagine many cases where objects can
be freely created by subjects
and access decision are made only for
subsequent attempts to open the
existing object. While there are
certainly examples where object
creation is a controlled operation I
don't think it is necessarily
always the case as suggested here.
RATIONALE
In general, the creation of an
object alters TSF data (values
or attributes) and allocates
resources, each action requiring
an appropriate access right.
The CAPP, in attempting to audit
"all operations" must then
include with these other audited
operations, the actual
instantiation of new objects.
I'm not sure about the altering TSF data
statement. I suppose TSF data
somewhere would almost certainly be
affected, but as indicated above, it
seems there could be cases where no
security restrictions are imposed
for object creation.
It is not necessarily clear what the
whole point is. The CAPP indicates
that users should be accountable for
their actions. Presumably that is
limited to security related actions,
perhaps meaning actions that are
otherwise restricted. Unfortunately I
think audit is mistreated in
general since auditing subject actions
may be distinct from auditing
user actions and, in deed, it may be
hard to discern users actions from
even a long list of subject actions. I'm
thinking that there may be
certain non-persistent objects where
there creation isn't particularly
interesting from a security perspective
and the simple creation thereof
really is not indicative of any security
relevant user behavior.
--
Helmut Kurth, atsec information security
www.atsec.com
Date Index |
Thread Index |
Problems or questions? Contact list-master@nist.gov