Re: How to choose an IDS/FW MSS provider

["David W. Goodrum" <dgoodrum () nfr com>]

Yes, I realized, after I sent my email, that ISS also had a problem... 
oh well.

Regarding NFR's code being available, you're absolutely right, but 
that's because we used to give our product away at that time and it was 
for R&D.  Not only was our R&D stuff was freely available several years 
back, I believe our first generation signature set (written by the l0pht 
group for us) probably floated into the wild as well.  That was sometime 
around 1999.  I can assure you that probably 99% of our code is 
completely different from anything we had back in 1999.  Evolution baby.

Don't get me wrong, I'm not fighting the closed vs open battle.  NFR 
sigs are open... Most of our competitors are closed (except  Snort).   
I'm merely stating that whichever way the vendor goes, there will always 
be people complaining.  I not only like open signatures, but I rely on 
NFR's open signatures to add value by writing custom code for our 
customers.  For example, I recently wrote a piece of custom code 
recently that leverages NFR's passive OS fingerprinting system (original 
designed to allow us to do fragmentation re-assembly better) to allow a 
customer to do OS policy enforcement on their internal network.  It 
wasn't hard to do, and the fact that it's an open signature language 
means that I didn't have to be a C programmer to do it.  You can ask 
anybody on NFR's development staff, and they'll gleefully tell you that 
I'm NOT a programmer... :).  But, at the same time, somebody could now 
read how I did it (if they could get the code I wrote) and then try to 
fool the OS Fingerprinting system into believing that a non-allowed OS 
is actually an allowed OS (not a likely scenario on somebody's internal 
network though).  So, what I'm saying is that I understand the argument 
from both sides;  I understand why ISS signatures are closed, and that 
it has both drawbacks AND benefits.

-dave

Jason wrote:

> inline.
>
> [...]
>
> > > Just cause your in L2 mode doesn't make you immune to attack
> > > (http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tcpdump). The 
> > > box still
> > > has to process packets just like any other L3 app. I'm not sure how 
> > > bridge
> > > mode makes a box "invisible". Besides, the device still needs an IP 
> > > on the
> > > local network for management. Sounds like security through obscurity 
> > > to me.
> > >
> > >  
> > Invisible in the sense that the interfaces that pass traffic do not 
> > have IP addresses.  And yes, the device must have an IP address on 
> > the management side, but that's generally deeper in the network.  I'm 
> > not sure that's obscurity... that's simply smart management.  Many 
> > customers have completely out of band management networks.  And yes, 
> > it's possible to compromise systems that are simply sniffing... but 
> > it's much harder.  I know of only one product that's been 
> > successfully remotely exploited in this manner, and the only reason 
> > that happened was because it was an opensource product that allows 
> > hackers to read the source code and look for ways to compromise it.
>
>
> Hmm, apparently your FUD thrower needs an update :-)
>
> http://www.google.com/search?q=witty+iss
>
> Last time I checked ISS was closed source.
>
> Then there is the Enterasys code that is apparently available for 
> sale. ( http://tinyurl.com/3s84g ) IIRC the NFR sources were floating 
> around a few years back too. The moral of the story is that sources 
> are easy to come across if you want them and being closed only offers 
> an obscurity advantage.
>
> http://www.caida.org/analysis/security/witty/
>
>     While the Witty worm is only the latest in a string of 
> self-propagating remote exploits, it distinguishes itself through 
> several interesting features:
>
>         * Witty was the first widely propagated Internet worm to carry 
> a destructive payload.
>         * Witty was started in an organized manner with an order of 
> magnitude more ground-zero hosts than any previous worm.
>         * Witty represents the shortest known interval between 
> vulnerability disclosure and worm release -- it began to spread the 
> day after the ISS vulnerability was publicized.
>         * Witty spread through a host population in which every 
> compromised host was doing something proactive to secure their 
> computers and networks.
>         * Witty spread through a population almost an order of 
> magnitude smaller than that of previous worms, demonstrating the 
> viability of worms as an automated mechanism to rapidly compromise 
> machines on the Internet, even in niches without a software monopoly.
>
>
> > > With the obvious success of IPS technologies at the perimeter, I 
> > > find it
> > > hard to believe that IPS and FW technologies will remain disparate
> > > technologies for more than a few more years. The IPS vendors need to 
> > > do one
> > > of two things:
> > >
> > > 1. Find a good firewall vendor to acquire them or
> > > 2. Build a full featured firewall from scratch.
> > >
> > >  
> > IPS technologies are actually just as (if not more) successful 
> > internally than on the perimeter.  I would argue that they are not 
> > disparate technologies even today.  NFR's appliances are essentially 
> > FreeBSD based, and so we've integrated FreeBSD's pf into the product 
> > which is a fully functional firewall.  It's providing the pretty GUI 
> > overlay that CheckPoint and other traditional firewall vendors have 
> > had for years that is the hard part.  Fortunately, we (the collective 
> > IPS vendor market as a whole) get to learn from their mistakes and 
> > successes.
>
> The IPS cannot be _in_ the networks to be protected and must remain at 
> the borders. This means that you can have systems compromised within 
> the internal borders and still end up with a big mess. An IPS is a 
> useful tool for mitigating nuisance issues and rapidly moving threats 
> only if it can respond before those threats occur. In the case of 
> witty it was the threat. What if those systems had been inline?
>
> Defense in depth is the key element and if you combine the FW and the 
> Inline device or not you still have to monitor the networks to really 
> know what is happening. How do you effectively prevent the 
> exploitation of the Microsoft GDI+ vulnerabilities by dropping packets 
> on a gigabit core? On a 100Mbs segment?
>
> I will argue that you cannot.
>
>
> Disclaimers:
> - I have never seen any of the source code mentioned.
> - I do not know that those sources are actually available.
> - I work for a vendor.


--
David W. Goodrum
Senior Systems Engineer
NFR Security
703.731.3765


--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from 
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
--------------------------------------------------------------------------