Custom Alerts
under review
J
Jonathan Pilkington
It would be nice if you could create custom alerts for the SIEM. Basically create a query and if something meets the criteria send a alert. A few things that you would probably want for this feature:
- I don't think these alerts should go to SOC. As otherwise the SOC might get overwhelmed by custom alerts.
- Allow the custom alert to have a threshold before activated. For example set a threshold of 50 failed logins on user bob2 before triggering.
- While the alerts should not go directly to the SOC it probably would be helpful if visible to the SOC if something does happen.
Nate O'Brien
Merged in a post:
Custom Alerts Notifications
Chris Bisnett
Adding in custom alert notifications through Escalations within Managed SIEM for anomalous behaviors
L
Leith Magon
can you guys implement this asap please! we are wanting to centralize all logging out of huntress SIEM and push these alerts to HaloPSA using the integration already present in huntress. the idea being we can flag certain FortiGate UTM events in our ticketing system for review.
C
Christopher Culligan
The ability to create a custom query, save it as a report, structure it as needed, and set up recurring email delivery would be highly beneficial.
Chris Bisnett
Merged in a post:
Event Notifications
P
Paul Martin
It would be great if the Huntress SIEM could send us a notification when certain events are detected. For example, a new user account being added to Active Directory, a user being added to a security group, or an admin login to the firewall.
C
Chris Bennett
Yes, this feature would be much appreciated! It seems like a basic function to have in a SIEM.
J
Joel DeTeves
I can give you a textbook example of this Chris Bisnett (just got off a call with Chuck Fuquay btw discussing this exact request).
We use our RMM to monitor Windows Event logs for possible Remote Desktop door knocking / intrusion attempts. We get alerted whenever a user fails to log into Remote Desktop on an RD Gateway / Terminal Server.
It could be that the Huntress Team will monitor for such behavior but without knowing, it would be useful for us to set up custom alerts when these events happen.
Even as a non-security item, we have people who log in and get mad when the connection doesn't work - alerting allows us to be proactive and contact them to say hey, we saw you were having trouble logging in, can we offer you some help, etc.
Since the data is there, it does not seem too technically complex to simply say "generate an alert on these conditions" - that way, we can collaborate more effectively with both our clients and Huntress (if Huntress SOC team misses something, we can debrief and detections can be updated - whereas if we simply get alerted for a non-security issue, we can be more effective to our clients).
Hope that clarifies our burning desire for this feature.
Chris Bisnett
under review
We're considering this functionality because it's clear there is a desire for it. We want to be clear that our intent is that we will manage the data sources for security relevant events in the same way we do for EDR, so there shouldn't be a need to build your own security detections. It does appear that there is some desire to create other types of detections that aren't security related and wouldn't go to the SOC and that is what we're considering with this.
Scott
Chris Bisnett: That would be fantastic. What I'm hoping for, long term, is to leverage the work you've already done with PSA integrations (including the new round trip closure when relevant, though I haven't had a chance to experience it) to better handle key events from some of the 'other stuff' (syslog events from UI/network devices, external tooling) where we don't have a clean way to get that into PSA so it can be actioned using our standard flows. But even if that's not in the cards, being able to have Huntress SIEM raise key events/escalations from a variety of disparate sources in one portal would be leaps and bounds better than the firehose of noise and error-prone manual relay that we currently deal with.
Andy
Chris Bisnett I'm glad this is under review, and it would be a massive value add. A use case that I'm doubting would be detected by your default rules would be monitoring for break glass account access.
P
Phil Eldridge
+1 for this and the comment about monitoring brute force attempts on AD accounts. Any repeated entries for 4625 event ID's I think it is over a period of time would be great
J
Joel DeTeves
Phil Eldridge Failed Remote Desktop logins also - does not always correlate with a 4625
B
Billy Rudolph
I agree there should be some functionality that we can utilize for custom alerts that won't trigger anything with the SOC. We wouldn't use these to alert on malicious actions as I expect Huntress to manage that, but we would use these for various "nice to knows" (e.g. a domain admin logging in), Huntress will already have the logs and a method of querying.
If this isn't built in I can see many organizations still needing to utilize another system to reach this goal which adds complexity and costs.
Additionally if a system cannot send logs to multiple places (e.g. many syslog implementations) then that further complicates things as there will need to be a fourth system in place to send logs to both Huntress and the alerting platform.
J
James Stull
I'm thinking the ability to setup for various actions, such as risky logins, if you have multiple accounts getting password sprayed from the same host, a ton of files being downloaded from onedrive/sharepoint, etc.
Load More
→