Automating Response Actions with Cado

In the cloud, things are fundamentally different than in an on-premises world. The scale is exponentially larger in terms of numbers of workloads. Applications are much more dynamic and elastic, spinning up and down continuously.

As such, the old, manual way of responding to threats simply doesn’t work. By the time you've had a chance to kick off the necessary investigation and response steps from your legacy playbook, the attacker - and even the workload itself - is long gone.

What's more, the risk equation is different. Traditionally, performing any sort of automated containment was a big deal, since it could mean interrupting critical business operations - especially if things don’t go according to plan. However, in a resilient cloud-native environment, with thousands of load-balanced instances, the potential impact on the business when taking targeted, automated response measures, is much less.

Cloud security architects can really only benefit by finding ways to ruthlessly automate manual steps in the incident response process.

Introducing Cado Automation Rules

The Cado platform harnesses automation at its core to enable security teams to streamline the end-to-end process. From parsing a detection from services like AWS GuardDuty to performing a deep-dive investigation and taking response actions. Using Cado automation rules, security teams can easily define an automated incident response process according to their organization’s unique needs. There are three main components that are configurable and customizable: 

1. Choosing Environments and Scopes: Analysts define a group of cloud resources from which they’d like to collect forensic data from. 
2. Defining Automation Rules: Analysts define the type of investigation they wish to perform (e.g. triage investigation or full disk acquisition) and whether to pull in additional context from the relevant detection alert (e.g. AWS GuardDuty alert). 
3. Configuring Response actions: Analysts define automated remediation actions such as stopping, containing, or isolating an instance to prevent further damage.

An Example

Let’s imagine you have a web application running on an AWS EC2 instance in us-west-2 and malicious activity was detected by GuardDuty. You’ve previously defined the rule outlined below so that the instance is immediately triaged and a deeper dive investigation can take place.

Step 1: Choose Environments and Scopes

In this case, you’ve defined a set of criteria in which the target resource met. For example, analysts may want to define a specific set of rules for a certain group of resources that host more sensitive data.

Step 2: Define Automation Rules

From here, you can choose the type of investigation you would like to perform across resources that fall into the environment criteria you’ve defined above. In this case, we’ve configured a triage capture to take place (versus full disk acquisition). The Cado solution will also parse the corresponding GuardDuty alert to support the investigation. This can be configured by sending the alert to Cado’s investigation API endpoint or by enabling automatic GuardDuty monitoring within the Cado platform.

Step 3: Automate Investigations

The Cado platform’s automated investigation feature validates whether malicious activity has indeed occurred and provides a verdict to the analyst. Further, the solution automatically surfaces key details about the incident including a full timeline of events and the incident’s root cause, scope and impact.

Step 4: Immediately Respond

Since the verdict of this investigation was “Malicious Activity Identified”, the instance has been automatically stopped:

As you can see, after some relatively simple configuration, you can automate the entire end-to-end cloud incident response process using the Cado Platform. 

If you’d like to try this out in your own environment, take advantage of our free trial.