Incident Response Tips

Ilya Solovey

• January 24, 2018 15:56

After using AlertLogic for almost a year, I've created a few filters and alerts that help me understand an incident. Does anyone have any useful tips / filters / process that help with incident response.?

Here is mine:

1. Setup a Event Alert called Brute Force Attack which alerts on MySQL and SSH BruteForce attacks. I add signatures as more common attack types occur. 

2. If I get an alert, I check events with a similar filter for signatures that contain brute. I try to understand what subnet or server is being targeted. 

3. I check the source IP (or IPs) for malicious reputation via a third party site like Cymon. 

4. Then I check if any events generate an Incident for further correlation. 

5. I gather the time frame and check what system changes were logged prior to the 'attack' to understand what might have triggered this attack. If it wasn't a system change, I block the IP on the Firewall. 

6. Finally I check the logs on hosts that were targeted to confirm nothing was affected. 

 

Thanks

Yes 2 No

• Official comment

  

  Oliver Pinson-Roxburgh

  • February 21, 2018 14:15
  • Edited

  This is great. I would also suggest using aggregation around the incident to help focus the investigation using the Log Manager Omnibox. It really helps summarise the logs to help spot anomalies.

  This knowledge base article on Omnibox should help you get started if you aren't familiar with its functionality: Log Manager Omnibox Log Search
• 

  Paul Le Page

  • February 21, 2018 12:57

  Thanks for sharing this. I find it interesting that you are looking so closely at events and that you're using event alert rules. There is absolutely nothing wrong with this approach, but as our primary output to customers is Incidents, this is what I had expected most customers to focus on.

  Events are the raw output from our IDS sensors - every time network traffic is seen which matches a signature (of which we have tens of thousands), an event is generated. Events tend to be high volume and low fidelity - so we leverage advanced analytics to find the "needle in the haystack" - although often it is more like trying to find a needle in a stack of other needles! You can read more about some of the analytics techniques we use in this blog post: https://www.alertlogic.com/blog/alert-logic-cuts-through-the-noise-to-find-web-application-attacks/

  Our SOC analysts and security researchers also use the raw event data to drive improvements to our detection capabilities.

  The output from analytics is an Incident - this is the "needle" that we've found, and it will be comprised of (usually) multiple events and/or log messages. Incidents are escalated to you by our Security Operations Centre by phone or email depending on the severity, which indicates the seriousness of the threat and the risk to your environment. 

  You can read more about incident severities and how we handle them in this article: https://support.alertlogic.com/hc/en-us/articles/115001451547-Incident-Handling-Policy

  My general advice to clients is to focus on Critical and High severity incidents first - these indicate a successful attack or compromise against your environment, and require immediate attention. Our SOC analysts will work closely with you during the process to ensure you have all the information you need to address the issue quickly and effectively.

  Medium and Low severity incidents represent unsuccessful attacks - we keep an eye on these, watching out for further activity from the attacker, and will increase the severity if we see the attacker escalating. It is a good idea to review the Medium and Low severity incidents on a regular basis so that you are aware of what is being attempted against your environment, and if any trends or patterns are occurring. Our reporting (available in the console) can help with this, allowing you to decide if there is any action you wish to take. This could take the form of blocking IP addresses, closing unneeded ports, or to inform whitelisting or tuning request.

  We would be very interested to hear how other customers are consuming data from us, and the processes that you follow for incident response - if you would like to share, please add your comments below.

   

   

  Yes 2 No

Please sign in to leave a comment.