IDS mailing list archives
RE: IDS failures and avoiding them (WAS: Rather funny; looks like page defacement to me)
From: "Angel Rivera" <arivera () mitre org>
Date: Tue, 17 Jun 2003 14:26:03 -0400
good requirements for an IDS _ I just wanted to add one more that is often overlooked - identify your high value targets from the beginning - ideally through a thorough risk assessment but I don't wan to go into that topic - I see a lot of clients that decide to put agents on all devices irregardless of whether or not they need it - this of course contributes to more massive amounts of data and alerts - not a glamorous technical suggestion but one that will save you a lot time and money. -----Original Message----- From: Jim Butterworth [mailto:res0qh1m () verizon net] Sent: Tuesday, June 17, 2003 1:26 PM To: 'Mike Lyman'; focus-ids () securityfocus com Subject: RE: IDS failures and avoiding them (WAS: Rather funny; looks like page defacement to me) Having just returned from operations abroad as a military Intrusion Analyst aboard an Aircraft Carrier, where my full time job was doing Intrusion Detection, I would tend to agree with the assessment that Intrusion Detection Systems are best left to the trained professional. You can quickly find yourself inundated with traffic, packet aggregation and data mining, engineering installations in a heavily switched environment, and just get in over your head real quick. And for what? That is really what is critical to think about. Why do you need, and what is it you intend to get out of it? Like Mike mentioned, most folks want to jump right into #3 (real time notification) right up until the time that they find either their email or pager is being DOS'd by your IDS sensor because of the immense amount of false positives that are being generated by your "MUST HAVE" IDS solution. To get it right requires trained Intrusion Analysts, and some time to baseline your traffic and analyze which is normal traffic. If your network load is maxing out your 100 Mbps cards on the periphery, and your servers are getting close to maxing out the ATM/Gig-E cards you're running, then AT BEST, you'll be pulling about 85% of the packets, AT BEST! It is imperative to know what it is you want out of the IDS first, then engineer your solution. This helps to implement rules, helps in knowing whether you need a NIDS or HIDS or both solution, whether you want to feel safe knowing you have a device, whether you really want to try and stop malicious intent BEFORE it reaches your network (stateful inspection), whether you want to try and be "Big Brother" by seeing who is doing what, whether you feel confident enough to rapidly work in a 95% DHCP network (no MAC reservation), using 8 different subnets, in an ATM environment, employing 6 different VLAN architectures, using IP tunneling technology, blah blah blah... My point is, if you want to do Intrusion Detection, convince the bean counters and money holders to hire some folks, and fund some hardware acquisition. If they are just treating it like an insurance policy, MAKE DAMN SURE you get them to sign a disclosure agreement that when your network gets hit, you are not responsible, because if you just let them get away with bare bones, and you don't advise them to the contrary, you will be perceived as being responsible because they "bought you" a solution. You are responsible to advise them, or don't so it. You'll give THEM a sense of security that YOU'RE responsible for. Also, be prepared to defend the investment of an Intrusion Detection solution when you go months without ever capturing that zero day (no notice) attack. [Remember, the rules are based upon signatures from documented attacks, meaning stuff that already happened] What a proper IDS will provide for you is: #1 - Who is talking to my network? #2 - Who is my network talking to? #3 - Which ports are my applications using repeatedly? #4 - Alerts of script kiddie sort of probes, scans, fingers, etc... #5 - What is the normal behavior of my network #6 - Needing to learn how to write/modify rule sets for YOUR installation #7 - When my network is talking outside my home, what is the nature of the connection? #8 - "I didn't know AOL Instant Messenger wasn't authorized!" - Johnny SYSADMIN, 2003 #9 - An awareness that there is so much more to learn #10 - an IDS solution IS NOT an antivirus solution!!!!!!!!!!!!!!!!!!!!! Make them understand!!!!!!!!!!! R/Jim Butterworth SANS GCIA -----Original Message----- From: Mike Lyman [mailto:mlyman () west-point org] Sent: Saturday, June 14, 2003 11:42 AM To: focus-ids () securityfocus com Subject: RE: IDS failures and avoiding them (WAS: Rather funny; looks like page defacement to me)
So most IDS systems are a waste of money. They may be useful if they are installed by a MSSP who actually understands security, but not by the average sysadmin handed another box and told to install the IDS because the auditors say we need one.
I've given this area a lot of thought lately because we are reevaluating parts of our system and I've talked with other orgs where their IDS deployments have been at best disappointing and in some cases disasters. In my mind, IDSs can serve four basic purposes: 1) Intelligence gathering 2) Investigation support 3) Real-time intrusion detection and investigation 4) Intrusion Prevention I've listed them in order of what I think the resource required are and the knowledge required are. The lines blur between the purposes quite a bit and intelligence gathering systems can occasionally result in intrusion prevention and intrusion prevention can certainly provide intelligence. Still, I think the four basic purposes are a good way to look at things. I think most deployments are a disappointment because too many places aim immediately for 3 & 4 without the knowledge, experience or resources to make it successful. It is better to start small, gain experience and grow as you are able. Some may argue that starting small will not get you the full benefit of IDS but you will gain some benefit and some benefit is better than none and could very well be better than a failed deployment. A good example of starting small was our deployment of HIDS. Most people seem to think about targeting their critical systems immediately. We went after the desktops first. Our thinking was based on a number of things. First, at the time we lacked the testing resources to do the testing necessary to move into business critical systems and at the time if we impacted performance at all, we'd have to be willing to cough up the resources to make up for the impact. Second, we knew the desktops were the low hanging fruit that would be the places first targeted by an intruder. Third, we knew that we could detect reconnaissance just as well on the desktops as we could on the servers and probably better because there are more desktops. Finally, there are lots of spare resources on the desktop and impacts there were far less likely to be noticed and if necessary, we could easily uninstall things. Admittedly, that desktop HIDS deployment was done as the path of least resistance but in hindsight, it was a good approach that allowed us to gain the experience that allowed us to move into the critical systems with a far more intelligent plan than we would have put together when we first looked at HIDS. We had proven the technology worked and that we could gain benefit from it by just shooting for investigation support and occasionally stretching things to real-time detection. We have always shot for 1 and 2 and still have occasionally been disappointed by parts of our deployment but those disappointments never resulted in us scraping IDS completely. In shooting for 1 and 2, we have gained valuable experience, learned to tune things for our environment and been able to sometimes create and stretch things into 3 and 4 without the resources that are often required to normally get to those levels. Of course there are exceptions. Small environments or environments with the right people and skills might get to 3 and 4 quickly and with fewer resources than other places and improved technology are helping as well. As usually, YMMV. Sometimes it is better to look for even a partial solution than a 100% solution. You still get benefit and are less likely to fail than you are shooting for a complete solution in one fell swoop when you are ill prepared for the complete solution. Mike Lyman CISSP mlyman () west-point org pgp keyid 0xD7BBADAD ------------------------------------------------------------------------ ------- Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas, the world's premier technical IT security event! 10 tracks, 15 training sessions, 1,800 delegates from 30 nations including all of the top experts, from CSO's to "underground" security specialists. See for yourself what the buzz is about! Early-bird registration ends July 3. This event will sell out. www.blackhat.com ------------------------------------------------------------------------ ------- ---------------------------------------------------------------------------- --- Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas, the world's premier technical IT security event! 10 tracks, 15 training sessions, 1,800 delegates from 30 nations including all of the top experts, from CSO's to "underground" security specialists. See for yourself what the buzz is about! Early-bird registration ends July 3. This event will sell out. www.blackhat.com ---------------------------------------------------------------------------- --- ------------------------------------------------------------------------------- Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas, the world's premier technical IT security event! 10 tracks, 15 training sessions, 1,800 delegates from 30 nations including all of the top experts, from CSO's to "underground" security specialists. See for yourself what the buzz is about! Early-bird registration ends July 3. This event will sell out. www.blackhat.com -------------------------------------------------------------------------------
Current thread:
- Re: [security-elvandar] Re: Rather funny; looks like page defacement to me, (continued)
- Re: [security-elvandar] Re: Rather funny; looks like page defacement to me Remko Lodder (Jun 18)
- Re: [security-elvandar] Re: Rather funny; looks like page defacement to me Paul Schmehl (Jun 18)
- Re: [security-elvandar] Re: Rather funny; looks like page defacement to me Remko Lodder (Jun 18)
- Re: Rather funny; looks like page defacement to me Jerry M. Howell II (Jun 14)
- Re: Rather funny; looks like page defacement to me Michael Sierchio (Jun 17)
- Re: Rather funny; looks like page defacement to me Paul Schmehl (Jun 17)
- Re: Rather funny; looks like page defacement to me George W. Capehart (Jun 17)
- Gartner comments (was Re: Rather funny; looks like page defacement to me) Randy Taylor (Jun 17)
- Re: Rather funny; looks like page defacement to me broyds (Jun 14)
- RE: IDS failures and avoiding them (WAS: Rather funny; looks like page defacement to me) Mike Lyman (Jun 17)
- RE: IDS failures and avoiding them (WAS: Rather funny; looks like page defacement to me) Jim Butterworth (Jun 17)
- RE: IDS failures and avoiding them (WAS: Rather funny; looks like page defacement to me) Angel Rivera (Jun 17)
- RE: IDS failures and avoiding them (WAS: Rather funny; looks like page defacement to me) Mike Lyman (Jun 17)
- RE: Rather funny; looks like page defacement to me Roger A. Grimes (Jun 17)
- Re: Rather funny; looks like page defacement to me Bill Royds (Jun 17)
- RE: Rather funny; looks like page defacement to me Roger A. Grimes (Jun 17)
- Re: Rather funny; looks like page defacement to me Callan K L Tham (Jun 17)
- Re: Rather funny; looks like page defacement to me Paul Schmehl (Jun 17)
- Re: Rather funny; looks like page defacement to me Bill Royds (Jun 18)
- Re: Rather funny; looks like page defacement to me Callan K L Tham (Jun 18)