Re: "false positive" inanity
From: Tom D'Aquino (tom_daquino@yahoo.com)Date: 06/30/02
- Previous message: David W. Goodrum: "Re: Crying wolf: False alarms hide attacks : Eight IDSs fail to impress during the monthlong test on a production network."
- Maybe in reply to: Frank Sweetser: "Re: "false positive" inanity"
- Next in thread: joe: "Re: "false positive" inanity"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 29 Jun 2002 17:39:03 -0700 (PDT) From: Tom D'Aquino <tom_daquino@yahoo.com> To: Andrew Plato <aplato@anitian.com>, Joel.Snyder@Opus1.COM
So Mr. Snyder is asking for an IDS that does not need to be configured?
Just plugged in and turned on. That's like plugging in a router and
saying "ok, route". Are there any firewall products that automatically
learn the IP addresses of your servers and then determine which ports need
to be opened? Of course not (and I wouldn't trust a vendor that claims
this). The whole point of configurable devices is to give the admin
maximum control of his/her network. Why on earth would a network IDS be
any different? If you want a device that decides whether or not you
should be notified of an attempted attack, I say your Crazy (with a
capital C)! IDS vendors have a hard enough time developing products that
don't trigger alarms on traffic that is not associated with an attempted
attack (false positives). No Way, I want to see all attempted attacks,
whether they were successful or not. I want to know who is messing with
my network. Seeing these attempted attacks leads to insight that helps me
better protect my network, sort of like a weather radar. I will be the
one to decide when I don't want to see an attempted attack. When Code Red
first came on the seen, our sensors were inundated with traffic. We
verified the patch level of our servers and created a filter so that the
signature was only triggered by outbound traffic (which would indicate
that a server of our own had been compromised).
Also I have to agree with Mr. Plato, that an IDS like the one you dream of
is quite a long way off (and a reliable one even further off).
Just my 10 cents!
-Tom
--- Andrew Plato <aplato@anitian.com> wrote:
> 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
> ------------------------------------
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
- Previous message: David W. Goodrum: "Re: Crying wolf: False alarms hide attacks : Eight IDSs fail to impress during the monthlong test on a production network."
- Maybe in reply to: Frank Sweetser: "Re: "false positive" inanity"
- Next in thread: joe: "Re: "false positive" inanity"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
