"false positive" inanity
From: Andrew Plato (aplato@anitian.com)Date: 06/29/02
- Previous message: Drew: "Re: Crying wolf: False alarms hide attacks : Eight IDSs fail to impressduring the monthlong test on a production network."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 28 Jun 2002 19:22:43 -0700 From: "Andrew Plato" <aplato@anitian.com> To: <Joel.Snyder@Opus1.COM>
Joel M Snyder [Joel.Snyder@Opus1.COM] wrote...
>Let's say I have an Apache web server (i.e., code red immune, by
>definition). You're saying that I still should get alerts that someone
>is Code Red-ing the Apache server? I don't see that as an "intrusion,"
>I see that as "knob twisting a Medeco lock."
You're correct that is it "knob twisting" but you're incorrect in assuming that it is not an intrusion. CodeRed is an intrusion. Just because your particular Apache box isn't vulnerable does mean that the act of attempting to infect that machine with CodeRed is not and intrusion. What you describe is a case where an intrusion attempt did not lead to compromise. Most "intrusions" are actually attempted intrusions that do not lead to compromise. There is immense value in knowing that somebody TRIED to infect your Apache box with CodeRed. CodeRed may have been their first attack. The second may be an Apache exploit.
The purpose of an IDS is to detect intrusions. From that point forward, it is a security analyst's responsibility to determine if a reported intrusion (or intrusions) amounts to compromise. Now, tools exist, such as a vulnerability scanners, virus scanners, system integrity tools (like Tripwire), or a kernel-level monitor (like Entercept), that can help security analysts do this more effectively. However, it has never really been a feature of an IDS to make the assessment as to weather an intrusion resulted in an actual compromise.
Some IDS vendors (such as my cash cow, ISS), are integrating their scanning tools into their management consoles to help a security analyst correlate an event to vulnerability. Moreover, some host-based IDS products have the capability to do system integrity and log file analysis to provide a greater depth of information. However, at the end of all of this data there still needs to be a brain who makes the determination as to whether an intrusion is really a compromise or just "knob twisting."
>I suppose that I agree that I might want to be able to turn ON such
>things. For example, if that server were running deep in my network and
>I never expected it to ever see a Code Red, then if it did, I might want
>to know about it. But I would not expect an IDS to have that behavior
>as a default. That's... well, if I can be inane, then that's stupid.
What your basically saying is - an IDS should only alert on stuff that you expect NOT to see. There is a fundamental flaw in this from a security perspective. A hacker may penetrate your internal network and carry out a lot of scans, probes, and intrusion attempts that do not lead to compromise. If you had tuned your IDS to the point where you were only looking for issues that you were vulnerable to, you would miss all this precursory hacking activity and hence, by the time you determined there was an actual intrusion, your systems would already be compromised. Moreover, it would be nearly impossible to tune an IDS to only look for things you're vulnerable to since there are hacking tactics invented every day and any change to a system may cause it to become vulnerable to something it was not vulnerable to the day before.
One of the strongest benefits to an organization when they implement and IDS is the insight they get into network operations. I have clients that have even used their IDS products to track down improperly configured software packages. That level of insight into the function of your network can also serve as an early warning system. You can see attempted intrusions before they become dangerous.
> Let's keep going. Let's say I have an IIS server, and it's patched so
> that Code Red is irrelevant. You're saying that I should still get
> alerts that someone is Code Red-ing that box? Again, I don't see that
> as an intrusion; I see that as futile. Why is the IDS wasting my time
> with information which is irrelevant?
It isn't irrelevant at all. That CodeRed alert could be the prelude to a much more sophisticated attack or an attack you are vulnerable to. Or it may even be a new variant of CodeRed that your system IS vulnerable to. In any event, you should be looking at this. Hackers will conduct a lot of well-known attacks on a system to see if it is vulnerable. I would want to know this information before the hacker moves on to more sophisticated attacks.
It sounds to me like you expect an IDS to be a "security brain" for you. Something that can not only detect an intrusion but then analyze that intrusion and then make a determination if you're vulnerable to that intrusion. This would require the merging of some rather sophisticated technologies, namely vulnerability scanners, patch management, firewalls, etc. While this may be a good idea, the technology simply does not exist to do reasoning at that complex of a level.
>You might say that I should be tuning the IDS. In effect, for every
>single attack signature, I should understand whether it is relevant to
>my network, which ports it should be looking on (let's say IIS is
>running on port 25), and where I care that it look. Well, you can say
>that---after all, you make your money fiddling other people's IDSes.
>But I would also call that "inane." An IDS that makes me know all that
>is simply dumb; *it's not doing its job*. And that's part of the core
>of the problems we saw.
Again, you're working off some very incorrect assumptions here. You are assuming that everybody's network is identical. You're also assuming that an IDS can reach into every system, analyze it, and then make decisions about each signature it sees. Both of these assumptions are faulty.
First, there is no such thing as a standard network. Networks are very dynamic and anybody who spends time inside more than one network can attest to the almost biological nature of a network. Therefore, IDSs have to be tuned to function optimally with each network.
And yes, it is a network administrator's responsibility to understand exactly what is relevant to his/her network. I would not be very happy if I hired a network admin and he/she did not know whether the systems under his care were vulnerable to Code Red.
A good admin can look at an IDS log, see a Code Red attack and say - "okay, I patched all my boxes so I am probably okay, but why is somebody attempting code red against these machines." In this case, compromise is not the problem but why that attack is even entering the network. The point is, that admin has data about an event that took place on his/her network. He then can make an informed decision on how to respond.
>The key to all this is that someday, probably someday soon, all of the
>IDSes we tested will get their signatures tighter and smarter. When the
>next
>wu-ftpd-bug-applicable-only-to-Solaris-on-Sparc-version-8.1-but-not-8.2
>is found, the signatures will ONLY trigger if the attack is relevant.
>And when that happens, you can bet your revenue for this year that NO
>ONE will complain. No one will say "oh, no, I don't want that behavior,
>I want to find out EVERY time someone attacks ANY version of ANY FTP
>server with this." And that's going to be the real proof that our
>definition isn't inane, but actually quite sane. (BTW: I will be
>overjoyed when that day comes, not to be proven right, but to see those
>products get closer to what they need to be.)
I think you may be waiting a while for this technology. However, I don't think I would want to use it on my network. I want to know all the things that are going on, on my network. And I like using a palette of different tools and technologies to manage and analyze my systems. And even if an event did not cause a compromise, I want to know that so I can track down the offender and lock him out of my network (if possible.)
The more I look into this nwfusion report, the more I realize how completely meaningless it is. It sounds to me like you entered this evaluation with some rather faulty assumptions and as such it is my opinion that the security community cannot take the results very seriously.
------------------------------------
Andrew Plato, CISSP
President / Principal Consultant
Anitian Corporation
(503) 644-5656 office
(503) 201-0821 cell
http://www.anitian.com
------------------------------------
- Previous message: Drew: "Re: Crying wolf: False alarms hide attacks : Eight IDSs fail to impressduring the monthlong test on a production network."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
