If you do incident response work, you know it doesn’t matter whether you work for a large corporation or a small organization — an incident can strike at any given time.

Unfortunately, there are often huge time lapses between when an incident occurs, when it is detected and when the security team can address it. That’s why, as the threat landscape evolves and expands, it’s increasingly critical to adopt automated incident response processes.

Collecting Event Information

To get started, you need at least two types of data:

  • Continuous event collection and monitoring of your assets; and
  • Threat intelligence.

All of your assets — or at least the most important ones — should generate events to be monitored for anomalies. Ideally, these events are logged in a central location via a log collector with a relatively long retention time.

Setting up a good logging and monitoring framework can be a daunting task. The key is to start small and fully understand the content of the events that your assets generate. Be aware of what you’re missing, what’s not included in the event data and what cannot be logged by your assets. Then, slowly expand and start including other event sources and assets not already in scope. The National Institute of Standards and Technology (NIST) provided useful guidance for logging and monitoring in NIST Special Publication 800-137.

Sharing Threat Intelligence Data

You can receive and share threat data by deploying your own threat intelligence platform and connecting it to community-driven sources. Having early access to this type of information enables security teams to detect malicious actions as early as possible in the attack phase and adapt their defenses accordingly.

Although there’s more to threat intelligence than just indicators of compromise (IoCs), these often represent the first level of data that analysts use to detect an incident. For this reason, it’s important to develop and exercise a process for consuming and verifying IoCs.

Despite the event data from critical assets and the threat intelligence data applied to these events, breaches often go undetected for weeks, months or even years. The time from compromise to detection — also known as dwell time — is a major issue for many organizations, but there have been signs of improvement. The global median time from compromise to discovery was 99 days in 2016, but half of the respondents to the “2017 SANS Incident Response Survey” reported a dwell time of fewer than 24 hours.

Moving Toward Automated Incident Response

Fast detection is important, but so is prompt containment and incident response. According to the SANS survey, 53 percent of respondents reported a detection-to-containment time of less than 24 hours in 2017. This fast response time is good, but still leaves attackers with plenty of time to cause havoc or steal information. How can we improve this process and move further toward automated incident response?

There are several different approaches to orchestration and automation. One strategy is to collect all forensic data related to an alert and then present it in a summarized view to the analyst. This approach requires the analyst to decide what steps to take next. Another approach is to define follow-up actions after the data collection that can be deployed either automatically or with an analyst’s approval.

Automated Digital Forensic Acquisition

When an alert is triggered, it’s natural to want to collect additional information and event data from the host or environment that triggered these alerts. It’s often impossible to gain physical access to the system, especially if you are working in an environment with a lot of remote workers. The following tools can help you collect the necessary data:

  • Mozilla InvestiGator (MIG) — MIG is a cross-platform, agent-based solution that facilitates real-time collection of data and information from endpoints, including file and memory inspection. It is designed to be fast and asynchronous with a focus on privacy and security. Agents never send raw data back to the platform — they only reply to questions. All actions are signed by GNU Privacy Guard (GPG) keys that are not stored in the platform.
  • GRR Rapid Response — GRR is a cross-platform incident response framework focused on remote live forensics. Both the agent and client are written in Python. This tool enables fast and simple collection of hundreds of digital forensic artifacts.

Incident Response Orchestration

In addition to forensic investigation, you can also automate post-incident response processes. In most cases, these activities are conducted in response to not a single incident but a combination of events, ideally ones that are validated by different sources.

Open source tools such as TheHive can help analysts implement this approach. TheHive is an incident response platform that enables security teams to collaborate to improve the quality of their investigation. Analysts can work on different tasks and consolidate the results into a single case. The information in the tasks can be automatically enriched with data and context coming from external sources, such as VirusTotal and PhishTank.

TheHive seamlessly integrates with the Malware Information Sharing Platform (MISP) and analysts can use its Python API client to collect data from a security information and event management (SIEM) solution or phishing mailbox. If you like scripting, you can achieve quick wins with TheHive by adding your own analyzers to the underlying enrichment engine.

LogicHub also provides native deep analysis and correlation. It integrates with other security solutions to enrich data and add contextual information to each investigation. One of those integrations is VMRay, a malware detection and analysis solution.

The usefulness of such integrations is best demonstrated in the context of phishing alert triage. Let’s say that a suspected phishing message is sent for analysis to a dedicated mailbox. A manual evaluation of a phishing email would require an analyst to look at the originator data, the maliciousness of the URLs therein and the nature of the attachments. These steps take time and can become tedious, putting your analysts at risk of alert fatigue.

With an automated solution, LogicHub can pull the email from the mailbox and immediately investigate the email originator, including Sender Policy Framework (SPF) and Domain-Based Message Authentication, Reporting and Conformance (DMARC) checks. It can then extract the URLs found in the email body and query them against VirusTotal, OpenPhish and MISP. All of the attached files from the email are submitted to VMRay, which analyzes the files and returns the results back to LogicHub. The results from VMRay are correlated with the other sources of data enrichment previously collected and LogicHub calculates a combined score.

This whole process happens automatically and is presented to the analyst to review. Any changes made by the analyst are recorded and applied to future investigations. If the investigation turns up a real threat, LogicHub can kick off automated response and remediation actions with the analyst’s approval. In the case of phishing, the platform can automatically remove the malicious email from the mailboxes of all the impacted users.

Start Small to Reap Big Benefits

By collecting events from different data sources, enriching them automatically with context and information from threat intelligence feeds, conducting automatic attachment and URL analyses, and proceeding with automated response activities, security teams can vastly improve the quality and speed of incident investigations.

However, this type of integration cannot happen overnight. It’s important to start small, assess what works within your environment and then extend accordingly with additional sources.

Watch the Think 2018 live session: Intelligent Orchestration — The Future of Incident Response

More from Incident Response

When the Absence of Noise Becomes Signal: Defensive Considerations for Lazarus FudModule

In February 2023, X-Force posted a blog entitled “Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers” that details the capabilities of a sample attributed to the Lazarus group leveraged to impair visibility of the malware’s operations. This blog will not rehash analysis of the Lazarus malware sample or Event Tracing for Windows (ETW) as that has been previously covered in the X-Force blog post. This blog will focus on highlighting the opportunities for detection of the FudModule within the…

Breaking Down a Cyberattack, One Kill Chain Step at a Time

In today’s wildly unpredictable threat landscape, the modern enterprise should be familiar with the cyber kill chain concept. A cyber kill chain describes the various stages of a cyberattack pertaining to network security. Lockheed Martin developed the cyber kill chain framework to help organizations identify and prevent cyber intrusions. The steps in a kill chain trace the typical stages of an attack from early reconnaissance to completion. Analysts use the framework to detect and prevent advanced persistent threats (APT). Organizations…

Defining the Cobalt Strike Reflective Loader

The Challenge with Using Cobalt Strike for Advanced Red Team Exercises While next-generation AI and machine-learning components of security solutions continue to enhance behavioral-based detection capabilities, at their core many still rely on signature-based detections. Cobalt Strike being a popular red team Command and Control (C2) framework used by both threat actors and red teams since its debut, continues to be heavily signatured by security solutions. To continue Cobalt Strikes operational usage in the past, we on the IBM X-Force…

What is a Red Teamer? All You Need to Know

A red teamer is a cybersecurity professional that works to help companies improve IT security frameworks by attacking and undermining those same frameworks, often without notice. The term “red teaming” is often used interchangeably with penetration testing. While the terms are similar, however, there are key distinctions. First and foremost is the lack of notice from red teams. Pen testing may be scheduled in advance to assess the ability of specific security measures to handle a simulated attack; red team…