Endpoint Policy Updates and GSM

  • 20 May 2020
  • 3 replies
  • 294 views

Userlevel 1
  • Fresh Face
  • 3 replies

Hi

I just wanted to ensure my understanding on how endpoints (managed by GSM) get policy updates and how this is reflected in the GSM portal.

Setup:

  1. I have a group called “test-group”
  2. I have a policy applied to the group called “test-policy”
  3. I have a pc in that group called “test-PC”
  4. The test-policy has polling interval set to 15 minutes

 

Questions:

  • If I make a change to the policy, “test-PC” endpoint should reflect that change within a max of 15 minutes?
  • How long should I then expect for that change to then reflect back in the GSM portal.
  • If a policy polling interval is 15 minutes, then the “Last Seen” value should never be more 15 minutes in the past (unless of course the device has been switched off)?

 

2 Specific examples:

This morning I have turned on the Evasion Shield for a group of servers and this afternoon they are still not reflecting the change. Polling is set to 15 minutes and the “Last Seen” value is within the last hour.

Another example this morning I enabled the Evasion Shield for a policy/group of 5 computers. It took 2.5 hours for GSM to recognise and display that Evasion Shield was turned on.

 

Thanks

T


This topic has been closed for comments

3 replies

Userlevel 6
Badge +26

@17G 

Your general assumptions are correct regarding poll setting in the policy assigned to any given endpoint. However, there are a few caveats and expectations to consider.

  1. Polling should reflect policy changes within their respective time frame. However, it’s not exact as there are many reasons the agent “calls home” outside the polling period, which will reflect inconsistent “last seen” times. (Realtime shield checks determinations, monitoring activity may check with threat servers etc… - not related to polling.)
  2. Polling is dependent on routing inconsistencies and may not always make 100% connection every 15 minutes. While it should, there are too many variables across the general internet. We suggest this setting to overcome these limitations making the agent more communicative throughout the day.
  3. If the agent is busy with other activities, the policy polling could possibly be interrupted. 
  4. Lastly, a common misconception is, the agent calls your console directly, when it does not. It actually calls a series of backend server farms (There are many) for various functionality. It reports it’s MID (Machine ID) and keycode it was assigned during installation during these updates. That report/calling home/polling gets gathered up and sent to your console for updating. All this communication can invoke inconsistencies and timing will never be exact. While it’s fairly instantaneous, there are variables that may affect lag.

While you are testing and would like to get more immediate responses, there are several ways to invoke the agent to call home immediately or “on demand”. 

> In the system tray icon, right click the menu. → Refresh Configuration is basically a mechanism to tell the agent to check with home servers for any updates.

> Command line - much more consistent and is used often by testers and various automation partners.

“C:\program files (x86)\webroot\” wrsa.exe -poll (can also simply run CMD as admin, cd to the respective directory where WRSA.EXE lives and run this on demand. wrsa.exe -poll

 

For the long inconsistent time frames you mentioned, 2.5 hours to update would have to be verified with the local agent logs. Evasion Shields switch (Script Shield) in PC Settings gear icon will show “off” for both “off” and “Detect and report” in the policy settings and will not actually change until it’s been switched to “Detect and Remediate”. If that is inconsistent, please let support know about the time lag. It may be found in the logs as to why. C:\programdata\wrdata\wrlog.log - may have some clues.

Userlevel 1

Thanks Scott! Appreciate your comments. More questions :grinning:

 

We suggest this setting to overcome these limitations making the agent more communicative throughout the day

What setting are you referring to?

 

Lastly, a common misconception is, the agent calls your console directly

Can I get a support engineer to test this theory and record the times?

 

While you are testing and would like to get more immediate responses, there are several ways to invoke the agent to call home immediately or “on demand”. 

Noted and we use those commands already!

 

Evasion Shields switch (Script Shield) in PC Settings gear icon will show “off” for both “off” and “Detect and report” in the policy settings and will not actually change until it’s been switched to “Detect and Remediate”

This is not consistent with what we have seen. I have “Detect and report” set for the IT Admin computers and we all show the Script Shield as ON in Webroot.  I have a ticket logged for related inconsistency with the Evasion Shield setting (#324318) but support is slow. I would be grateful if someone could better assist further.

 

Is there a way to tell in agent logs whether the Detect and report is set as displaying off for “off” and “Detect and report” is confusing

 

Thanks Again

Userlevel 6
Badge +26

Thanks ScottI’m sure you meant-  (Shane)  :sunglasses: Appreciate your comments. More questions :grinning:

 

We suggest this setting to overcome these limitations making the agent more communicative throughout the day

What setting are you referring to?
Poll setting - default is “daily” we suggest in best practices to drop this down to at least an hour or less. Gives the agent 24 or more shots at calling home.

 

Lastly, a common misconception is, the agent calls your console directly

Can I get a support engineer to test this theory and record the times?

Absolutely you. can test the times/dates etc…  it will reflect the date/time stamp it last communicated with any of the servers and then updates your console. As a long time Webroot employee, I can tell you with 100% certainty that the agent does NOT talk directly to your console, so it’s not a “theory”. The Last Seen updates will usually reflect pretty close to updates. Example: when using the -poll - and you’re watching the console in the “Groups” tab list, it may say “Just now”  - It may also say “Yesterday” or 2 days ago, but may not give you exact “time stamp” - you can look at it in the “Groups” tab and click the endpoint hyperlink. In the lower left, it will display more details. “Last Seen” - May 20th, 2020, 15:55 (Which is what one of my own test machines reported “Just Now”. Which technically was over 15 minutes ago. So, not exact.

 

While you are testing and would like to get more immediate responses, there are several ways to invoke the agent to call home immediately or “on demand”. 

Noted and we use those commands already!  :sunglasses:

 

Evasion Shields switch (Script Shield) in PC Settings gear icon will show “off” for both “off” and “Detect and report” in the policy settings and will not actually change until it’s been switched to “Detect and Remediate”

This is not consistent with what we have seen. I have “Detect and report” set for the IT Admin computers and we all show the Script Shield as ON in Webroot.  I have a ticket logged for related inconsistency with the Evasion Shield setting (#324318) but support is slow. I would be grateful if someone could better assist further.

With this setting being recently exposed in the console, (Tuesday) it may have some inconsistencies. I’ve personally been testing it for a few months and haven’t interrogated the UI switch enough to be 100% certain I’m correct. So, i’ll verify.

 

Is there a way to tell in agent logs whether the Detect and report is set as displaying off for “off” and “Detect and report” is confusing.

There are codes in the log, but they’re not clear text, so yes, but not visible. I’ll go look at the “configuration” codes and see if I can discover which is which. 

PS… you’re welcome to reach out to me directly either through DM here in the community or shoot me an email directly if you’d like to schedule a more indepth discussion while testing. We can also discuss best practices and discuss any additional concerns.. shanec@opentext.com 

 

Thanks Again