RE: When to do something about detected attacks (was Re: how to d

From: Russ (Russ.Cooperat_private)
Date: Fri Apr 17 1998 - 11:47:39 PDT

  • Next message: carsonat_private: "Re: High ranking lusers"

    My favorite television program, "Connections" with James Burke, is
    always giving me lots of good examples to apply in every day life.
    
    In this case, its the idea that if you set up a test to prove that the
    Sun is moving away from earth, you'll come up with results that validate
    your idea. The reason is, when we make a premise, we have to envisage
    ways to prove the premise. Then that's what we go and look for.
    
    In this IDS debate, the premise is we're looking for hackers, so we put
    up monitoring to look for what we consider to be "hacks".
    
    Marcus' point, strengthened I think by Dan's comments, is that there is
    no way to define what "hacks" are.
    
    If I'm going to monitor, and rely on this monitor to tell me something
    is not right, then why base this on what I don't know (what's wrong).
    Instead, it should all be based on what I do know (what's right).
    
    The problem that has to be overcome here is the age old problem. I can
    collect far more information than I can tolerate. I could, for example,
    capture every single packet going to every single machine. The burden,
    however, on my systems, my network, my users, etc... would simply be too
    great for me to handle.
    
    Its like saying that we're looking for the proverbial "needle in the
    haystack" by removing everything that is not "hay"!!
    
    Well, if you think about it, that is the only way to find the needle.
    Sure, I could put a huge magnet over the haystack and the only thing
    that should come out of the stack should be the needle (assuming the
    only piece of metal in the stack is the needle, and further assuming
    that the needle is made of metal, I don't know either when I put the
    magnet above the stack, do I??).
    
    The idea of "anomaly testing", or looking for Bad Things(tm), is based
    on the premise that not only do I know what's good, but I can also
    filter it out of my measurement. I honestly don't think either are
    possible at a network level, and still be effective.
    
    This is why, quite some time ago, Marcus and I ended up in strong
    disagreement about the future of security. He wanted to build stronger
    borders, and I wanted to set each person adrift in the ocean of the
    Internet with a damn secure boat...;-]
    
    If, however, we could delegate security scope, we might be able to get
    our filters focused on enough information to make them perform (both
    quantifiably and qualitatively).
    
    Task desktop devices with application security, network devices with
    network security, and spread policy enforcement defined from a central
    authority out to all.
    
    Truly, the problem today lies in the cost of bandwidth versus the ever
    increasing volume of data we need to transmit/receive.
    
    The stop-gap measures that most IDS systems (and for that matter,
    Firewalls) represent today are the stepping stones necessary to get the
    cost of that bandwidth low enough that we can do what we need to. Why is
    UDP used in supposed or potential security solutions (e.g. SNMP),
    because it performs. Why do we need the performance, because it costs to
    much to oversize the network bandwidth.
    
    Shrinking what we need to look at is not the right approach. Its been
    the approach we've been taking for eons, and look where it gets us. If
    we are truly going to look at all the "hay" to see if its a "needle",
    then we have to accept that we need to do a whole lot more than we do
    with current IDS/Firewalls, and that's going to cost bandwidth (btw,
    bandwidth, in this context, includes the cost of processing power to
    drive the transmissions speeds).
    
    That doesn't mean we shouldn't consider optimizations, but as we all
    know, that's typically where we end up getting burned. "Oh, I won't do
    an alert on that, it'll never happen...", "I'll reuse that buffer to
    avoid chewing up more RAM..." and so on.
    
    If we're going to do it, then let's do it right, and if we can't do it
    right, then let's accept we need insurance (...my age old call for
    computer security insurance...;-])
    
    Cheers,
    Russ Cooper
    R.C. Consulting, Inc. - NT/Internet Security
    Moderator of the NTBugtraq mailing list
    http://www.ntbugtraq.com
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:55:15 PDT