This looks great!

Love to try it, but not available yet for me. Does it only appear when *ALL* endpoint are at version 9.0.28?

The perquisite is only that the Agent Version is at 9.0.28 or higher, so it will work on any endpoint with that Agent installed. We updated everyone’s console on Tuesday, so it should be working for you. 

If it isn’t please raise a ticket with Support as I’m sure the Product Manger and  Dev  escalation team will want to help you out pronto.

Another factor is that Script reporting and policy only existing at the  Global not the Site level, so you need to be at the Global level.  

Gotcha.

So is there a way to differentiate policies at the site level? Or do I need to (re)create my site level policies at the global level if I want different Evasion settings within a Site?

Looks like a good feature but doesn’t seem that it’s rolled out yet.

It’s not listed in my policies and searching help files for “evasion” yields 0 results.

I opened a ticket.

Looking forward to turning it up (soon I hope).

@gcarey You need to look in the global policies - site policies. Had me confused too. Afaikt there’s no way to set/tweak in the site policies.

That’s a deal-breaker for our MSP, then. If we can’t control features at site-level, it’s no good. Unfortunately this is another reason we’re looking to a different provider for antimalware protection.

Agreed.  As a MSP, we need to be able to make this change in the individual site policies.  Until that change has been made, I am unable to enable this.  We do not use the global policies at all.

Does whitelisting a script apply globally to all sites, since this function is only available in the global policies? The FAQ just points to the regular file whitelisting / overrides...

If we do detect and report where do we find these reports? I enabled it last week to just test it but haven’t seen any reports yet. 

Thanks for the feedback. I was able to talk with our VP of Product Management about this who shared this with me:

We have policy control in 2 places in the console. For MSPs only using site level policies, they will need to import those policies into the global level and then enable Evasion Shield.

Here is a brief description:

At the GSM level, a policy can be created and it is possible to apply that policy to a single device, single site, or a combination of devices/sites. For many partners, this allows them to streamline and standardize management and policies across multiple sites. We support Evasion Shield in these policies.

At the site level, a policy can be created which is local to that site. It cannot be used across other sites. As we are migrating more wholly to the GSM level policies (which can still be applied to individual sites), we have only added Evasion Shield to this policy level.

As many partners have historically created site level policies, we have created a workflow to import them into the GSM level. This means you get the benefits of using them for a single site or multiple sites at the GSM level without having to re-create them from scratch. Once you import the policies you want, you can enable Evasion Shield on them at the GSM level.

Here are instructions on how to import a site-level policy into the GSM level policy management.

OK - so it’s easy enough to migrate policies from site level to global level, but what about applying those new global level policies as they were before the migration?  We are a two location MSP and we use the sites just for each of our locations.  Then, our customers are configured in individual groups in the dashboard depending on which location (site) sold them the Webroot licensing.  Some customers have custom policies for individual machines, etc.  This means that we would have to go through our entire list of 1500+ clients and make sure to reapply all of the new migrated global policies, correct?

It would certainly be much easier if they’d just allow the configuration of the Evasion Shield on a per site policy basis...

Hey @a-ics , 

I hear you.

I’ve gone ahead and reached out to @coscooper, one of our fantastic Sales Engineers who will be contacting you directly. He’ll be able to answer all of your questions and walk you through the new Evasion Shield. Look for an email and/or private message on the community. 

Thanks!

@CompuCraft_Dan  & @a-ics  - As @freydrew stated, thanks for the feedback.

As a point of discussion, there are several suggestions that I may offer to help with this situation.

1. At the main admin level - you can still manage your sites and groups without actually going into the respective “site management console” (hyper-link to site) - instead, there is a “Groups” tab at the top which allows you to create site groups, manage endpoints in those groups and mass apply policies or apply policies by group or by endpoint, just like the older site management console. Many of the commonly used Agent Commands are there as well, making the need to go to the site management console obsolete. Many long time users aren’t aware of this section and have found it to be both helpful and faster than using the site management console.
2. Global policies - our current best practice guidance encourages everyone to use global policies for standardization and ease of management over using site policies. Site specific policies, as has been suggested earlier, can be imported to the global level and used as before using the Groups tab above taking advantage of the Evasion Shield and all new expanded options going forward.

So, theoretically, using the Groups tab above at the global level gives you the same functionality and allows you to use the updated feature, Evasion Shield, very much like you’re doing today.

To provide context around site management console, it is no longer being updated as all of the current development efforts, updated tools, expanded products and all future direction will be done at the main admin console level. As a heads up, the individual site management console will be deprecated at some point in the future. While the site creation concept and endpoint management will not change, the way endpoints are managed will change. The entire admin console is being redesigned and will not include the site manager, rather all functionality will be moved to the top level, similar to "Groups".

Hope this helps.

the problem im seeing in all of this, how are permissions supposed to be handled? you only have 2, technically three permissions level, super admin, limited admin, site admin. your essentially forcing MSPs to make all engineers (and those with clients that co-manage) to be super admins. 

for clients that have access, those with a technical staff, making them a site level admin is essentially useless if they cant manage the global policies.

it also doesnt make sense to give a ‘key to the castle’ for every single engineer. thats too many people that can edit global settings.

am i missing something?

I am sort of wondering the same thing.  I am very uncomfortable moving all of my policies around.  I’ve got everything set up exactly how it needs to be already.  I do NOT need to deal with a mass exodus of phone calls, should one of these policies cause issues.  I also have zero desire to go through and re-apply my policies to all my 1500+ endpoints.

Until this whole Evasion Shield thing came about, I wasn’t even aware that there were global policies!

This is really a big mess.  We’ve been using Webroot for many years now, but this is really making me consider other alternatives.  We really like the product, but things like this aren’t acceptable.  We don’t all have the time to go through each and every endpoint and move them to the global policies.  It’s far easier said than done!!

@a-ics  & @msptech 

Fully understand your concerns. Unfortunately, as a software development organization, decisions have to be made that impact many variables, including user interfaces and administrative consoles. Many decisions start with performance and backend systems and then is presented in the user interface as best possible.

Because of the importance of providing the highest efficacy in the industry, it was decided to introduce all new product direction at the primary console level for speed and efficiency.

For the two concerns, Policy management and Admin access, there are work arounds that can be applied that take little effort.

For policy Management:

> It has always been our best practice recommendation to include global policies to sites making them available to every admin. (Simply create two global policies for your respective customer site(s) one with Detect & Report, the other with Detect & Remediate. Site admins can apply them as needed.)

> Newly created policies can be applied to the site “Default” policy whereby all endpoints assigned to a given site using the default policy will automatically pick up the new policy that has Evasion Shield applied.

> Policies can be applied to batches through reassigning the default policy on a given group or select all endpoints and change their policy at once. This is not time consuming and takes a few minutes to implement.

Site Administration:

> Once global policies are created and accessible, any site administrator can use them and apply them appropriately. (They have a globe icon to the left at the site level.)

> You could create a global purpose built admin with “Limited” admin privileges set and remove all other site visibility from that user making them a global site only admin. That user can see all scripts detected and reported in the console using the Groups tab as well as run reports in the Reports tab.

> For overrides, that same user or any site only admin user can create overrides at their respective site level just as before to manage the overrides aspect as both global and site overrides work for all endpoints across the entire threat landscape and Evasion Shield script overrides work just fine with site overrides.

The ONLY limitation at the global level that a “Limited” admin does NOT have the ability to create policies and create overrides at the global level whereby it’s more advantageous for the MSP to manage global policies and overrides. From there, once the policies are established and the overrides can be made at the site level, it’s set it and forget it.

If you’d like to schedule some 1:1 time with myself or anyone on our team to help work through these issues and the level of effort, we’ll be more than happy to provide links to our calendars. DM me through the community or send me an email at: shanec@opentext.com 

understand the development requirements in that you can’t accommodate for every edge case that is out there. i’d still argue that after the technical limitations are factored in, security should be the guiding factor over efficiency.

do you have a general eta on when some of the GSM changes are scheduled for? would certainly take you up on the offer to go over it once the new changes are there.