When to do something about detected attacks (was Re: how to do...)

[sedayao () orpheus sc intel com (Jeff Sedayao)]

Marcus brings up a key point that one of my coworkers who has spent a
career building measurement systems (first for manufacturing systems and
then for measuring network performance) is always saying:

If you don't know what you will do with data, don't collect it.

Otherwise, you are just wasting your and other people's time and
resources.  But does that mean IDS are a waste of time?  What actions
could you take based on the data?  When?  I would propose the following 
are useful actions you could do with IDS data.

1.  Trigger on resource threshholds.  If attacks consume a significant 
amount of resources, either in the logging machine or in network bandwidth
and other infrastructure, you need to do something about the attacks.
So I would qualify his Point #1 by saying "only tell me about it if
significant resources were being used by detected attacks".

2.  Stop employees (or other people within access to your internal
network like contractors) from hacking into other sites (#3 below).  This 
can often be very cost effective, especially if lawyers get involved in 
a hacking incident.  If your PR department gets involved, then things have 
gotten really expensive.

Jeff Sedayao
Intel Corporation

> Let me state a few of my assumptions, first. If they don't hold
> then I'm wrong. :)
>
> 1) Administrators don't have time to backtrack and try to shut
>       down attacks. They'd like to but they need to sleep sometimes.
> 1.2) Administrators will start to ignore their IDs if it pages them
>       more than once a day, maximum.
> 2) Firewalls and perimeter systems aren't 100% secure.
> 3) We are concerned about employees that are hacking other sites
>       because of the legal liability.
> 4) We are concerned about detecting other forms of break-ins that
>       occur on our internal network, possibly via modem or other
>       means (including social engineering).
> 5) We assume our attackers will be using attacks we don't know
>       about, yet.
> 6) Our networks are vast, rapidly-growing and completely chaotic
>       and we can't assume that what is going across it today is
>       what will be going across it tomorrow.
> 7) We have no defined policy, nor do we actually have any control
>       over networking and network growth. So telling a user to
>       "fix it" is a waste of time.
>
>       I think those are a reasonable set of assumptions. Unfortunately.
>
>       -> Based on assumption #5, I believe that we have to be skeptical
> of the usefulness of "network grep" type intrusion detection.
>       -> Based on assumption #1, I believe that even the informational
> value of "network grep" type intrusion detection will eventually go
> away, as the administrator tunes it out. After all, we really do NOT
> have time to backtrack every twink who runs scans against us.
>       -> Based on assumption #4 I question the utility of IDs in the
> firewall, though it's probably a component of a complete solution.
>       -> Based on assumption #6, I question the utility of AD-IDS that
> "learn" patterns -- the patterns change too fast or lose resolution.
> See Vern Paxson's earlier papers for some insights into this. Even
> if the system learns it'd generate false positives, which applies
> to assumption #1 and #1.2.
>       -> Lastly, the SNI guys have shown us that "network grep" IDS
> won't work against attackers who are trying to hire their attacks.
> I wonder how long it'll be before there are hacker tools for hiding
> from IDS? This is a cue for one of you grey hats to pipe up and say
> "but there *are*, daddy-o..."
>
>       Ok, so I don't think we're left with much. Yes, it is important
> to know how bad things are. That gets security funded. Yes, it is
> important to know that the firewall is resisting attack. Which leads
> me to a point:
> Point #1:
>       If the firewall/IDS/whatever deflects the attack successfully,
>       then don't bother me with it. Give me a weekly summary of how
>       many times it was attempted and we can have a laugh at the
>       twinks.
>
>       The main thing I think we have left is a notion of what is
> permitted by "policy" and a set of tools for looking at events.
> Here I'm not using "policy" in the usual computer security sense,
> of an unyielding set of rules; perhaps it's more an intent of
> what should and shouldn't be going on. That's what to look for.
> The bad news is that it's site-specific. :(
>
>       When I was consulting, I'd often be brought in to do
> analysis of some configuration or network or problem, to rule
> as to whether it was secure enough or recommend how to improve
> it. Frequently, during that process, I'd run across things that
> shouldn't happen. The customer would say something like, "well,
> nobody should be able to get into the Web server from the outside
> so we won't see anything like that..."  -- That's the key. What
> you need to do is identify categories of things that shouldn't
> occur, and set traps to detect when they do. Then scream.
> Essentially, what you're doing is looking for a policy violation.
>
>       Example: You have a web server outside a firewall, on a
> DMZ, protected by a router with screening. The CGI scripts are
> carefully audited, and so forth. Let's look at our policy:
> -> Nobody from the outside should be able to get a packet (through
>       the router) to anything but port 80/TCP or 53/UDP.
> -> The web server should not originate traffic to anything outside the
>       network (heading to the router) except packets from the http
>       server on port 80, and 53/UDP
> -> The web server should not originate traffic to anything inside the
>       network except the firewall, and then only on let's say SSH
>       and maybe SMTP
> -> Since there are no other systems on the network we should not see
>       anything coming in to (or going out!) from them.
>
>       That's a start for building a very strong intrusion detection
> capability. You know what is allowed to happen, you derive a few
> basic assumptions about what shouldn't happen, and you look for events
> that match the "shouldn't happen." You can get much much more detailed
> than my simple example. I.e.: "the web server should never ping broadcast
> addresses." or even "nobody on the web server should ever use the 'ls'
> command as "root""
>       Next you can start to usefully apply your "network grep" by
> using it to watch for specific things outside the scope of what
> should happen. Perhaps you want to watch for basic attack signatures
> in all traffic going to the ethernet address of the inside of the
> firewall. Perhaps you want to make a few other assumptions: nobody
> within the network should try port-scanning sites on the Internet.
> Or perhaps: nobody within the network should try to FTP password
> files from other machines. Etc. Etc.
>       Which brings me to another point:
> Point #2:
>       Intrusion detection is only meaningful if you:
>               - know what you'll do about it
>               - know what constitutes a violation of acceptable access
>               - can usefully reduce the scope of the areas in which
>                       you perform broad scanning
>               - can accurately define what "shouldn't happen"
>
>       After all, if you can't tell me what shouldn't happen on your
> network, I can't even tell you what an intrusion of such a network
> *IS*, right?
>
>       I bet if I asked you "will you react more vigorously to
> an IDS-generated alert on your internal network, or on your
> external?" you'd all say "internal!!"  Ok, then I ask you, "why
> bother about your external? You'll barely have time to look at
> your internal network anyhow!"
>
>       That's why I call this "policy-based intrusion detection" for
> lack of a better term. I suppose I am giving potential competitors
> useful ideas, but I've always been stupid like that. :) Besides, this
> is 6 year-old-thinking, I have newer, better ideas. ;) Just no time
> to do them...
>
>       Don't let any of this stop you. Intrusion Detection is going
> to be like firewalls. In a few years, EVERYONE is gonna have to
> have a sucker/sniffer/probe/recorder plugged into their network.
> Heck, the FBI may even require it (don't laugh!). So, for all the
> products' technical problems and philosophical design flaws, the ID
> vendors are going to make a bundle of money.
>
>       So, let me ask you a few questions:
>       -> Will you actually react to all the "attacks" your IDS finds?
>       -> Will you immediately rush to block land, flounder, blick, and
>               augenblick2 attacks as soon as someone tries to use them
>               on you?
>       -> Will you monitor all the logs?
>       -> Will you ever get any sleep?
>
> mjr.
> --
> Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
> work - http://www.nfr.net
> home - http://www.clark.net/pub/mjr


-- 
Jeff Sedayao
Intel Corporation
sedayao () orpheus sc intel com