Re: RE: IDS (was: FW appliance comparison)

["Marcus J. Ranum" <mjr () tenablesecurity com>]

[This is going to be my last posting in this thread. The sound that
I am hearing in the background sounds suspiciously like the
sound of my head beating against a wall...]

First off, a couple of meta-comments: I've been on this list
since it's inception (I was, after all, subscriber #1) and there
is a paradigmatic exchange of postings that we've all seen
time and again which follows the approximate pattern of:
        Original Poster: We'd X but it can't be done.
        Follow-up Poster: Actually, it's not that hard, you just Y and Z
        Original Poster: Oh, yeah, but what I didn't mention is that
                our X is 15 times bigger than normal and, well, it's
                political, and our budget just got caught, and an army
                of ninja squirrels is holed up in our computer room and
                won't let anyone in.
        Follow-up Poster: Why do I get the feeling you don't actually
                WANT to do this??

Of course this is just an Internet mailing list. Nobody on the list is
another poster's mommy or daddy. If your organization's security
sucks, or your management is clueless, or - whatever - your
problems are probably entirely your own. So, unless I'm unfortunate
enough to live downwind from your reactor, or I have my tiny stock
portfolio in your care, or you're putting my personal information at
risk - I really don't care if your managers are stupid, or whatever.
Don't feel you need to make excuses to me, or Paul, or Arkanoid -
OK? We know your managers are morons; everyone's are. We know
your budgets are tight; everyone's are. We know you're not a
programmer; nobody is. Whatever. It's not our problem.

Thank Goodness.

Brian Loe wrote:
> I suppose, but where I was coming from was that this requires a great
> deal of resources - not only in space - and that requires money.

I guess that's where I was coming from, too. You seem to think
this requires a great deal of resources and I doubt it does. You
seem to think this requires a great deal of money and I doubt
that, too. But I'm not the guy on the ground, so I'm absolutely
sure there are "details" that complicate or change the situation
a great deal.

> Naturally its slightly political, but
> only because I would have to put the fact that we have our pants down
> right now pretty delicately.

That's your real problem, I bet, isn't it?

99% of the "technical" problems I run into in security are
usually political - which is really a manifestation of poor
management or egotistical employees. Or both.

> > spend money" - wait a minute: didn't you already say you had
> > some hardware? Presumably a computer with a hard disk, right?
> > Maybe you don't have a terabyte in the darned thing but if you
> > managed to do something useful and demonstrate some value
> > to it, you'd probably find that they could afford a hard disk
> > upgrade. But what do I know?
>
> But wait, isn't that what I'm asking - how to go about doing just
> that?

I answered that question in my previous post but here it is
again:
        - There is no "silver bullet" that "handles logging"
                and requires no comprehension of what you
                want to do with your data
        - Look at your data
        - Decide what you want to do with it
        - Then do some scaling estimates and back from
                there into your performance envelope
        - Then implement it

There's no "laundry list" for what you should be able to pull
out of your logs and what you should do with the results. That's
because logs are highly site-specific and data-specific.

There was a good discussion on the log analysis mailing
list of "reports that would be good starting points" but it's
always data-dependent. I.e.:
Popular Reports
•       Loganalysis mailing list’s top picks:
–       Top N machines sending/receiving traffic through the firewall
–       Top N machines sending/receiving traffic on the network segment
•       Same as above but inward-looking
–       Top N machines being accessed behind the firewall
–       Breakdown of traffic through firewall by service (%-age)
•       This is popular as a pie chart
–       Breakdown of traffic on the network segment by service (%-age)
•       Same as above but inward-looking
–       Top N email address(es) sending Email messages
–       Top N email address(es) receiving Email messages
–       Top N machines accessing web
–       Top N targets identified in IDS alerts
–       Top N IDS attacks identified
•       Advanced reports:
–       %age of Email that is identified as spam
–       %age of Email that contains blocked attachments
–       %age of web traffic aimed at sites on porn blacklist
–       %age of traffic aimed at sites on spy/adware blacklist
–       Top N porn-surfers
–       Top N most-ad/spyware infected systems
–       New machines that have served WWW/FTP/SMTP today

That's from my old USENIX class materials and loganalysis.org.

> They've tried, I've tried, to do the logging - and always with
> something running on the data to help make it useful. You say it can
> be done and that it is useful - I'm just wanting to hear how. I think
> generally the mindset has been to log for troubleshooting purposes,
> not security (and this should probably include my last effort).

Look for things you've never seen before
Look for things that fall outside a range of what you see every day
Look for things that usually happen that don't

That's a pretty good start.

If you couple that with throwing away the stuff you ARE SURE
you don't care about (but count the number of things you throw
away and compare them day-over-day) you're in pretty good
shape.

You're still not guaranteed to find something valuable. But you're
much much much less likely to be standing around going
"Duh, we don't know WTF happened but yeah our customer
database is out there and the New York Times is calling. Let's
have a press conference and tell them we don't know anything
about how our systems work, then get jobs flipping burgers."

> The problem
> seems to get exacerbated, I might add, if you're saving all the data
> (no drilling) and reviewing it all manually, looking for something
> you've never seen before and can find no reference for.

How do you identify things you've never seen before?

The answer is easy: identify things you've seen before, acknowledge
them and count them, and if ANYTHING isn't something you've
already seen before it must be new, right?

I (again) suggest you take a look at the NBS powerpoints that
I mentioned in my last posting. Also, look at the posting I referred
to on "artificial ignorance." Those are two approaches (structural
analysis for never-before-seen structures and pattern analysis for
never-before-seen patterns) that work at extremely high speeds if
you are careful how you implement them. Trivial artificial ignorance
is a 5 line shell script. You can get fancier than that if you like.

> > But you're the guy who said:
> > "But, on the bright side, our 2k IDS system did
> > eventually begin blocking it from all but one customer site."
> > comparing your "$250k" log analysis system to your $2k IDS -
> > which certainly doesn't make it sound like you think your
> > IDS is useless. Make up your mind, would you?
>
> Did I say that?

Yeah, you did. Not only do I log all the URLs entering and leaving
my network, all session start/stops, DHCP leases, MAC addresses,
and IP/MAC pairings, I log all the Emails, too. :)

> I am currently tracking things like processor
> and memory loads, in hopes that a jump in activity - especially at odd
> times - would be an alert of something bad happening.

It might, yes. But then what?
"Processor loads spiked off the chart at 3:00am!"
"WTF happened?"
"I don't know. Our logs from 3:00am are already gone."
"Oh, well, let's hope it was nothing really bad!"

Something that seems to be lost here though is that when I was saying
> a Gig an hour, that was in compressed format.

It didn't get lost; you never said it. You didn't mention the
ninjas in your computer room either. :) But what's an
order of magnitude between friends?

Seriously, though, 1 gig of compressed data per hour
means a bunch of different stuff; namely that you were
compressing it (which is fairly CPU and memory intensive)
on the fly -- so you could just as easily be doing something
else with it like running it through a stoplist or something
to prune out the stuff you know is garbage. Yes, that is
site-specific stuff and to do it right we're talking a little
bit of programming -- not rocket science type programming;
more like an awk script.

> The logserver was
> rolling the logs at a gig.

Did it only have a gig of disk space?? Most logservers roll the log
when the disk is full.

> Not only is that a lot of data to store but
> that's a lot of data through the NIC. Multiplying that by two is going
> to be interesting, let alone 4 or more. 

...and this is why I am going to stop posting on this thread.

When I read observations like the one above, I can tell that
you have decided in advance that this problem is going to
defeat you. You're just looking for excuses. Hey, it's OK,
you don't have to do that. It's not our problem, we don't care,
and we don't need to know why you're not going to do it.

mjr. 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards