Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
855 Views 3 Replies Latest reply: May 8, 2013 8:57 AM by gene33 RSS
dmease729 Champion 267 posts since
Jul 22, 2011
Currently Being Moderated

May 7, 2013 10:32 AM

Query on use of IPS simulation mode in new deployments

Hi there,

 

A while since I have deployed a new NSP solution (going back to 6.1 days I believe), and I was not previously aware of the IPS simulation mode (From looking into this, I would gather it was included in v7.0 onwards, with a few improvements in later versions to allow assignment of the mode to interfaces instead of just sensors).

 

We are looking to deploy 7.1 (more similar to previous versions than 7.5!), and we want to initially start with the sensors in IDS (sensors will be physically inline), moving to inline IPS after a baselining period during which attack filters could be created and assigned.  Based on the above, could somebody confirm my understanding of pros and cons against the approaches below?  The approaches listed below assume that the initial policies are based on the default policies (ie there are no specific rule sets that have been configured), and that there is a need for different policies on different interfaces for future management and operation purposes.

 

Feel free to add your own pros and cons also - my feeling is to go with Approach A and use the 'new' simulation mode.

 

cheers,

 

 

Approach A:
- Clone 'Default Inline IPS' policy and name 'My Policy'
- Assign 'My Policy' to relevant sensor/interface/subinterface
- Enable simulation mode on relevant sensor/interface
- Push configuration to sensor
- Wait for baselining period
- Review alerts, and configure attack filters and filter assignments as required
- Disable simulation mode

 

Pro: The same policy is kept from start to finish, and no amendments are needed with the exception of the attack filters and filter assignments
Pro: Any new signature set that is applied will be included as per the original rule set (in this case 'Default Inline IPS') - therefore any new signatures that get applied that are recommended for blocking will be blocked from the outset
Con: Only con I can think of is similar to the above pro - change control may not want any new signatures being automatically blocked (customer decision)

 

Approach B:
- Clone both 'Default IDS' and 'Default Inline IPS' policies, naming 'My IDS Policy' and 'My IPS policy' respectively
- Assign 'My IDS policy' to relevant sensor/interface/subinterface
- Push configuration to sensor
- Wait for baselining period
- Review alerts, and configure attack filters and filter assignments as required
- Change policy from 'My IDS policy' to 'My IPS policy' (same policy but IPS is configured to block on relevant sigs.  As attack filters are applied, nothing *should* get blocked that shouldnt get blocked)

 

Pro: Any new signature set that is applied will be included as per the IPS rule set that is now applied (in this case 'Default Inline IPS') - therefore any new signatures that get applied that are recommended for blocking will be blocked from the outset
Con: In my mind, a little more fiddly than Approach A, as the change over to the IPS policies results in a new policy being pushed out, instead of a simple switch from simultation mode
Con: Change control may not want any new signatures being automatically blocked (customer decision)

 

Approach C:
- Clone 'Default IDS' policy and name 'My IDS Policy'
- Assign 'My IDS policy' to relevant sensor/interface/subinterface
- Push configuration to sensor
- Wait for baselining period
- Review alerts, and configure attack filters and filter assignments as required
- Bulk edit agreed sigs and set sigs to block

 

Pro: Based on change control requirements, below con could actually be a pro
Con: Although we are now running in IPS mode, any new signatures will never block as the rule set is based on the IDS ruleset
Con: Most fiddly option of the 3 approaches

  • gene33 Newcomer 35 posts since
    Jun 15, 2012

    The only approach that even makes sense to me is the first one really.  The others are more work for little reward.  You want an IPS but you don't want to block without knowing what will get blocked.  Use the simulated blocking feature to know what will / won't get blocked.  Smart Blocking will only block high confidence alerts so the best way to see examples is to use simulated blocking.  I block on more signatures than what is configured out of the box, but that kind of thing always needs to be tailored to the environment.  I always start with the default IPS policy (cloned) and then begin monitoring and making adjustments from there.

  • gene33 Newcomer 35 posts since
    Jun 15, 2012

    You can definitely manage the simulated blocking just from NSM (and this can either be sensor-wide, or per interface).   You can also enable/disable it from the command line as well, but generally you would just use NSM.  Most configuration tasks can be done from the command line, but typically use the NSM.  I have simulated blocking on a couple of sensors for a company that is really cautious about IPS.   Basically it just changes the result to "Blocking Simulated" (which means it WOULD have been blocked, but since you are simulated, the traffic went through).  See screenshot:

     

    2.png

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points