How are you managing Alert Logic and AWS Guard Duty Integration?
Anyone out there integrated Alert logic and Guard Duty?
As Alert Logic doesnt sync back to Guard Duty for any remediated incidents we end up with two version of the truth and two places to have to manage findings and alerts.
How are you managing the GD findings and AL incidents?
Hi James — I have questions! What kind of sync functionality would help you here? For instance, do you archive GuardDuty findings in the AWS GuardDuty console to manage your workflow there? If so, what kinds of activities in the Alert Logic console would you be looking to map to archival? Closing an incident? Do you use the feedback mechanism in GuardDuty?
James - great question! Hopefully some fellow customers will send tips, but if you don't hear anything back in a few days we'll have an Alert Logic expert provide some suggestions.
So you're aware, I've moved this post into our Discussions forum so you can hopefully get a great conversation going!0
Hi Matt, I am just getting familiar with all this but a good example is one series of findings remediated in Guard Duty recently.
- Guard Duty reported that we had 2000+ findings for port probes on servers in 1 security group that had an open port to the internet.
- We closed the ports.
- We archived the findings in Guard Duty, and they have not returned. (Which is great as its fixed)
- However Alert Logic still has all the original incidents listed, and under Open Remediations 'the offending security group' is still listed.
- I have been unable to establish which Alert Logic Incident is related to a finding in Guard Duty, other than searching for something unique in the events.
Ideally we’d like to fix / repair a security group and close a ‘parent’ incident in Alert Logic and have all related incidents close with it (or have it detect the GuardDuty stuff has been archived and close the Incidents automatically..)
Can you advise the simplest method for managing these alerts and incidents going forward?0
It sounds like you're interested in a few different workflows:
1. Being able to reflect GuardDuty archival status in Alert Logic: when you archive a finding, the associated incident in the Alert Logic console is marked closed.
2. Being able to archive GuardDuty findings when the associated incident is closed: after an incident is closed, the finding would be archived if not already.
3. Search for GuardDuty findings in the Alert Logic console: This is supported today. You can search by the Finding ID (e.g. 52b53a588f046b902ced3669cec369a7) in the Alert Logic console. The Finding ID can be located in the AWS GuardDuty console, near the top of the detail pane that opens when you click on a finding. In the Alert Logic console, enter that ID in the standard Search field under Incidents, List.
Alert Logic's current integration with GuardDuty is unidirectional (AWS -> Alert Logic, via a CloudWatch Events stream). I'll raise a feature request to consider auto-closing archived incidents. However, there are some potential workflow issues that would need to be addressed because the typical delay on the CWE stream is 6 hours for updates.
For the inverse (Alert Logic -> AWS) synchronization, our push integration with AWS Security Hubs doesn't push Guard Duty incidents back to Amazon to avoid duplicating data there.
As we investigate more synchronization options, one avenue you can explore is using Alert Logic APIs to retrieve the current list of closed incidents and archiving Guard Duty incidents yourself using AWS APIs. For the general incident API, see https://console.account.alertlogic.com/users/api/iris/#api-Incident-Get_aggregations_for_a_list_of_fields You can look at how those queries are constructed in the Alert Logic console by using the web developer toolbar or similar functionality in your browser.
Thanks for the feedback!0
Please sign in to leave a comment.