1 2 Previous Next 14 Replies Latest reply on Feb 3, 2015 4:58 PM by wwarren

    Configuring Low/High/Default risk processes policies

    mpearce

      Currently my company is noticing a high count of events that have access protection rules as the threat type.  Their solution is to add the executable or file path to the excluded process list in access protection (AP) for whatever rule was listed in the threat type.  Upon further research I have found that the detection method is OAS. Upon review of the OAS policies I have found that they have chosen to use one scanning policy for all processes instead of using low/high/default.

       

      My understanding of OAS is that it scans a process against the access protection rule set and if it finds a breach an event is fired noting that a threat has occurred.  My suspicion is that the event will fire every time OAS detects that an AP rule has been breached and that this is the cause of the high threat event count.  VSE seems to ignore the fact that the process is excluded in AP.  I am assuming this is by design? or is it a bug?

       

      I would like to get some clarity on why the events are still firing even when a process is listed under the exclusions for an access protection rule.  I suspect that the event will fire each time because the on-access scanner has no concept of low/high/default risk policies and it will ignore the AP exclusion.  If this is true why would ignore the process if it is excluded?

       

      I know that McAfee best practices will state that low/high/default policies should be used.  This is the direction I want to go.

       

      My question is if I start adding the processes they have listed as exclusions in access protection into the low risk process policy will this cause a reduction in events?  What is the difference between adding a process to the low risk list versus adding it as an exclusion in the access protection?

       

      Is there any documentation that explains in detail how the policies function?

        • 1. Re: Configuring Low/High/Default risk processes policies
          ansarias

          Hello,

           

          If process added to Low/High/default exclusion than it will help during scanning when ever that process is doing any read/write activity but if that process is captured in AP rules then we can stop only them if we have added into detected AP rule.

          Can I have sample log of that rule if you can share here?

          • 2. Re: Configuring Low/High/Default risk processes policies
            mpearce

            Perhaps my questions/thinking will make more sense given a threat event that was received.

             

            Source: C:\Program Files (x86)\EMC\NavisphereAgent\NaviAgent.exe

            Target: C:\Program Files\Common Files\Mcafee\systemcore\mcshield.exe

            Source User: <none, blank field>

            Target User: NT Authority\System

             

            Event ID: 1092

            Severity: Notice

            Threat Name: Common Standard Protection:Prevent Termination of McAfee processes

            Threat Type: Access Protection

            Action Taken: deny terminate

            Threat Handled: true

            Analyzer detection method: OAS

            Event description: AP rule violation detected and blocked

             

            The source process is in the excluded process list under that AP rule yet the event still fires.  The on-access delfault process policy is set to use one scanning policy for all processes. With the policies set the way they currently are this event will fire 700+ times in an hour from a single system.

             

            If I were to change the on-access default policy to use low/high/default policies instead of using one policy and add NaviAgent.exe to the low risk process policy would that cause a decrease in the number of these events?  If there is a better way to "quiet" this event please let me know.

            • 3. Re: Configuring Low/High/Default risk processes policies
              ansarias

              Thanks for log file, Adding NaviAgent.exe to the low risk process policy or default will not help to stop log the events.

               

              Its a known issue and I had same logs in my account also. I'll suggest to add NaviAgent.exe into McAfee access protection log under process to exclude in rule : Common Standard Protection:Prevent Termination of McAfee processes

              ScreenShot_ 01.49 04-Feb-15.jpg

              Please male sure to select correct access protection setting for workstation or server.

              Let me know if it fixes the issue.

              • 4. Re: Configuring Low/High/Default risk processes policies
                wwarren

                That rule triggers when a process tries to access a protected process, and in their access attempt they specify an ACCESS_MASK that explicitly includes the TERMINATE privilege.

                It does not trigger _because_ they are trying to terminate us, it triggers because they're seeking that ability.... and if we were to allow them to succeed in obtaining that privilege, then they could terminate us at any time.

                 

                There is no good reason why a 3rd party process needs to acquire the TERMINATE privilege against protected McAfee processes.

                It's typically a sign of coding practices where security via least-based privilege was not a consideration. It is also possible the programmer called a higher-level API that eventually made this request on their behalf, making their application susceptible to this behavior - either way, it's up to the vendor to correct this behavior. All we can do is tell you the workaround - excluding their process - and the risks of doing that (their process will be allowed to terminate our processes, better hope they never become compromised... which is easy to swallow with a large spoonful of wishful thinking ).  Naturally, I'd suggest looking to the vendor to improve their code rather than making an allowance that puts you at risk.

                 

                If it's the noise that's bothering you the rule can have reporting disabled, but then you lose all visibility of that rule being violated.

                • 5. Re: Configuring Low/High/Default risk processes policies
                  mpearce

                  Thanks for the advice, I noticed that the process is already in the 'processes to exclude' list. To me that says the process should be excluded and the event shouldn't fire.  But then again if the process is excluded and the report box is checked does that mean the event will still generate?

                  • 6. Re: Configuring Low/High/Default risk processes policies
                    ansarias

                    Completely agree with wwarren.

                    But this process is safe to exclude from McAfee AP.

                    naviagent.exe is used by 'NAVI Agent'.This is an application created by 'VeriSign, Inc.'. To stop naviagent.exe permanently uninstall 'NAVI Agent' from your system. Uninstalling applications can leave invalid registry entries, accumulating over time.

                    • 7. Re: Configuring Low/High/Default risk processes policies
                      wwarren

                      But this process is safe to exclude from McAfee AP.

                      No process is safe to exclude, not really.

                      When you add an exclusion you are saying "This process is allowed to terminate McAfee".

                      So, what happens when new malware manages to inject into their process and has code to terminate McAfee processes?  They get terminated, that's what. And even if you install current DATs that can now detect the threat, you're in a difficult place because that malware code is able to terminate our processes before we get a chance to scan+detect+clean.

                       

                      We don't stop people from making this sort of configuration change because it is You, the customer/User who ultimately decide what level of risk is acceptable when excluding a process from a rule.

                      • 8. Re: Configuring Low/High/Default risk processes policies
                        ansarias

                        well in my case customer has accepted the risk. The same risk has been presented to them and they were agree to accept it.

                        • 9. Re: Configuring Low/High/Default risk processes policies
                          wwarren

                          Thanks for the advice, I noticed that the process is already in the 'processes to exclude' list. To me that says the process should be excluded and the event shouldn't fire.  But then again if the process is excluded and the report box is checked does that mean the event will still generate?

                          No. The rule should not be violated by a process that is in the "Processes to exclude" list.

                          If it is still being triggered, then you have a policy issue to investigate. Either the policy change is not reaching the client, or has not reached it yet, or the policy is reaching the client but failing to be enforced.

                          1 2 Previous Next