IDS mailing list archives
Re: IPS Implementaion
From: "Eric Hacker" <my.self () erichacker com>
Date: Fri, 14 Sep 2007 14:57:02 -0400
Chris, I don't know of any reference materials, but then I haven't been looking for some time. I'll offer some tips though to get you started. This will be a bit haphazard stream of consciousness. Survey the IT and Business managers to find out if there is any time critical traffic on the networks with the IPS. Determine the ports/protocols and endpoints for this traffic. Put the list in order of Cost Per Hour of down time (CPH). Anything on this list is probably traffic that you want to turn on blocking for last. There may be a point where the CPH starts to approach your salary for important traffic. At this point a small IDS staff should not turn on blocking on that important traffic as it is likely that there will be hour or more response times for such a small staff. If there is a high security need to monitor this traffic, then the risk proposition justifies a bigger IDS team capable of on-site response times anytime this traffic exists. If necessary, set up monitoring filters for the important traffic now so that you have a good history of possible false positives. Depending on the reporting system, it might be easy to pull this data out on the existing database from the existing rules, or it might not. Make sure you are currently collecting the data you need to make decisions later. Some large organizations have formal change control procedures. Sometimes this applies to IDS, but often not because IDS tends not to interfere with other network services. Once you start blocking, that must change. Make sure you understand the requirements and have budgeted the time necessary to follow change control procedures. You also need to pay attention to change control to make sure you add any new high CPH protocols to your list. A lot of IDS teams have gotten away with not paying attention to the new stuff and then adjusting the after it starts to generate false alarms. You don't want to do this for IPS. For really high CPH, I'd recommend a separate QA environment or perhaps install IPS in the application QA environment to ensure that problems don't arise later. Consider what information you need to store about the rules/signatures and whether the IPS system adequately allows you to capture that information. These are the business reasons, history, last changed by, etc. It may be necessary to set up a tracking database to track this information elsewhere. Sometimes a help desk ticketing system can be correlated to the rules to do this. Do not think that you'll remember why a rule was put in when you look at it again next year, or even what some obsure notes mean. One is performing high level programming of the IPS and like any other programming, documentation is crucial to maintainability. I hope that helps some. Peace, Eric Hacker, CISSP Hacker for Hire aptronym (AP-troh-NIM) noun A name that is especially suited to the profession of its owner I _can_ leave well enough alone, but my criteria for well enough is pretty darn high. ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw to learn more. ------------------------------------------------------------------------
Current thread:
- IPS Implementaion Chris M (Sep 14)
- Re: IPS Implementaion Eric Hacker (Sep 14)
- Re: IPS Implementaion Göran Sandahl (Sep 17)
- <Possible follow-ups>
- Re: IPS Implementaion proneetb (Sep 14)
- Re: IPS Implementaion Eric Hacker (Sep 14)