RE: True definition of Intrusion Prevention

From: Vigilant Labs (labs_at_thevigilant.com)
Date: 01/06/04

  • Next message: Teicher, Mark (Mark): "NEW Topic: Network Mapping Intrusion Detection style" 
    Date: Tue, 6 Jan 2004 13:39:06 -0500
To: "George Capehart" <gwc@acm.org>, "Brad McGary" <bmcgary@secondfront.net>

    George you hit the nail on the head, EXPERIENCE. Sharing positive
    success stories on this list is by far some of the best security
    education we could all receive.

    For the past few years I worked at Top Layer Networks*. While my job
    responsibilities varied, I felt that my most important responsibility
    was my role on the product planning team for the Attack Mitigator IPS
    product. Previously coming from the "user-side" (at ABN-Amro and Datek
    Online) I thought it would be easy to design a "high speed in-line
    appliance that could look for snort signatures and have the option to
    block them". Sounds simple, right? But as it turns out, this was very
    difficult. When designing a product like this there are fundamental
    approaches to consider that could make or break the product. For
    example, do you build an IPS product that "augments" detection
    technology (aka IDS) like Top Layer's approach or do you build an IPS
    product that "replaces" IDS like Intruvert or Netscreen's IDP**
    approach. While I'd rather not have tons of replies with the supposed
    answer to this question, I wanted to throw it out there so that people
    can start to understand and appreciate the thought that goes into these
    products.

    Another difficult decision is how does the product ship? Does it ship
    with all checks (i.e. signatures, prevention mechanisms, etc...) turned
    on? If that was the case the product would break 99% of the networks
    that it was installed into. Should the product be shipped with some of
    the checks turned on? How is the vendor to know which checks are even
    contextually relevant to the customers environment? Does Nimda matter
    when protecting a production Unix/Apache environment? Ok, ok so we'll
    ship the product with all the check's off? Now the product does nothing
    when you put it inline and the user is required to "turn things on" to
    secure their environment. This third option is the safest choice from
    the vendor's perspective but assumes three important details to consider
    the implementation of the product successful.

    1. The user knows their environment extremely well.
    2. The user knows what assets they are trying to protect with the
    product.
    3. The user knows the product well enough to configure it properly to
    protect those assets.

    As with any security tool, (Firewall, IDS, Policy thingamig-er) what
    matters is how the product is used and configured. Often times people
    don't understand how the product is intended to use, they just think
    "Whelp, I paid a lot for this it better secure me when I put it in." As
    we all know, network security is a difficult problem that is unique to
    every environment. Networks are uniquely designed, assets carry
    different risks, and what is important to one organization may not be as
    important to another. Proper planning is the key to having a successful
    IPS implementation. While this step may seem obvious, it almost always
    overlooked.

    Most people don't understand what how they intend to protect themselves
    with the product. The most common (Doh!) I've repeatedly seen is an IPS
    deployed on the internet gateway, while no protection exists after the
    VPN endpoints. (with 100+ users connected to the core of the network
    sitting behind cable modems of course) ; )

    To attempt to answer the subject line of this question...

    Definition:
    Network Based Intrusion Prevention - And inline network device that
    allows blocking, mitigation (slowing down), of malicious traffic in one
    of the following manners:
    Layer 2 - Mac Address Filtering
    Layer 3 - Source IP Filtering - "You triggered this check 5 times, I'm
    going to automatically block your source IP for 10 minutes."
    Layer 4 - Port Based Filtering - Basically mimic's firewall
    functionality, could be triggered as in Layer 3 example.
    Layer 7 - Application Based Filtering - This can be extremely advanced
    and is probably the most difficult prevention feature to design from a
    product standpoint, both resource wise and from a fundamental design
    standpoint. Examples include: Whitelisting and Blacklisting of URI's,
    RPC Bounds checking, FTP command restrictions, etc...

    I guess there are two points to what I'm trying to say.

    1. Building a product that will solve everyone's problem by just
    plugging it in is impossible. In my new role, I've been trained in or
    have evaluated all of the most popular IPS products on the market today,
    all of them have their strengths and weaknesses, but NONE of them work
    well "out of the box".

    2. Plan before buying, plan more before implementing, test, implement,
    and tune. This IS the recipe for success.

    Hope some of these comments were useful.
    Have a secure New Year!

    Joseph C. Magee
    Chief Technology Officer
    Vigilant, LLC.
    Phone: 617.921.8671
    Fax: 877.577.6718
    E-mail: jmagee|at|thevigilant.com
    PGP FP: 22A2 906C 1FA3 0A28 8471 20C0 B9AD A7A0 8671 5F14

    * My decision to leave Top Layer was to start a professional services
    company focused on integrating different types of security event data
    together and tuning the output according to an organizations weighted
    risk, ya know, the other side of the problem. : ) I still believe in
    the company and their products.

    ** These products were built with the intent or ability to replace IDS
    (and there is nothing wrong with that.) Don't let them tell you
    otherwise. An issue later faced is that their target market, fortune
    1000, banking, financial services, insurance and healthcare usually
    already have a heavy investment in another vendors IDS, hence the
    "augment card" is played. So they will claim that they can do either/or.

    > -----Original Message-----
    > From: George Capehart [mailto:gwc@acm.org]
    > Sent: Monday, January 05, 2004 5:26 PM
    > To: Brad McGary
    > Cc: focus-ids@securityfocus.com
    > Subject: Re: True definition of Intrusion Prevention
    >
    >
    > On Monday 05 January 2004 03:12 pm, Brad McGary wrote:
    > > I agree with your comments but would offer the thought process
    > > regarding the structure of an attack scenario. Most attacks
    > start with
    > > recon and end with target specific exploits. I've been using a
    > > commercial version of Hogwash for about two years and have
    > > significantly reduced the number of successful attacks launched
    > > against our environments by preventing the more prolific
    > recon tools
    > > from returning target intelligence. As for the worm attacks
    > we've been
    > > relatively successful at stopping these since they mostly utilize
    > > exploits which have mature snort signatures. In the end there's no
    > > panacea and we see our share of false positives and false negatives
    > > I'm sure. Please take these comments as just my specific experience
    > > and understand I certainly don't want to engage in any
    > heated debates.
    >
    > Hi Brad,
    >
    > Thanks for sharing your experience. And, while heated
    > debates tend to
    > drift away from the topic, I'd be interested in hearing what others
    > have done to try to head off attacks. This gets exactly to the point
    > that, to my way of thinking, to prevent intrusions one needs
    > to employ
    > a *process* which has many dimensions. You have very clearly
    > described
    > one aspect of that process . . .
    >
    > Regards,
    >
    > George Capehart
    >
    > --------------------------------------------------------------
    > -------------
    > --------------------------------------------------------------
    > -------------
    >
    >

    ---------------------------------------------------------------------------
    ---------------------------------------------------------------------------

  • Next message: Teicher, Mark (Mark): "NEW Topic: Network Mapping Intrusion Detection style"

    Relevant Pages

    • Re: Privilege-escalation attacks on NT-based Windows are unfixable
      ... >>> a well secured network. ... >> So you're basically saying that local privilege escalation doesn't ... > environment, this weakness is well behind other, like user writing down ... > security facilities ...
      (comp.security.misc)
    • Re: Privilege-escalation attacks on NT-based Windows are unfixable
      ... >>> a well secured network. ... >> So you're basically saying that local privilege escalation doesn't ... > environment, this weakness is well behind other, like user writing down ... > security facilities ...
      (comp.os.ms-windows.nt.admin.security)
    • Re: GPO to prevent user "hardening"
      ... Possibly a workaround for your problem if it's security of your network that ... administrators were updating systems for security, ... basic process is test - and retest and retest in a stable environment, ... Hardening of the systems may not be directed at the administrators, ...
      (microsoft.public.win2000.security)
    • Update #823559
      ... Installation History ... Successful Sunday, October 05, 2003 823559: Security ...
      (microsoft.public.windowsxp.security_admin)
    • Re: Being saved to a temporary document
      ... When excel saves the file, it saves it as a temporary file with a funny name. ... If the save is successful, xl will delete the original and if that's successful, ... Maybe something is wrong with that branch of the network. ...
      (microsoft.public.excel)
    Loading