[logs] Re: [TSG] intrusion detection and log analysis [was: book advice]

From: Tina Bird (tbird@precision-guesswork.com)
Date: Tue Nov 04 2003 - 08:59:30 PST

  • Next message: Pravir Chandra: "[logs] Re: [TSG] intrusion detection and log analysis [was: book advice]"

    On Tue, 4 Nov 2003, Bruce Potter wrote:
    
    > ...incoming...
    >
    *eep*
    
    > I'll bite on this.  How much money/effort (ie: more money) had an
    > organization spent on IDS in order to detect nimda?  I mean, medium size
    > org ($500MM in revenue a year) probably spent $120k on licencing, hardware
    > and man power in a year to do Network IDS the Vendor Way... at least
    > $120k.  If the same org also had machines a year out of date on patches
    > (or even _4 months_, it doesn't matter) don't you think that money would
    > have been better spent on patching the machines?  and I don't just mean
    > tactically patching boxes, but rather coming up with an automated patching
    > process, testing requirements for patching production machines, etc...
    >
    i'm totally not arguing, here, but again -- in many environments (read:
    over 70% of counterpane's customers, in my incredibly not scientific
    survey) the people who controlled the IDS had it there because they had
    >no< access to the web servers themselves (and in all too many cases, to
    the web server logs).
    
    in fact one of the biggest problems c-pane had from a deployment PoV was
    that many orgs (and these are corporate, not university) were >so<
    politically fractured that the security team (the typical
    bringer-in-of-counterpane) couldn't get the system admins (or the dbas, or
    the web developers, etc) to forward their logs, >>even though the admins
    were making absolutely no use of them<<.
    
    > Now in an _incredibly_ uncontrolled environment (ie: Tina's nightmare, a
    > university), and IDS is an effective traffic cop.  You can't really
    > control student and faculty workstations and your only hope is detection
    > and response.  That is just a fact of life in a university.  but in a
    > corporate environment, there's no excuse.  You can use the hammer of thor
    > to control workstations....  patch or be owned
    >
    i'm not arguing, and the number of corp machines that were hit with RPC
    attacks this summer was smaller than it was at universities, but it sure
    as hell wasn't zero.
    
    > Seriously, how many zero-day worms have there been?  <crickets chirping>
    > I'm sure there will be one some day, but the current rack of IDS's will be
    > just as blind to it as your admins.  Keeping machines current on patch
    > levels ensure that your standard issue network IDS will be absolutely
    > useless.
    >
    in the particular issue of web servers, patching is also not going to
    necessarily detect other categories of attacks -- SQL injection etc --
    that you >might< be able to write into an IDS.
    
    > ...putting on the asbestos suit after that comment...
    >
    > In short, if you spend your IDS budget on figuring out how to do patching
    > right and mabye even for some external auditing of your network, you'll
    > probably not see many valid hits on your IDS.
    >
    the choir is listening attentively -- hell, >my< machines are all
    patched!! -- but in most places i've been, the IDS budget and the patching
    budget are completely independent and therefore this argument, while true,
    rarely translates into corporate reality.
    
    > I am a huge fan of statistical analysis of your own log data in real time.
    >  YOu know how your app "feels"... you may not know exactly how it works,
    > but you end up with log data that you get used to.  You get used to it b/c
    > there's a pattern.  .... mmm... stats.  So, do some statistical analysis
    > of the data.  Monitor it in real time.  If you suddenly see big deviations
    > from the norm, through a flag.  It is really not that hard to roll your
    > own detection mechanism here... the math is pretty straight forward.. the
    > only thing that changes it he types of data you're dealing with.  Weblogs,
    > flow data from routers (my fav for this type of analysis), mail logs, even
    > FW logs... take some of that leftover IDS budget you're now not spending
    > b/c you have a great patch process, and spend some time figuring out the
    > patterns in your log data and how to codify detection of anomolous events.
    >
    > Tina, I agree that many apps don't log the important stuff wrt security.
    > That is a problem that usually needs to be fixed by the developers...  but
    > it's amazing what you can sometimes infer with the log data that you do
    > have.
    >
    ;-)
    
    ms.-i-run-loganalysis.org is hardly going to argue with this point!
    
    > It always amazes me how much money an organization will spend on IDS
    > without having the slightest clue what is really running in their
    > datacenters and what a targeted attack would even look like.
    
    one of the steady themes of my classes and list postings is that if you've
    got a network IDS and no infrastructure to collect logs from the target
    machines, you're throwing your money away...so really, sir, we are in
    violent agreement here.
    
    web servers are a special case, mostly cos of the vast quantities of log
    data they produce.  but i'm sure Someone will beat that one into shape
    here any minute now.
    _______________________________________________
    LogAnalysis mailing list
    LogAnalysis@private
    http://lists.shmoo.com/mailman/listinfo/loganalysis
    



    This archive was generated by hypermail 2b30 : Tue Nov 04 2003 - 09:13:19 PST