IPS Change management process

[lonervamp at gmail.com (Michael Dickey)]

1. As Joel said, try to always do rules/signature and device/software
updates as soon as possible. For appliances and the like, you should
download daily and use whatever automated process is built in, especially
for rules updates. For my vendor, I've only had one known issue with a new
rule being somewhat poor and not doing what it should, but thankfully my
device defaults to not block with new stuff.

2. Also, do what you do now and stick to IDS mode to see what traffic you
see. You'll likely want to keep this up for quite some time. In fact, you
can probably keep this up forever and just block what you want to block,
especially if you're going to be good about attending to high priority
alerts that fire.

3. As your device learns, start to identify alerts you know are either a)
benign, b) false positives, c) things you know are fine and don't want to
block, or d) things that give you no value (arp and scan alerts most often).

4. For things you don't care about and can't/won't block, set up filters to
ignore them. If your device allows, be sure to provide detaile comments on
why you're making the change. If it doesn't, either utilize your ticket
system to track changes or start a spreadsheet. Every change you make, mark
it down in a new line and be as detailed as possible about where, what, and
why on those changes.

5. Eventually once you get a feel for things, you may start diving into what
alerts are possible. I'd encourage you to start blocking categories that
likely will not have false positives very often like P2P, IM, Bot, Worm,
etc. As before, always document your changes. And if you have a team to
notify on your changes, feel free to do so. It sucks to block something only
to find out a week later that it sent a team into 3 days of futile
troubleshooting, but it didn't come up until 2 days after your change.

You don't have to, but I think it would be useful to treat your IPS rules
and blocks like firewall rules: document changes and definitely the why
about them.

6. Get used to your device and make sure you can pull reports and
information out like what alerts you all have blocked or customized. If it
has a built-in history and audit trail and comments, that's excellent!

7. What you'll find is not only are you learning about the traffic in your
network, but as you read up on each alert, you're going to learn a lot about
what sorts of attacks are out there, too! Enjoy!

8. As you keep up with security in the great big world, especially Microsoft
patches, be aware which ones are critical or wormable or already exploited
and watch your vendor release notes for alerts based on those patches.
Really think about immediately blocking those alerts the next chance you
get. This can give your patch team some added breathing room.

Lastly, you don't *need* heavy change management on these things if you're
really careful, but I would wonder how valuable the IPS will be if you're
too careful, you know?




On Thu, May 21, 2009 at 9:07 AM, Dan Baxter <danthemanbaxter at gmail.com>wrote:

> The company I work for is in the process of spinning up an IPS solution.
> It's been a long time in coming and overdue, but we finally got the budget
> approval.
>
> Anyway, I'm developing the rules management process and have a few
> questions.  We're a large, international company with many different
> applications running on our WAN.  With many different application owners
> that may or may not know which address & ports the apps require for
> operation.  As a result, our management, while recognizing the need for the
> project, are nervous that it will cause problems by blocking legitimate
> traffic.
>
> I'd like to know some of the items that should go into a good change
> management process for adding/modifying rules to an IPS.  Our plan is to
> place the devices into IDS mode for a time to get to know our network
> better, but eventually we will turn blocking on.  From the time a ruleset
> gets released by the vendor, to the rules getting implemented on the actual
> devices, what are the steps you guys may be taking.
>
> I appreciate any input.  Thanks!
>
>
> Dan Baxter
> -------------------------------------------------
> Quis custodiet ipsos custodes?
>
> _______________________________________________
> Pauldotcom mailing list
> Pauldotcom at mail.pauldotcom.com
> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> Main Web Site: http://pauldotcom.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pauldotcom.com/pipermail/pauldotcom/attachments/20090521/66b06dec/attachment.htm