Re: Cisco CTR

From: Martin Roesch (roesch_at_sourcefire.com)
Date: 11/19/03

  • Next message: Martin Roesch: "Re: Cisco CTR" 
    Date: Wed, 19 Nov 2003 14:07:55 -0500
To: Renaud Deraison <deraison@nessus.org>

    On Nov 19, 2003, at 1:32 PM, Renaud Deraison wrote:

    > On Mon, Nov 17, 2003 at 05:40:30PM -0500, Martin Roesch wrote:
    >> You can infer a number of interesting things from looking at MAC
    >> addresses, hop data, peer information and so on. In the general case
    >> the information will be accurate, in some cases it will not, it's
    >> still
    >> interesting and useful for certain applications.
    >
    > The map you get is mostly inaccurate in terms of network _topology_.
    > Have a look at the screenshot on your website - it basically shows
    > that groups of hosts are <N> hops away, and that your router actually
    > has two NICs. It looks very nice, though.

    Actually you're wrong, it demonstrates topology very well from the
    viewpoint of a passive system that needs to know basic things like hop
    counts in order to have an accurate way to gauge the impact of TTL
    variations in passively acquired packet sets (e.g. NIDS). You're also
    wrong that we can't determine topology, RNA is capable of discovering
    topology explicitly by identifying routers, switches, proxies, NATs and
    so on. Additionally, you're wrong in your interpretation of our
    network topology that's displayed in our 3D visualizer (which is an
    easy mistake to make seeing as you have no idea what our network looks
    like), what it's actually displaying is our dual redundant T1s going
    out to the internet through our redundant routers and the hosts beyond
    clustered by hop counts. We can display clusters of data in other ways
    as well, but this particular view is useful for the sake of
    screenshots.

    >> I don't doubt that you can do similar things with Nevo, it just seems
    >> that the emphasis and focus of your product is in a different
    >> direction
    >> than ours. If that's not the case I'm sure that everyone here would
    >> enjoy being enlightened as to what you guys are up to with your
    >> product.
    >
    > You are absolutely right - NeVO is a passive vulnerability scanner,
    > with
    > all what it implies (get the list of open ports, guess the operating
    > system, determine who is talking to who, and finally show the list of
    > vulnerabilities we actually think are vulnerabilities).
    > Ie, to paraphrase the marketing about RNA :
    >
    > . Network Asset Profiles
    > . Asset Behavioral Profiles (with Lightning)
    > . Security Vulnerabilities
    > . Change Events (with Lightning)

    Well then it would appear that the difference is that we don't need a
    separate product to do 50% of the job, we're capable of building
    pictures of change events, quite possibly at a different level of
    granularity, with a single device and coordinating that with the rest
    of our NIDS+Management solution on the back end. Our RNA appliances
    are fully capable of running stand alone as well as in a distributed
    mode with the Sourcefire Management Console coordinating and
    correlating data from multiple sensors.

    > Note that for security vulnerabilties, we actually consider that people
    > do sometimes apply patches, so we don't just do an OS lookup in a
    > vulnerability database to report all the flaws that ever happened for
    > that
    > particular OS release.

    Nor do we.

    > This is prone to false negatives but this is how we
    > market NeVO - it's a tool to "get the temperature" of the security of a
    > network, not to get a list of all the hypothetical flaws that might
    > eventually
    > be on the network.

    Getting a list of the vulnerabilities that exist in an environment only
    has a few uses such as improving the quality of the information coming
    out of the NIDS by qualifying events. That is only one of the
    subfunctions of RNA, our primary thrust with this product lies in asset
    management and change analysis, it sounds like we have implemented
    similar technologies with different concentrations and overall goals.

    > I hope this clear things up,

    As do I.

         -Marty 

    -- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Snort-based Enterprise Intrusion Detection Infrastructure
roesch@sourcefire.com - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
---------------------------------------------------------------------------
---------------------------------------------------------------------------
  • Next message: Martin Roesch: "Re: Cisco CTR"

    Relevant Pages

    • Re: Cisco CTR
      ... The list of vulnerabilities ... > create a vulnerability in the context of a network. ... I think that passive discovery ... Sourcefire: ...
      (Focus-IDS)
    • CERT Advisory CA-2003-04 MS-SQL Server Worm
      ... code that most likely exploits two vulnerabilities in the Resolution ... traffic generated between hosts infected with the worm targeting SQL ... Activity of this worm is readily identifiable on a network by the ... protection whatsoever against the initial infection of systems. ...
      (Cert)
    • RE: Pre-Scanning for Marketing
      ... The controlling interest of the network has to have a inclination to secure ... vulnerabilities are easily and efficiently identified. ... Audit your website security with Acunetix Web Vulnerability Scanner: ... Up to 75% of cyber attacks are launched on shopping carts, ...
      (Pen-Test)
    • CERT Advisory CA-2002-03 Multiple Vulnerabilities in Many Implementations (fwd)
      ... CERT Advisory CA-2002-03 Multiple Vulnerabilities in Many ... Products from a very wide variety of vendors may be affected. ... Many other systems making use of SNMP may also be vulnerable but were ... The Simple Network Management Protocol is a widely deployed ...
      (Focus-Microsoft)
    • Re: Lockout a country.
      ... only the last hop or three is relevant. ... It's easier to block their network and just not ... No I don't know if that refers to 2.2.5 to 2.2.15 (I don't know of any ... current distro using a kernel that old - the "current" 2.2.x kernel is ...
      (alt.computer.security)