1 of 1 people found this helpful
<narcissism>The article you found is in my opinion one of the best pieces of literature McAfee has posted to the knowledgebase.
I don't know who the author could possibly have been, but oh my goodness I wish they'd write more articles </narcissism>
It's understandable to struggle with understanding this feature. I'll try to walk through the building blocks of understanding how it works, and from there perhaps you'll see how you can use it to meet your needs -
Think of these configurations as "scanning profiles". You have 3 of them, "High" "Low" and "Default". They could equally be called "Jon" "Simba" and "Cheese" it doesn't matter what they're called. We named them High/Low/Default to help you understand our intended usage for them.
Each scanning profile can be configured separately - this is why their names aren't important. Having these 3 scanning profiles gives you LOTS of flexibility for adjusting how the product provides protection to your environment.
The feature works like this:
- We identify the name of the process who is accessing a file on disk
- We check which scanning profile contains the name of that process
- If the process name is found in one of the scanning profiles, then the scanning configuration from that profile is used.
- if the process name is _not_ found in one of the scanning profiles, then the "Default" scanning profile is used
At this point, it is best to explain further by use of examples. The KB contains some examples. Perhaps you can ask more specific questions if still struggling with particular aspects of the feature.
Thank you for your replay.... Now i understand the the deference and how it works.
If I've created a high risk and low risk policy, if any new application or process running on my network,do i need to separate each new application and add them in to
high or low risk policy or it will be fine in default policy.....what do you suggest...and what is the best practices.
The best practice... while people will have their own opinions, the fact that you're considering use of this feature means you have 1 or more applications in your environment that need to be handled differently from others - Otherwise, stick with a single scanning profile.
The most common need to use multiple profiles is 1 or more special processes whose activity is causing a lot of scanning to occur, so much that the performance impact is unbearable. I'm assuming by this point that it has already been confirmed to be a scanning performance issue, not due to other features; this type of troubleshooting should've occurred already.
When recognizing a need for using multiple scanning profiles, evaluate "What configuration is needed" compared to "What configuration is safe/acceptable".
And that means there is no best practice. It will vary with each organization, even if they're using the same application .
This feature should therefore be used to adapt our flexibility in scanning configurations to the custom needs of your environment.
"What configuration is needed" vs. "What configuration is safe/acceptable"
If you're making any change to our default configuration settings, chances are you're reducing your scan protection coverage.
This is not an activity that should be taken lightly. Punching holes in your AV protection means opening doors/windows for known threats to enter your environment. Proceed with caution...
What you should do:
1. Find out what scanning configuration allows this special process to work normally, with acceptable performance.
- Does it perform the way I expect with OAS disabled (i.e. no Read scans, no Write scans)?
- Does it perform the way I expect if OAS is enabled but only Read scan is disabled?
- Does it perform the way I expect if OAS is enabled but only Write scan is disabled?
2. The more you know about how that process behaves, the more granular you can refine the configuration to keep security at its highest. Additional questions -
- Is the special process accessing the same folder or various folders?
- Is the special process accessing the same files, or file types?
These questions let you know if exclusions are viable, and they too can be granular to read/write actions.
When you have the answers to these questions, you can assign this special process to your Low-risk profile and configure the low-risk profile accordingly.
You have then punched a hole in your AV coverage, however, you've made it as small as possible and still meet your needs for performance gain. That is a big Win for this product feature - historically, with single scanning profiles, if you defined an exclusion or disabled read or write scans, it applied to your entire AV posture... VSE lets you limit holes like that to specific processes, while maintaining your usual protection level for all other processes.
Sorry folks if that's a bit wordy. It's a powerful feature, difficult to explain well, so it might take a few reads to digest.
Thanks a lot for your reply,
I got additional information's too....That was so useful...i gohead and deploy whatever you said...
For more information on High-Risk, Low-Risk, and Default processes scan policies,
Kindly find the below McAfee KB Articles,
1 of 1 people found this helpful
As heavy user of Low Risk scan policies this advice is right on. I use it heavily for servers. I have many different low right policies for server types (SQL, Web, ect) and many for just a single server. Exclude just the stuff giving us grief. We do have few things universal in all low risk policies, like most of the McAfee executables themselves and the back up software.
If I have any complaint it is that the manuals do not fully explain the power of this feature.