Re: IPS Implementaion



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@xxxxxxxxxxxx
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.
------------------------------------------------------------------------