Automated incident response can benefit security both in the cloud and in traditional settings. Read what it can be used for and how it helps.

Despite the increase in breaches and security incidents we hear about regularly, many incident response teams are understaffed or struggling to find the right skill sets to get the work done.

Today, more enterprise incident response teams actively look for opportunities to automate processes that often take up too much time for highly skilled analysts, as well as those that require lots of repetition and provide little value in investigations. Common activities that many teams consider automating include the following:

• Identifying and correlating alerts: Many analysts spend inordinate amounts of time wading through repetitive alerts and alarms from many log and event sources, and then spend time piecing together correlation strategies for similar events. While this is valuable for the later stages of investigations, it can also be highly repetitive, and can be automated to some degree.
• Identifying and suppressing false positives: This can be tedious work on a good day and overwhelming on a bad one. Identifying false positives can often be streamlined or automated using modern event management and incident response automation tools.
• Initial investigation and threat hunting: Analysts need to quickly find evidence of a compromised system or unusual activity, and they often need to do so at scale.
• Opening and updating incident tickets/cases: Due to improved integration with ticketing systems, event management and monitoring tools used by response teams can often generate tickets to the right team members and update these as evidence comes in.
• Producing reports and metrics: Once evidence has been collected and cases are underway or resolved, generating reports and metrics can take a lot of analysts’ time.

James Carder and Jessica Hebenstreit of Mayo Clinic provided several tactical examples of automated incident response in a past RSA Conference presentation:

• automated domain name system (DNS) lookups of domain names never seen before and driven by proxy and DNS logs;

• automated searches for detected indicators of compromise;

• automated forensic imaging of disk and memory from a suspect system driven by alerts triggered in network and host-based antimalware platforms and tools; and

• network access controls automatically blocking outbound command-and-control channels from a suspected system.

There are many more areas where automated incident response can help, especially in forensic evidence gathering, threat hunting, and even automated quarantine or remediation activities on suspect systems.

Endpoint security vendors have begun to emphasize response automation activities and integration with detection, response and forensics capabilities. Analysts need to quickly identify indicators of compromise and perform lookup actions across other systems, as automating as much of this as possible is a common goal today.

There are a fair number of vendors and tools that can help integrate automation activities and unify disparate tools and platforms used for detection and response. These include Swimlane, FireEye Security Orchestrator, CyberSponse, Phantom, IBM Resilient Incident Response Platform, Hexadite and more, most of which use APIs with other platforms and tools to enable them to share data and create streamlined response workflows.

Things to consider when evaluating these types of products include maturity of the vendor, integration partners, alignment with SIEM and event management, and the ease of use and implementation.

Automated incident response in the cloud

Incident response in the cloud may rely on scripting, automation and continuous monitoring more heavily than in-house incident response does. Currently, many of the detection and response tools emerging for the cloud are heavily geared toward automation capabilities, which tend to be written to work with a specific provider’s APIs, many of which are focused on Amazon Web Services (AWS) at the moment.

Teri Radichel wrote a paper on AWS automated incident response and released a simple toolkit to help with it, as well.

The ThreatResponse toolkit developed by Andrew Krug, Alex McCormack, Joel Ferrier and Jeff Parr can also be used to automate incident response collection, forensics and reporting for cloud environments.

To truly implement automated incident response in the cloud, incident response teams will need to build automated triggers for event types that run all the time — such as AWS CloudWatch filters — especially as the environment gets more dynamic.

Deciding what triggers to implement and what actions to take is the most time-consuming aspect of building a semi-automated or automated response framework in the cloud. Do you focus on user actions? Specific events generated by instances or storage objects? Failure events? Spending time learning about cloud environment behaviors and working to better understand normal patterns of use may be invaluable here.

None of these tools and methods will replace skilled, knowledgeable security analysts who understand the environment and how to properly react during an incident scenario. However, unless we start detecting and responding more quickly, there’s no way we’ll ever get ahead of the attackers we face now and in the future.

via: techtarget