Cado Security, SentinelOne and Tines Make Kubernetes Investigation and Response Possible

A major challenge security teams face when investigating incidents in Kubernetes environments is due to the ephemeral nature of these resources. Often by the time an analyst is ready to investigate an incident, it’s likely that the resources no longer exist. While this obstacle is far too common amongst modern security teams, there is one straightforward solution: Automation.

This blog focuses on how security teams can set up an automated detection-to-investigation pipeline using SentinelOne Kubernetes Sentinel, Tines and the Cado Platform.

• SentinelOne provides comprehensive visibility across an environment - giving security teams the breadth they need to detect malicious activity as soon as it occurs.
• Tines delivers the ability to orchestrate workflows between different APIs.
• The Cado platform automates forensic-level investigations to deliver essential context and depth, allowing you to
• quickly identify root cause and craft an effective response plan.

By leveraging these three solutions together, threats detected by SentinelOne can automatically trigger a more profound investigation within the Cado platform. By incorporating automation throughout the end-to-end incident response process (data collection, evidence processing, and events investigation), security teams can effortlessly gain the level of detail they need to handle cloud risk appropriately. More specifically, when it comes to ephemeral resources, this approach ensures critical evidence is captured before it disappears and proper response actions can occur.

Let’s take a real-life example. Let’s say we’ve received an alert from the SentinelOne Singularity platform regarding a potential compromise in our EKS container environment.

From here, our goal is to ensure that any data associated with this potential compromise will be automatically preserved so that proper investigation and response can take place. 

Prerequisites:

1. Cado Platform (You can deploy a free version of the Cado platform to perform your own investigation.)
2. SentinelOne Singularity
3. Tines

Step 1. Generate API Keys:

The first step is to generate API keys for both SentinelOne Singularity and the Cado platform so we can access their APIs using Tines.

To generate a key for the SentinelOne Singularity platform, go to: Settings -> Users -> Click on chosen user -> Options -> Generate API token

Now, let’s create an API key for the Cado platform. Go to: Settings -> API -> Create New Key. A popup will appear on the screen with public and secret key, copy the secret one.

Step 2. Setting up Credentials and Resources in Tines:

Now we can store these two API keys securely on the Tines’ “Credentials” page. This will allow us to access them when we create our workflow in the next step.

Log in to Tines -> navigate to “Credentials” on the left navbar -> Click “new credentials”.

Do this twice, one for the “sentinelone” key and the other for “cadoplatform” (they can be named accordingly).

Additionally, for convenience, let's store the Cado Platform URL and SentinelOne URL in a “Resource” (to be used as an environment variable in our Tines workflow). On the same left navbar, go to “Resource”, then click “New Resource ''. Create two new resources, one for “cado_url” and one for “sentinelone_url”, as follows:

Step 3. Creating the Story/Workflow:

Believe it or not, we're almost done! On the Tines dashboard, create a new Story (alternatively, you can skip this section entirely and download the Story here and import it to Tines directly)

Next, we will need to drag three Actions from the left navbar to the story canvas:

3.1 Event Transform:

This action will run the Story according to the time interval you define. In this example, we will set it to run every five minutes. To define the time interval, simply drag the Event Transform action from the right, and then configure it on the left. You can leave all the defaults as they are, but you will need to add a scheduler as follows (note: you can only set a Scheduler once the Story is published):

3.2 HTTP Request 1: Get Active Threats from SentinelOne

This action will send an HTTP Request to the SentinelOne API to retrieve the active Threats (alarms) that were detected. We can send query parameters to narrow in on the alerts we are interested in investigating. In our example today, we'd like to investigate threats that were detected by a Kubernetes agent in the last five minutes (as this workflow is going to run every five minutes).

Let’s drag the “HTTP Request” action to our canvas, connect it to the Event Transform action that we just created, and configure the HTTP request as follows:

• Name: Change it to “Query SentinelOne Active K8s Threats.” 

• URL: The SentinelOne URL we set as a Resource in the previous step, plus the threat endpoint. Should be: /web/api/v2.1/threats​

• Method: A GET request

• Payload: Json with two query parameters, one to filter threats from the past five minutes, and the other to get only K8s threats.
  • Key: createdAt__gt
    • Value (a formula): UNIX_TIMESTAMP() - 300 |> DATE(%, '%Y-%m-%d %H:%M:%S')

  • Key:agentMachineTypes
    • Value: kubernetes node

• Authorization Header: “Authorization” as the header key, and “APIToken ” (where the refers to the credentials we saved earlier)

The end result should look like this:

3.3 HTTP Request 2: Investigate Detected Threats with Cado Response

Now that we have a list of all the active threats from the last five minutes, we can pass them along to the Cado platform, which will automatically create a new investigation, and collect all of the relevant assets. In this case, it will collect triage data from the container itself. Because this container runs on an EKS, it will also collect the CloudWatch and CloudTrail Logs related to this container.

Let’s drag another “HTTP Request” action to our canvas, connect it to the previous HTTP action that we just created for the SentinelOne API, and configure the HTTP request as follows:

• Name: You can change it to something like “Investigate Detected Threats with Cado”
• URL: The Cado URL you set as a Resource in the previous step, plus the investigate alarms endpoint: /api/v2/investigation/

This endpoint takes any alarm and kicks off an automated investigation. As part of this process, all relevant assets will be identified, collected and processed. From here, an initial level of analysis will be performed by the Cado solution and key details related to the incident are presented to the analyst.

• Method: A POST request
• Payload: the payload of this request will be the list of threats from the response of the previous request, we can do that by defining:
• Authorization Header: “Authorization” as the header key, and “Bearer ” (where the refers to the credentials we saved earlier)

The end result should look like the following:

Now, the remaining step is to publish the story and wait for alerts to generate. From here, within the Cado platform you will be able to see all relevant data to be able to quickly understand an incident, and to act upon it:

Cloud context:

As part of the automated investigation capability you see above, Cado collects triage data from the container itself but also proactively gathers other relevant data sources. In this case, because this is an EKS cluster, the analyst can gain essential context for their investigation from the CloudTrail and CloudWatch logs.

Conclusion and Next Steps:
As you can see, this workflow is extremely powerful. Using SentineOne, Tines and Cado Security’s combined solution, security teams are empowered to rapidly perform in-depth investigations and minimize time to respond. After publishing this Story, every five minutes you will have an automatic flow that will collect all the relevant assets for the new alarms/threats in your K8s environment. When it comes to attack containment, time is of the essence, especially in a Kubernetes environment.

So, now what? With this simple flow, you can already achieve a lot, but it can also be further improved, here are some additional suggestions:

1. Modify the HTTP request that queries the threats endpoint in SentinelOne and adjust the filters to be more specific to the threats you’re interested in (e.g. only threats with high severity or that are from a specific threat type, etc).
2. Add an additional step to the Story that will query Cado's investigation findings and act upon them.
3. If your team does not currently leverage a SOAR solution, this flow can be implemented with a Lambda function or even a python script that makes HTTP requests to Cado and SentinelOne APIs. 

You can download the Story and go from there!

For a more personalized demonstration of the Cado platform and how it integrates with other solution, don't hesitate to reach out!