[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CONTENT DECISION: Distinctive descriptions to support lookup

Adam Shostack said:

| =================================
| Candidate: CAN-1999-0534
| Published:
| Final-Decision:
| Interim-Decision:
| Modified:
| Announced: 19990721
| Assigned: 19990607
| Category: CF
|
| A Windows NT user has inappropriate rights or privileges, e.g. Act as
| System, Add Workstation, Backup, Change System Time, Create Pagefile,
| Create Permanent Object, Create Token Name, Debug, Generate Security
| Audit, Increase Priority, Increase Quota, Load Driver, Lock Memory,
| Profile Single Process, Remote Shutdown, Replace Process Token,
| Restore, System Environment, Take Ownership, or Unsolicited Input.
|
| VOTE:modify, don't list privs, except perhaps eg.:
|
| =================================
| Candidate: CAN-1999-0575
| Published:
| Final-Decision:
| Interim-Decision:
| Modified:
| Announced: 19990721
| Assigned: 19990607
| Category: CF
|
| A Windows NT system's user audit policy does not log an event success
| or failure, e.g. for Logon and Logoff, File and Object Access, Use of
| User Rights, User and Group Management, Security Policy Changes,
| Restart, Shutdown, and System, and Process Tracking.
|
| VOTE: modify, vigorous CVE entries are concise.
|

The reason that these entries contain such information is partially
historical, but there are some significant benefits to leaving this
information there.  When I was doing my tool mappings, the tools would
often list the specific privilege/event names, and my search script
would pick up on that and quickly find the appropriate CVE entry.

Without this information, what terms can be used to effectively look
up the name of these vulnerabilities?  For CAN-1999-0534, looking for
"privilege" might work - but there are already 8 vulnerabilities that
have reached Final Decision that use that term!  And there are 20 or
more candidates that use the same term as well.  So, a mapper would be
presented with 30 or more potential candidates, just to look up the
name for one vulnerability.

When you're trying to map hundreds of vulnerabilities, looking through
30 candidates is time consuming.  Mapping is still a bottleneck, even
with automated support.  Even with the advanced search script that I
use, sometimes the vulnerability I'm really looking for isn't in the
top 5.

The problem is twofold.  For software flaws, one of the most effective
keywords is the application name.  But most configuration problems in
the CVE right now are related to configuration at the OS or host
level, not for specific applications.  But the name of the affected OS
does not sufficiently discriminate between all vulnerabilities,
especially if the search also includes software flaws.  So, the
specific configuration option becomes the most effective
discriminator.

The second problem, and a much more significant one, is the lack of an
established terminology to describe different types of configuration
problems.  For software flaws, if the appplication name isn't enough
to discriminate between vulnerabilities (e.g. for Sendmail or IIS or a
number of other applications), then the type of vulnerability may help
to narrow the search (buffer overflow, etc. - but observe that even
"buffer overrun" is still used).  But that isn't possible for
configuration problems since there isn't an established terminology.

It turns out that the CVE category can play a role in the lookup of a
CVE name, not just in determining what content decisions to apply.  I
often use a specialized keyword search script that allows me to narrow
my search to a specific category, which can reduce the overload
significantly.  It makes a big difference when mapping more than a few
vulnerabilities.

Because of these reasons, I believe that some CVE descriptions -
especially with respect to configuration problems - should contain
more information than is absolutely necessary, in order to support
lookup.  If/when appropriate terminology emerges to effectively
discriminate between such vulnerabilities, then we can adjust the
descriptions accordingly.  Obviously, a well-defined and commonly
accepted taxonomy would be very useful in this situation.

I touch on this and related issues in the "Content Decisions" and
"Expected Problems with CVE Content" sections of the tech paper.  Note
that I'm not advocating placing additional structure into the CVE, but
we should make sure that we write our descriptions with lookup
requirements in mind.

- Steve
Page Last Updated or Reviewed: May 22, 2007