4 Replies Latest reply on Apr 15, 2014 2:41 AM by Don_Martin

    Evergreen: Low/High risk policy and standard comprehension

    Don_Martin

      Hello,

       

      I just want to be sure I did understand the working of these nice Policys.

       

      Low Risk Policy and High risk policy

      Here you are able to define different process (example.exe, example.com, example.bat) and postdefine the working directory in which the process example.xyz is allowed to work under the given configuration (like "scan on read/write" or none of of them, looking out for pups which can came up used in any job or what so ever startet by the defined process). Just for OnAcessScanning.

      This is not the place to define generelly exclusions for Directorys - this policy is only good for the different setting in how to handle processes and their working directorys. Is this right?

      If I define example.exe as process exclusion the process itself is beeing scanned but not the directorys I defined nor the extensions I defined in exclusions - right?

       

      Difference low to high risk policy: You MUST mark at least one scanoption in high risk: on read or on write.

       

      standard risk policy

      Here - and ONLY here - you are able to set simple folder, extension and executable exclusion for OnAcessScanning. ("C:\Example.exe", "**\example\", "**\Example\**\Example.exe" and so on with other wildcards or LUNS or mounted Drives which are already scanned via other Agents on other systems)

       

       

      I have read nearly all articles in this forum and the KB-Articles but I am puzzled about the mechanismen of how the low and high risk policy works at all. Defining only directory exclusions in low risk policy is without use (tested with EICAR), defining these exclusion only in standard risk works fine. So I am wondering in how to make good use of low and high risk policy´s. For sure Office and adobe executables have to stay put in the high risk policy (I know the names of the policys are just "names" and could have been "Policy A" and "Policy B") but when I define a process in low risk Policy and don´t define working directorys is it working properly (like a Wildcard for every folder and drive) or is it just useless?

      When it is like a Wildcard (as example in high risk policy) and the executable I defined is working in a exclusion I defined in Standard risk: Will the executable scanned on read and write or does the standard risk policy overseed the high risk policy?

       

      Can someone explain how the link between the defined process and the folder exclusion in the low/high risk policy works? Or is it completely without a link and the folder exclusion got nothing to do with the procss exclusion (and If so: What is the folder Exclusion in low/high Risk policy good for in this case)? And...how about a nice and clean paper for it @ McAfee/Intel?

       

      My english is not as good as it should be so please feel free to ask for futher Informations if anything is not understandable.

        • 1. Re: Evergreen: Low/High risk policy and standard comprehension
          wwarren

          Hi Don,

           

          Most of the content you've probably seen on this topic was authored by me. And I apologize it isn't more clear . I try to tackle this topic in various ways because it's tricky for almost everyone to grasp. Let me try another way -

           

          Test 1: Detect EICAR (notice the process responsible for the file access is NOTEPAD.EXE)

          Place NOTEPAD.EXE in "Low risk" (Scan READ = On, Scan WRITE = On, no exclusions)

          NOTE: At this point in time the "Low risk" and "Default" and "High risk" profiles all have the same scanning configuration - the fact process names exist in different profiles means nothing.

          Open NOTEPAD, and write the EICAR test file virus string into the NOTEPAD window...

          Save the file to C:\TEST\eicar.TXT

          --> A detection should occur. The file was scanned after the WRITE occurred.

           

          Test 2: Use an Exclusion to Not Detect EICAR

          Configure the "Low risk" profile to add C:\TEST\ as an exclusion. No other changes (Exclude READ and Exclude WRITE are both enabled).

          NOTE: The exclusion is added to the "Low risk" profile only.

          Since NOTEPAD is still open, with the EICAR string in the window...

          Save the file to C:\TEST\eicar.TXT

          --> No detection occurs.  The process doing the work "NOTEPAD.EXE" is found to exist in the "Low risk" profile, and the "Low risk" profile has a folder exclusion for C:\TEST\. Therefore, no scan occurs.

           

          Test 3: Detect EICAR (notice the process responsible for the file access is EXPLORER.EXE)

          Since C:\TEST\eicar.TXT contains a valid copy of eicar, lets trigger a detection...

          Navigate to the folder C:\TEST

          Double-click the file eicar.TXT... do you know what application in your environment is being used to open TXT files?

          --> A detection should occur. The file was scanned when a READ was attempted - and who read it? EXPLORER.EXE

          Even though TXT files might be associated with NOTEPAD or some other text editor, it was EXPLORER.EXE who touched the file that triggered the scan. And EXPLORER.EXE is in the "High risk" profile, where there's no exclusion for C:\TEST\ therefore a scan occurs.

          Restating:  The exclusion in the "Low risk" profile for C:\TEST\ is not used because the process touching the file, EXPLORER.EXE, is not in that profile.

           

          Test 4: Lets infect NOTEPAD.EXE (kind of)

          Repeat Test 2, but this time save the file as "NOTEPAD.EXE" into the C:\TEST folder.

          The file is saved successfully.  You now have a "program" on disk that is actually a test-file virus .

          What will happen when you launch that program?  NOTEPAD.EXE is a process named in your "Low risk" profile... will the file be scanned?

          Navigate to the folder C:\TEST

          Double-click the file NOTEPAD.EXE...

          ---> A detection should occur. The file was scanned when a READ was attempted - and who read it? EXPLORER.EXE

          When a process is defined in your "Low risk" profile, the process itself will still be scanned - rather, it'll be scanned using the profile that contains the name of the process who is touching the file. EXPLORER.EXE is in the "High risk" profile, which has no exclusions for C:\TEST, and so we scanned the file NOTEPAD.EXE.

           

           

          In these tests, we demonstrate how important it is to be aware of what Processes are touching files. They are the ones that trigger a scan to occur.

          And when we use profiles, we can place processes into a profile that has a "better fitting" scanning configuration - the work done by those processes gets scanned using that configuration.

          If the processes we add to the "Low risk" profile are names used by Malware - we know those files themselves will still be scanned.

           

          Let me know if anything is still murky....

          In summary -

          • Process names matter.
          • The scanning profile those process names exist in, matters.
          • The configuration for each scanning profile matters.
          • And they are all used, allowing you to create secure scanning configuration with the least amount of risk should you have need to punch a hole in your AV settings. Or, in other words:

               Don't create the same exclusion for all 3 profiles; only create the exclusion for the processes that need it .

          • 2. Re: Evergreen: Low/High risk policy and standard comprehension
            Don_Martin

            Hello,

             

            I am sorry for the late reaction to your useful Post which helped me out :-)

             

            But I have juuust one more question: Defining more than one process which intentionally should not only be restricted for the given directory exclusions (Process A - Folder A and B, but not C; Process B - Folder C and A, but not B; process C - no restriction to any folder Exclusion one this system) is just not possible or we would have to screw up the high risk policy, true?

            I would like to restrict the OAS for some processes to specific folders but do not want to restrict other processes for the same system on the defined folder excusions (for example SQLServr.exe just need to be excluded for DB-Folder whereas Backup.exe should not scanned at all on the same system).

            • 3. Re: Evergreen: Low/High risk policy and standard comprehension
              wwarren
              Defining more than one process which intentionally should not only be restricted for the given directory exclusions (Process A - Folder A and B, but not C; Process B - Folder C and A, but not B; process C - no restriction to any folder Exclusion one this system) is just not possible or we would have to screw up the high risk policy, true?

              True, although there is another way which isn't documented.

              The product is capable of handling up to 8 different scanning profiles - we have exposed only 3 in the UI. 3 has been more than adequate based on field usage but like i say, it can handle more.  You ought to submit a PER for us, suggesting we expose more profiles for environments that have more complex needs.

              1 of 1 people found this helpful
              • 4. Re: Evergreen: Low/High risk policy and standard comprehension
                Don_Martin

                I allready submitted a PER. This could be one really good option :-)

                 

                Thanks a lot for sharing this Information! :-)