3 Replies Latest reply: May 8, 2013 8:57 AM by gene33 RSS

    Query on use of IPS simulation mode in new deployments

    dmease729

      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

        • 1. Re: Query on use of IPS simulation mode in new deployments
          gene33

          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.

          • 2. Re: Query on use of IPS simulation mode in new deployments
            dmease729

            Hi gene33,

             

            Many thanks for your answer - to be honest it was expected, and makes sense - was maybe a simple question but I always like starting up a discussion as there can always be some way of doing things that may have been overlooked.  Have you used the simulation feature before?  I note that on p397 of the IPS Administration Guide (v7.1 rev J) it advises "The set ipssimulation disable and show ipssimulation status commands are used to manage Simulated Blocking. For more information, see Network Security Platform CLI Guide." - I am wondering why there would be a need for them to explicitly state this if the enabling and disabling of ipssimulation can be fully controlled from NSM - although I appreciate that the latter command (status) can be used to confirm that the configuration has indeed been picked up.  The wording of the statement *seems* to imply that it is recommended that ipssimulation is managed from the sensor...  I would be interested to see what happened if it was disabled on CLI but a config (with it enabled) was pushed out from the NSM - I would assume that the NSM config would override (enable it).

             

            There is always something in McAfee documentation that makes me wonder if there is any reason that they felt the need to explicitly state something - makes me wonder if there are some nuances with the workings of the functionality being discussed.

             

            Going to end there, I do tend to waffle on :-)

            • 3. Re: Query on use of IPS simulation mode in new deployments
              gene33

              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