|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Survey: Use of Same Attack/Same Codebase content decision in VDB's
Keep in mind that system vulnerabilities won't show up on a network intrusion detection system in most cases. They will show up on host-based IDS systems either in the event logs when a vulnerability is exploited or present through static analysis. Steve N. is correct about the network side but it's a different story on the host-based side. False positives are less of an issue on the host-based side because of the nature of the signatures. They are not usually "string matches" but deterministic sequences of events. I'm not entirely sure what this adds to the conversation but I wanted to point out the differences before conclusions were drawn from Steve N's comments alone. Basically, vulnerabilities are primarily system-based and should be addressed by system level IDS (in most, not all cases). Any given vulnerabilty can be detected by multiple signatures. For example the Cybersafe Centrax product has a signature on NT to detect a base-class of attack exploited by sec-hole and getadmin. These are different attacks exploiting the same hole (unauthorized addition of a user to the administrator's group). My view is that all three are CVE worthy. 1) sechole, 2) getadmin, 3) unauthorized addition of a user to the administrator's group. 1 and 2 are published exploits. 3 is sure to be used by other attacks in the future. One of the disconnects between the host-based ID and the CVE is that vulnerability exploitation is only one aspect of monitoring. We also monitor for behavior deviations, trends, and patterns of misuse such as abuse of privilege. I've been wondering if the CVE will attempt to address these or just stick with known vulnerabilities. Paul ************************************************************* Paul E. Proctor Senior Scientist Corporate Technology - Cybersafe Corporation 6363 Greenwich Drive, Suite 150 San Diego, CA 92122 Tel: (Direct) +619-546-2400 x312; Fax: +619-546-0590 Email: paul.proctor@cybersafe.com ************************************************************* > -----Original Message----- > From: Steven M. Christey [SMTP:coley@linus.mitre.org] > Sent: Thursday, July 01, 1999 9:56 AM > To: cve-review@linus.mitre.org > Subject: Re: Survey: Use of Same Attack/Same Codebase content > decision in VDB's > > > The following comments are from Steve Northcutt. > > > > >From Stephen.Northcutt@bmdo.osd.mil Thu Jul 1 11:49:33 1999 > >Return-Path: <Stephen.Northcutt@bmdo.osd.mil> > >Received: from hqbmdofs03.bmdo.osd.mil (firewall.bmdo.osd.mil > [134.152.2.194] (may be forged)) > > by linus.mitre.org (8.8.7/8.8.7) with ESMTP id LAA26228 > > for <coley@linus.mitre.org>; Thu, 1 Jul 1999 11:49:32 -0400 (EDT) > >Received: from hqbmdofs03.bmdo.osd.mil (root@localhost) > > by hqbmdofs03.bmdo.osd.mil with ESMTP id JAA02331 > > for <coley@linus.mitre.org>; Thu, 1 Jul 1999 09:33:05 -0400 (EDT) > >Received: from hqbmdofs01.bmdo.osd.mil (hqbmdofs01.bmdo.osd.mil > [172.20.1.1]) > > by hqbmdofs03.bmdo.osd.mil with ESMTP id JAA02327 > > for <coley@linus.mitre.org>; Thu, 1 Jul 1999 09:33:05 -0400 (EDT) > >Received: by HQBMDOFS01 with Internet Mail Service (5.5.2448.0) > > id <N4S6V5G7>; Thu, 1 Jul 1999 09:36:25 -0400 > >Message-ID: <A0CCBD88DC7ED1118BBD00005A4441D403C1AFF4@HQBMDOFS01> > >From: "Northcutt, Stephen, CIV, BMDO/DSC" > <Stephen.Northcutt@bmdo.osd.mil> > >To: "'Steven M. Christey'" <coley@linus.mitre.org> > >Subject: RE: Survey: Use of Same Attack/Same Codebase content decision in > > > VDB's > >Date: Thu, 1 Jul 1999 09:36:24 -0400 > >MIME-Version: 1.0 > >X-Mailer: Internet Mail Service (5.5.2448.0) > >Content-Type: text/plain; > > charset="iso-8859-1" > > > ><I'd prefer to delay deciding on the Same Attack/Same Codebase > ><decisions until I hear from an IDS person. > > > >Actually, I have done a little intrusion detection system development. > > > >>From a pragmatic IDS perspective you are keying on three things, source > >information, dest information, signature information. > > > >CVE would be concerned with the latter. Most IDSes are very primitive > >and rely on exact signature matches. However, at the price of false > >positives they often match on substrings. Can two completely different > >attacks have the same signature? Certainly. Can we track a codebase > >by its network footprint? Sometimes. > > > > > >Vulnerabilities are the gateways by which exploits are made manifest. > >A network based IDS can't (usually) detect the vulnerability, it detects > >the signature of the exploit in transit. Now lets bring it home. > > > >Because the signature matching is so poor on most intrusion detection > >systems, if you are going to be sensitive to IDSes, you probably need > >to individually enumerate the vulnerabities since they will often have > >a different signature. You do NOT want to give IDSes a reason to do > >partial matches! For instance two commercial systems alert on phf? > instead > >of phf? and cat (as in cat /etc/passwd). That causes a lot of false > >positives and gets the filter turned off in short order. > > > >If you find this helpful, feel free to share with the group. S. > >
|
||||
