Managed ITDR

MDR for Microsoft 365
VPN Device Suppression - Alert/Report for Devices without Huntress Installed
Hi, its great the device suppression option has been added for vpn escalations. However based on the wording below I have some concerns. Concern: Compliant devices: Suppresses unexpected country and VPN escalations (Default: ON) Entra Joined / Hybrid Joined: Suppresses unexpected country and VPN escalations (Default: ON) Entra Registered (BYOD tier): Suppresses unexpected country and VPN escalations (Default: OFF) If a hacker somehow managed to gain access to the end users credentials, they technically could have the ability to Entra Join a device (depending on security configurations). Whilst I appreciate eventually Huntress will likely pickup the compromised account based on other actions in the M365 tenant, its still a concern in the short term. Request: Given Huntress has the ability to interrogate Intune, I would assume it then has the ability to also interrogate the discovered apps. From this, would it be possible to request that if any of these are turned on, then we have the ability within Huntress to enable a report/setting which flags to us at certain intervals that if a device is "joined and/or registered" in Intune and does not have the huntress agent installed, then Huntress will generate an alert or report? Intent: If a hacker manages to somehow join their device and block Huntress from being installed on their device, then Huntress (at a scheduled interval) will flag there is a device in the M365 environment which doesn't have Huntress installed which could be seen as a red flag or an opportunity to see why Huntress failed to install.
0
·
Unwanted Access…
Google Workspace - Account suspension support or agressive deauth
Based on conversations with Huntress support as well as our account manager it seems that ITDR for Google workspace currently revokes an active session once, but does not de-authenticate the account and does not perform more aggressive de authentication on subsequent logins. The Cited concerns for this in documentation is that it may be too aggressive and can break some google workspace functionality. I for one would find this acceptable so long as what breaks is documented and can be resolved by the admin. I would much rather cleanup a broken config if it is feasible, as opposed to allow malicious actors to freely roam on re-entry. Alternatively, if what breaks is not repairable or creates a massive support burden, we would like to at least see a far more aggressive session de-authentication for the user account, continuous, until the incident is resolved. Perhaps a forced credential rotation as well to help keep those sessions de-authenticated. If we can't block access completely via revoking access, I would hope it can be made far more difficult by other means. I understand perhaps the huntress team and some other administrators may not share the wish for this level of protection, so perhaps this could be implemented in an opt-in and granular level For example: Default experience: Current Opt-in settings/levels: Continue revoking sessions Force credential rotation Suspend and break integrations (The aggressive level Huntress suspects is too aggressive) This way we can keep those actions separate if anyone was interested in a more aggressive de-auth but not rotating credentials and not breaking those application connections. Some granular choice would ultimately be ideal in the matter. And as with anything, we would prefer this to be on a per-organization level, because each org may have their own preference of how aggressive they want to have it as well. Thanks for your consideration
2
·
Unwanted Access…
Load More