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.
Chris Bisnett
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.
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.
Chris Bisnett
What types of events would you be looking for and how would you like to get the notifications? It sounds like these would be potentially security related, but without having them sent to the SOC I'm not sure. Our intention is to fully manage the SIEM product from making sure the right data is ingested to detecting malicious events to ensuring the data is stored for compliance retention purposes.
J
Jonathan Pilkington
Chris Bisnett Honestly the main thing would be brute force attempts on a AD accounts. Similar to how M365 alerts to when there are a lot of failed CA login failed attempts.
S
Scott Thomson
Chris Bisnett another example would be RDP connections from non-LAN IP. Our RMM's RDP functionality tunnels thru the RMM agent, so all RDP connects that it uses appear from localhost, plus any customers that need external RDP access use a brokering tech that doesn't involve firewall/port forwards.
SO for our customers & managed devices - any RDP connection logged from non-LAN IPs -or- from the local LAN gateway (indicating gateway/firewall is remapping the inbound IP to the gw address) would be exceptions and something we'd want to investigate.
J
Jonathan Pilkington
Scott Thomson Agreed we know what IP's should be using RDP on certain computers so being able to alert on that would be great.
C
Cindie'la Dicki'la
Chris Bisnett an example would be 3rd party apps that log to Event Logs where we want to know that something triggered but its not something we need the SOC to investigate.
A
Anthony Rankine
Chris Bisnett some examples would be... to see when a USB drive has been plugged in, Browser/outlook process interacting with files (user opening attachments), DNS or browser connection events to verify if a user clicked or browsed to a malicious website.
J
Joel DeTeves
Scott Thomson this is one of our primary use cases also