Re: PROPOSAL: Cluster 19 - NTCONFIG (13 candidates)

["Steven M. Christey" <coley@linus.mitre.org>]

Craig Ozancin said:

>=================================
>Candidate: CAN-1999-0576
>Published:
>Final-Decision:
>Interim-Decision:
>Modified:
>Announced: 19990721
>Assigned: 19990607
>Category: CF
>
>A Windows NT system's file audit policy does not log an event success
>or failure for security-critical files or directories.
>
>VOTE: Modify
>
>Some files and directories are clearly understood to be critical. Others are
>unclear. We need to clarify that critical is.

I intentionally kept the definition of "critical" fairly vague since
the terminology for configuration isn't as well established as it is
for software bugs.  There's no term for a type of configuration error
that has the same universality and compactness as "buffer overflow" or
"race condition," for example.  I don't think it's the role of the CVE
to define or establish terminology in these areas, but on the other
hand, now could be a good opportunity.  The same rationale applies to
my use of the term "inappropriate."

That said, I would define a critical file in terms that are strongly
related to the "universally accepted" portions of the CVE definition.
A critical file is one in which inappropriate access to it allows an
attacker to gain Leveraged Access, i.e. additional privileges or
access to data that they're not supposed to have, or to hide their
attempts to do so.  That is:

  A critical file is one which, if accessible to a non-administrator,
  either:
  - allows an entity to bypass the system's normal authentication
    and verification processes to execute arbitrary commands as
    another entity
  - allows an entity to pose as another entity without formal or
    informal authorization
  - allows an entity to affect the computing system in a way which
    disrupts the activities of other entities
  - allows an entity to prevent or limit the tracking of
    activities which attempt to exploit another vulnerability
  - allows an entity to obtain information that increases the
    likelihood for exploiting other vulnerabilities

In the Unix model, the password file satisfies this definition, since
its modification allows bypassing the normal authentication process,
and as a rule, even being able to read the password file is sufficient
to gain access.  Any .rhosts, .login, .cshrc, cron/at script, etc. is
critical since their modification would allow execution of commands as
another user.  Most log files are critical since their modification
could allow someone to hide their activities.

Something that's not critical might be, say, a user's mail spool, or a
file system that contains data but is not related to the configuration
of the server itself.  It may be extremely important to the owner of
that data, but access to it will not necessarily allow an attacker to
gain additional access.

In my view, this definition of "critical" acts as a discriminator
between what is truly dangerous from a computer security policy
perspective, versus what shouldn't be accessible because of an
information policy (e.g. limiting access to corporate secrets may not
be a requirement of a computer security policy).  One of the
challenges that I see security assessment tools facing, is in
appropriately discriminating between what data is security-critical
versus what is information-critical.  If NFS exports a password file,
that's security-critical; if it exports a CD-ROM, it (probably) isn't.
So it depends on whether the data is associated with administration of
the system itself, versus what data the system is being used to
process.

- Steve