Last fall we launched a new webcast series dedicated to sharing InsightIDR best practices, tips, and tricks for our customers. This installment of the InsightIDR Customer Webcast series will cover some of InsightIDR’s latest customization updates and how they can help accelerate your team’s time to respond.
Please join Rapid7’s product management, customer success engineering, and go-to-customer teams for an informative customer-focused webcast where you’ll learn about:
- How to create exceptions for Attacker Behavior Analytics (ABA)
- Priority options for both User Behavior Analytics (UBA) and custom detections
- How to hone in on and focus your investigation efforts on alert types most critical to your organization
Link to the webcast in Rapid7 Academy!!!
Really like these exceptions capabilities! Great webcast
@SDavis are there any plans of also allowing to create these kind of advanced exceptions on User Behavior Analytics as well? That would have been really useful and is something that I would love to see.
I believe so, but let me confirm.
Edit: I have confirmed this is the direction we are going.
That is great! Do you maybe have a timeframe for when that would be available? Me and my team are really eager for such possibilities
We don’t have a solid ETA to share yet, throughout this year we plan to migrate some of our UBA alerts. Starting with third party alerts, our AWS Guard Duty UBA alerts have already been migrated to ABA for instance, with more to come. Due to the complexity of some of our UBA alerts understandably some will take more time and effort than others - whereas third party alerts are pretty simple.
Okay so am I understanding it correctly that you need to migrate the alerts from UBA category into the ABA category to be able to do those advanced exclusions on the alerts like it is now possible in the ABA alerts?
That is correct, due to the current implementation of our detection engine, the exception rule builder only enables ABA alerts to avail of this functionality. Not to get too far into the weeds but all ABA alerts today are fired based on singular log events being observed such as a process start, which makes it easy to build exceptions based on those events.
However many UBA alerts span multiple logs, such as a Brute Force attack, or multi country authentications, we need to work on getting those multi event rules into our ABA engine in order to migrate them.
Since third party UBA alerts work in a much similar way to our existing ABA detection capabilities (single event observed-> fire alert) we can migrate those ones first.
Thanks for a great reply, that makes total sense!