IDS mailing list archives
Re: IPS Implementaion
From: Göran Sandahl <goran () gsandahl net>
Date: Mon, 17 Sep 2007 00:23:21 +0200
I also recommend monitoring and blocking different traffic differently. As suggested by Eric, for each system (or group of systems) define the traffic (on protocol level) that is truly critical (e.g. database transactions between finance systems). Then define a procedure for which new signatures are applied to these traffic flows that prioritises their availabilty. An example of this would be to have new signatures as detection for a week, and once they have proven not to fire on normal traffic, put them in blocking mode. For less important traffic flows (e.g. printer traffic?) signatures can usually be implemented in blocking mode once they are available (if the signatures severity rating is critical enough, of course) and regular tuning should take care of signatures prone to false-positives within an hour. /Göran -- Göran Sandahl mail: goran () gsandahl net web: http://www.gsandahl.net On Friday 14 September 2007 20:57:02 Eric Hacker wrote:
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=i ntro_sfw to learn more. ------------------------------------------------------------------------
------------------------------------------------------------------------ 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)