3 Replies Latest reply on May 30, 2014 8:04 AM by shakira

    Built in thresholding ruining a custom rule

    shakira

      Didn't realize there was built in thresholding for HIPs rules until I ran into this issue. Thresholding article here:https://kc.mcafee.com/corporate/index?page=content&id=KB67073

       

      The default timeout is 30 seconds.

       

      A given signature does not generate two or more events for the same user/process within 30 seconds. You cannot override this via the policy, but you can by modifying the following registry value:


      [HKEY_LOCAL_MACHINE\SOFTWARE\McAfee\HIP\eventfiltertimeout]

       

      NOTE: This is the number of seconds to wait before generating another event for the same signature/user/process.

       

       

       

      Is there really no way to turn this off besides on the registry key of each endpoint? Why isn't this a setting on a rule by rule basis?

       

      Long story short, I need to get around this so I can watch for known bad malware enumerating specific dlls in quick succession on execution. This allows me to filter later on in our logs and see which endpoints have fired 10+ of this rule off within a microsecond of each other. This let's me know the malware has activated.

       

       

       

      Is there a solution to my problem? Instead of housing a list of dll's in one subrule, can I create one subrule for each dll instead? If that doesn't work, what about creating one rule for each subrule?

       

      Message was edited by: shakira on 5/28/14 1:18:04 PM CDT

       

      Message was edited by: shakira on 5/28/14 1:24:00 PM CDT
        • 1. Re: Built in thresholding ruining a custom rule
          shakira

          After testing I realised I had to make 10 different rules, each with one file rule looking for a specific dll. One dll per subrule, inside one rule did not work because it still thresholded.

          • 2. Re: Built in thresholding ruining a custom rule
            Kary Tankink

            Is there really no way to turn this off besides on the registry key of each endpoint? Why isn't this a setting on a rule by rule basis?

            There is not; the change is global for all signatures.  Submit a PER (KB60021) if you'd like to request this functionality per-signature.  Lowering this Eventtimeout value can cause a huge increase in logging and events sent to ePO, which would flood the server and affect system performance.  The EventTimeout is to add some aggregation filtering on the client and ePO server side.  I tested it with HIPS 8, and with a 3sec timeout, 1 signature created 25k+ signature violations and almost 200 ePO events in about 5 minutes (system performance was definitely impacted).

             

            As you found, separating these by Signature numbers will eliminate the threshold you're seeing, but remember there is a limited number of custom signatures that can be created (total 1998).

             

            KB70638 - Cannot create custom signature. Too many custom signatures exist. (issue: reached maximum limit on number of custom signatures)

            1 of 1 people found this helpful
            • 3. Re: Built in thresholding ruining a custom rule
              shakira

              Thanks Kary. I understand that lowering it could increase in logging. That's something that happens with every single IDS/IPS out there. We have a test environment to prevent such issues.

               

              The problems are that this default threshold isn't obvious to the end user nor is it changeable once found (on a rule by rule basis where it matters). I've been looking through logs and viewing endpoints behaviors under the wrong assumption all along. To add to the confusion, hipshield.log doesn't threshold. This tells me the endpoint's perfomance is not saved by this thresholding, only the ePO server is.

               

              As for a rule firing 25k+, well again, that rule needs to be remade or thresholded. That doesn't mean every rule out there should though.

               

               

              Thanks again.

               

              Message was edited by: shakira on 5/30/14 8:04:02 AM CDT