Have user-based Bypass option feature in agent.
J
James Read
At the moment the ability to use the 'Bypass' protection feature is limited to a per computer deployment / deployment key group. It would be great to have this feature based on user groups, in addition to entire PCs, such as via On-premise AD & AzureAD groups, like we can use for Policy groups settings.
Having this apply on a per user (or user group) basis could reduce the potential attack surface, and ensure only known controlled certain users have this privilege, instead of enabling an entire PC which could be used by several users, thus increasing the risk of bypassing the security of DefensX by malicious actors.
Log In
B
Brian Miner
I agree that this would make the bypass feature more useful and this would then allow us to stop uninstalling and re-installing the agent to do granular testing to see if DefensX is causing a specific symptom. However, we would need good administrative audit logs. Ideally, this feature should come with a timer so that we can enable a very granular bypass for a finite period of time.
C
Cody Arnold
Brian Miner I find it rare that I ever need to uninstall/reinstall to troubleshoot, the only thing we can't solidly see in the logs is things blocked by adblocker but easily enough we just have an adblocker exclusion policy where we toss a domain in, and if we update policy and it fixes the problem, we know.
if not, we remove and test, 99% of situations it's not DefensX.
That being said, group based bypass isn't a bad option however imo, but users shouldn't have the ability to bypass on their own since people are likely to just disable it the moment something gets blocked in order to keep moving along, it's like someone has the gun with no ammo, and you just gave them the ammo to shoot themselves in the foot.
J
James Read
Brian Miner I have put in place a temporary work around, which involves using a GPO that changes the deployment key to one that has the bypass option enabled. No need for a uninstall/reinstall then. It works but it is a bit clunky and sometimes does not apply instantly, but that is inherent to GPOs along with the usual Kerberos ticket refresh more then anything, when adding a user into a group. Agreed, a proper audit trail of its use or a logged solution would help. I envisage this would be used by certain trusted people; admins; troubleshooting & testing; and enabling remote users getting out of a bind when nothing else works.