RE: CONTENT DECISION: Presence of Services or Applications (SA)

["Prosser, Mike" <mike.prosser@L-3SECURITY.COM>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave,
I am not saying don't check for a service running, we do.  I believe
Aleph One says it best when he said it is a risk vice an actual
vulnerability.  A client may not even realize they are running a
particular "risky" service, or they may be fully aware of it and need
it for their business.  All a scanner does by checking for the service
is alert the user to the fact the service is running.  Speaking for
myself, not for other vendors,  having a "risky" service running or
not is a decision that the client has to make based on their needs.
We try to provide them with all the options to make that decision.
All part of risk management.
- -mike

- -----Original Message-----
From: Dave Mann [mailto:damann@MITRE.ORG]
Sent: Wednesday, August 04, 1999 4:38 PM
To: cve-editorial-board-list@lists.mitre.org
Subject: Re: CONTENT DECISION: Presence of Services or Applications
(SA)


> > On Tue, Aug 03, 1999 at 08:52:05PM -0500, Gene Spafford wrote:
> > > I really do not like the idea behind this category.
[snip...]

> On Wed, Aug 04, 1999 at 02:55:52PM -0500, Prosser, Mike wrote:
> > I agree with these comments as well!  Unless there is an actual
> > vulnerability related to one of these services, don't see them as
> > being CVE material just by running.  This becomes a "best
practice" or
> > company policy decision rather than a vulnerability.

Aleph One wrote:
> I belive this what the words you are looking for is vulnerability vs
> risk. A service running is a risk. Not a vulnerability.


Mike, I am surprised to hear a tool vendor saying this and I
would very much like to hear the input of other tool vendors on
this one.  As a consumer of security tools, I note that security
tools most often report on things like the existence of finger
on a system.

As someone working on managing enterprise security (a different
hat from research, tool production or vulnerability discovery)
I can assure you that I NEED to be able to manage information
about the unintended presence of services or applications.
I insist that my tools be able to discover these things and
I demand that my tools be able to interoperate at this level.
This is, in fact, precisely the reason why we proposed the
idea of the CVE in the first place.

Mike and the other tool vendors, please note
that if we adopt a more narrow (and perhaps more accurate)
definition of vulnerability, then a lot of the security checks
performed by your tool(s) will not correlate to any CVE entry.
This, in turn, will undercut one of our primary goals of the
CVE which is to foster tool interoperability.

It turns out that we are discussing this issue here at MITRE
currently.  We are formulating a possible long term approach
for handling this problem.  Being more precise about the
semantics and definitions may play a role, as Elias
and Spaf have alluded to. In the mean time, I would strongly
urge others to weigh in on this issue.

As always, eagerly anticipating the input of all,

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

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQA/AwUBN6nYtBIUaHPadf5hEQLclQCffioNXxoVrzyq57gVr+wUdC3NmSMAn0pM
jOjx8/FqvdzfTbvHdcnGsN1X
=BmuK
-----END PGP SIGNATURE-----