IBM Security QRadar

Containers are changing the way of how software’s are built and delivered, build it once and run it anywhere, onsite, or on the cloud.

IBM Security QRadar is capable of ingesting and detecting security threats in Kubernetes deployments, onsite, and on the cloud. 

Many use cases can be derived to highlight the threats for security analysts. These include:

• Failed requests to get the Kubernetes secrets.
• Leaked container token.
• If a container token will be used to execute commands over other containers.
• If a container token will be used to create another container.
• Mounting of sensitive or critical volumes to a container.
• Creation of a privileged container, or DaemonSet.
• Successful API requests from anonymous user.
• Successful API requests from unusual countries.
• Successful API requests from different geographies using the same access token.
• Multiple forbidden requests initiated from the same username.
• Command execution over containers in the Kubernetes system namespace.
• Creation of an unusual privileged role.
• To dynamically baseline which users can call which APIs.

 
The Kubernetes use cases are available out of the box and can be downloaded here:
IBM QRadar Container Content Extension

You can have a Kubernetes cluster onsite or on-cloud, and in this post we will go over the needed steps to ingest Kubernetes API logs from Amazon Elastic Kubernetes Service (Amazon EKS).

From AWS console, go to Amazon Container Services -> Amazon EKS -> Clusters

In my case, I only have one cluster as seen in this image:

We will need to go to that cluster to enable the logging options:

Click update, and enable the audit logs (Kubernetes API logs) option, as following:

The logs will be saved into a CloudWatch log group, by going there we can see the respective log group:

Going inside the log stream, we can see the kubernetes API logs already being saved there:

You can use QRadar Amazon Web Services protocol to ingest the logs from CloudWatch to QRadar.

Add a new AWS log source as following:

Select Amazon Web Services protocol:

Enter the log source name, description:

 

Add the log source identifier, and the AWS access key and secret:

 

Choose the AWS region:

Choose the AWS service as CloudWatch and enter the name of the CloudWatch log group as following:

Enable the following options:

• Extract Original Event
• Use As A Gateway Log Source
• Automatically Acquire Server Certificate(s)

 

This log source will act as a collecto, will get the logs from AWS cloudwatch log stream, and will onboard them to QRadar under a kubernetes log source with the specified identifier which is: "kube-apiserver"

for the Log Source Identifier Pattern, you can use:

kube-apiserver=.

As following:

After saving and deploying the changes, we will start getting the Kubernetes logs as following:

Additional resources

Amazon Web Services protocol configuration options

Kubernetes DSM guide

IBM QRadar Container Content Extension

IBM QRadar Custom Properties for Kubernetes