Re: Universal vs. Environmental Policy, and the "vulnerability" term

[Dave Mann <damann@mitre.org>]

Pascal Meunier wrote:
> Let me define macrovulnerabilities as
> vulnerabilities that arise from the assembly of services, hardware and
> software in a specific environment, while each of those individually does
> what it is supposed to do and nothing else.
[snip...]
> Are services unsecure because they contain vulnerabilities, or because they
> are ill-designed services for which no implementation can ever be secure?
> In the first case, there should be a CVE entry for those vulnerabilities
> but not the service.  If having the latter kind running allows someone to
> circumvent other common policies, then the service is a macrovulnerability.
> I think that services falling in this category deserve a CVE entry.  In
> such a case I believe that there can be a one-to-one mapping between a
> macrovulnerability and low-level policy.

I think the case can be made that the pressence of certain
services or applications represent what you are calling
a macrovulnerability.  Allow me to present an example
suggested by a collegue.

Suppose we have a system that is running telnet (or
finger or some other well-known service) and further
suppose that the version of telnet does not have any
vulnerabilities under the strict understanding of the
word.  That is, suppose that telnet behaves precisely
the way it is supposed to.  In this case, telnet still
presents a vulnerability -- Since it is so well understood
and since TCP itself has inherent weaknesses, telnet is
subject to attacks such as hijacking.

Note, the vulnerability here resides in large measure
with the fact that telnet is so well known.  Consider,
in contrast, a custom built data exchange protocol to
support a database application.  Provided that the
specifications for this custom built protocol are not
known, there is very little chance that a hacker could
hijack the session.

Again, we see that the vulnerability of the service running
on TCP/IP resides in the knowledge of how the service
works.  I think we can agree that decisions about vulnerabilities
should be based on facts about the systems involved.  Despite
the fact that this may move us into an uncomfortable "best
practices" definition of vulnerability, I note that the
consideration of the relative knowledge of a service and it's
relative popularity with hackers are still facts about
the service.  This is what leads me to consider telnet
to be a (potential) vulnerability (relative to policy).

Dave

--



=========================================================
David Mann                     ||  phone: (781) 271 - 2252
INFOSEC Engineer/Scientist, Sr ||
Enterprise Security Solutions  ||    fax: (781) 271 - 3957
The MITRE Corporation          ||
Bedford, Mass 01730            || e-mail: damann@mitre.org