Managed ITDR

Our client deployment processes include a "tuning" period for a week at the start to review unwanted access escalations with the point of contact. I recently had a client who wanted a copy of the Application or Client the user was attempting to use in the reported sign-in event. This is avaialble from the entra sign-in logs, but does not appear to be ingested by huntress. This additional data can help us understand what the user was doing at the time of alert

I like this new feature but I think it would be better if we could specify what IP addresses we want to whitelist for specific VPNs, instead of just allowing all "SonicWall VPNs", etc. I also find that there are going to be a lot of issues with Apple's Private Relay stuff. Not sure how to handle those.

Currently the Unwanted Access Escalation Emails will only send out if there is no PSA detected. If there is a PSA detected then only the PSA will receive the ticket and no email will be sent out. The partner would like to have the functionality to do both at the same time as this interrupts their response process.

It would be amazing if you could create an expected location rule for a specific user with a policy expiration date through the Huntress API. Seeing as how you already sponsor CIPP, I think this would be a great addition to their existing vacation mode, which excludes a user from a conditional access policy for a period of time. This would prevent the Huntress escalation for the unknown location, as it would already be defined before the user traveled. Other partners could also use this API with other automation platforms like Rewst. This would reduce the need to hop to different portals, allow us to be more proactive, and provide better details to the Huntress team without our help desk forgetting.

When responding to an ITDR escalation the options to add "Account" and "Organization" Unexpected\Unauthorized rules within the UI are much more prominent than the option to add the same rule to an "Identity". My recommendation would be to make the Identity option equally as prominent. "Account" has a very similar meaning to "Identity" when discussing O365 administration so at a glance this looks like the two options users expect to have. Yes, this is explained in the Huntress documentation. Yes , this we informed our techs during our onboarding. Yes, it says the name of our Account right there next to the "Create Rule for Account" button. No, this was not enough to stop users from consistently making inappropriate Account level rules. I understand the intent with the "resolve actions" big buttons to allow multiple escalations to be resolved with the same rule at once, but ideally we are so quick to close the typical one off escalation that there is only ever one open escalation at time. Ideally the typical user experience is to view the respond section with only one identify in the list. In this situation, I do not believe the three vertical dots at the end of the solitary offending-identity-information-row were we must first consider "Login Count" "First Seen At" and "IPs (last 14 days)" before we can get to the our true goal, the 3 vertical dots button, are as obvious to the average person as the sweet siren call of the big red and green buttons immediately after the bold text "Resolve Actions". As a third\bonus option it would be great to have the option to deny account level access rules\settings by security role for users created in the top level account. To my mind it undermines having privileged organizations if they can be effected by rules created by users whose non-admin role forbids them access to the privileged organization. We want these users to have admin access to any organization, but we dont want them to have admin access to every organization in a single action. If this was once or twice I would just blame the user and move on, but this has happened by several different users and they all offer variations of the same feedback provided above.

I would like to have the ability to bulk add unwanted access rules, specifically to set all VPN providers and countries, except the United States, to Unauthorized at the root account level. This feature would greatly enhance our security management by allowing us to efficiently manage access rules without having to create individual rules for each entity.

Can we get Watchguard VPN as an option in the ITDR VPN unwanted access rules?

Since enabling the 'VPNs Unauthorized by Default' feature, all VPN usage now generates Critical level incidents, which automatically trigger phone alerts 24/7, including a recent 2 AM call. While I want to detect and prevent unauthorized VPN usage, the Critical severity level creates unnecessary after-hours disruptions for routine violations. I'd like to request a severity level of High for unauthorized VPN incidents. One that generates tickets for business hours investigation without triggering phone calls, unless accompanied by additional suspicious activity. I'm happy to receive urgent calls for genuine security threats, but 2 AM notifications for a colleague's forgotten Proton VPN connection seems excessive. Could you consider adding the ability to select the severity option for default VPN detections or allowing custom severity rules for different incident types?

it's a bit of a pain to have to log in to huntress to see who these notifications are referring to, especially when i see the notification through my phone or via my ticketing system it would be helpful to have the user and tenant listed in the subject line or at least the body of the email so i can jump right into their m365 tenant and verify is the sign in is a problem

Currently this is only available at the Account / MSP level and not granular down to Organization / Client level.