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: [EMAIL PROTECTED] 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. ------------------------------------------------------------------------
