Re: so, is I[dp]S a STUPID technology?

[Paul Schmehl <pauls () utdallas edu>]

--On Wednesday, October 12, 2005 00:48:27 +0200 Aviram Jenik 
<aviram () beyondsecurity com> wrote:

> On Wednesday, 12 October 2005 00:13, Paul Schmehl wrote:
> > What if I *do* have a vulnerability and the IPS blocked the attack?
>
> Then you're a very lucky guy and should go play the lottery. In this rare
> scenario the IPS is more up to date then your vulnerability scanner -
> this  means you bought a crappy scanner. It also means there's a very
> good chance  you're vulnerable to things your IPS *isn't* blocking, which
> means you have  to re-think the way you're protecting your network.
You''re not understanding.  I don't have a *useful* vulnerability scanner. 
When I say "useful", what I mean is: a scanner that can be scheduled to do 
routine scans of my address space.  To scan for the SANS 20 across my 
entire network takes the better part of a day.  To do that routinely means 
that one day of *every* week is taken up scanning for that alone.  Why 
that's going on, any other scans will be queued.  So I can't do "spot" 
scans with that tool.

The IPS is updated very regularly, automatically, without me having to do 
anything except review the report to ensure nothing is being blocked that I 
don't want blocked.

I *wish* there was a vulnerability scanner ****that I could afford***** 
that was as useful and reliable as the IPS is.  (And yes, I know about 
Foundstone, I know about Retina and I know about MSSPs that do this.  *All* 
of them are *far* too expensive for me to implement.)
> I can't argue with your experience (I quite agree with it, actually). But
> just  because you tried 2 bad tools and failed doesn't mean the idea is
> flawed -  just that you need to search a little harder.

No, the idea is flawed.  The IPS works without me having to do *anything* 
except review the results.  A vulnerabilty scanner *that worked* would 
still require me to do a great deal of work.

You apparently have no concept of what it's like to work in edu.  First of 
all, even if I *could* know, moment by moment, what my vulnerabilities are, 
that doesn't mean they'd get fixed.  First I have to id the owner.  Then I 
have to convince the owner they should update.  In some cases the equipment 
is owned by the professor, paid for by a grant, and the best I can do is 
take him off the network after he gets infected with something.  In still 
other cases the equipment is certified by some government entity and we're 
not even *allowed* to patch it.  We have to use other means to protect 
those.

These are real world problems, not fancy theories that sound good.

> There's also a very good reason why you haven't heard of alternatives to
> ISS  and nessus, but I really won't get into that. Enough holy wars for
> one day.
I'm not sure why you'd assume that, because it's untrue.  I've tested 
Retina, for example.  I've looked at Foundstone and played around with it a 
little.  We also have a site license for GFI Languard, which is a useful 
tool for spotchecking Windows boxes but worthless for Unix and Macs.  (And 
we have every OS and version imaginable.)

But when vendors get past $30,000 for their product, I'm done.  I don't 
have that kind of budget.

> > We all
> > learn from each other because each of us have different skill sets and
> > different exposures that color our outlooks.
> True. This is what this discussion is about :-)
> I don't claim to be objective, but I have seen enough success stories to
> convince me closing vulnerabilities (and not hiding behind a probability
> blocking system) is a very real scenario.
Well duh!  I'm not arguing it isn't the *right* way to go about it.  I'm 
just telling you that *real work experience* tells me, it ain't gonna 
happen.  Not 100%.  Yes, we use SUS and SMS.  We push patches.  We automate 
updates.  We do everything we can to stay patched and reduce exposure. 
But, and again, maybe you just don't know edu, it just isn't possible to 
patch *every* box and eliminate *every* vulnerability because - while I'm 
typing this to you, so smart 20-year-old CS major is installing a default 
version of Debian on his workstation and he's absolutely *certain* he has 
no exposure to risk because - well hell - it's UNIX!!!  And his box will 
get hacked.  And I'll discover that.  And I'll have to go give him the 
lecture, do the forensics, wipe his box and tell him never to do that 
again.  Then his buddy will do the same thing next week, and we'll start 
the dance all over again.
> That's too bad. And this is what you should change. After you fix your
> vulnerabilities and after you *know* you're patched against the known
> problems, go ahead and buy an IPS (or any other candy you wish). Also,
> you'll  finally have the time to play with its nice GUI :-)
How in the hell do I patch the default install of Debian that gets 
installed *tomorrow*?  I'm sure you're a bright guy, but you just obviously 
don't realize what a college computing environment is like.  (That's not a 
knock against *you*.  Lots of people don't know about edu - and way too 
damn many of them are willing to lecture us about what we ought and ought 
not to be doing.)
> On the risk of sounding re-re-re-redundant, this is what the VA tool's
> job is  - to tell you what new vulnerable stations are suddenly there.
Sigh...unless you have a VA tool that can 1) sense when a new, previously 
unknown node has come online, 2) scan it immediately for all known 
vulnerabilities and 3) take if offline immediately if it's vulnerable and 
4) explain to its owner why he can't get a network connection - you can't 
help me.   Oh, and it has to cost under $30,000 and be a site license or 
else I can't use it.

Trust me.  Your theory sounds great.  It just doesn't work in eduland.

Paul Schmehl (pauls () utdallas edu)
Adjunct Information Security Officer
University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/ir/security/
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.