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 <[email protected]>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 > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com >
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
