Threat Detection

ARMO Platform's Cloud Detection & Response (CDR) feature enables users to have visibility into the runtime environment and respond to threats in real-time. Using eBPF probes together with Kubernetes and cloud context, Kubescape effectively monitors the runtime environment for any suspicious activity.

Installation

To enable Threat Detection you can use the following flags in helm:

--set capabilities.runtimeDetection=enable
--set alertCRD.installDefault=true
--set alertCRD.scopeClustered=true
--set capabilities.nodeProfileService=enable

Platform

Navigate to the Threat Detection page and you should see the following screen (Hopefully without a crypto miner 😉).

In the top right corner you have an indication of the number of assets being monitored in your environment.
Below it you can find the different filters you can apply in order to narrow down the results.

Once you click on one of the threats you will see a screen similar to this:

In the graph you see the flow of the attack and where it occurred all the way up to the specific process.
You can click on the threat info to view more details about the threat, and browse the different events related to the attack in the events list. Each event is clickable and will open a side panel with the relevant details.

How it works

The runtime threat detection engine is divided into three main detection components:

• Anomaly detection 🔎
• Behavior analysis 🧠
• Malware scanning 🐛

Anomaly Detection

The anomaly detection part is responsible for detecting any abnormal behavior in the runtime environment. It does this by recording the normal behavior of the application and comparing it to the current state. If any deviation is detected, the engine will raise an alert.

ARMO Platform observes containers during a customizable learning phase to understand the application's typical behavior. It then stores this information persistently in objects called ApplicationProfiles (see here) , capturing details such as file access, network connections, system calls, and other relevant data. This profile, stored as a Kubernetes Custom Resource (CR), serves as a benchmark for normal behavior. Once the learning phase concludes and the profile is established, ARMO Platform compares real time application events coming from eBPF for deviations from this norm, triggering alerts upon detecting anomalies.

The durations for which the node agent will monitor a running container are set using the nodeAgent.config values in the Helm installation configuration.
Here are the default values:

nodeAgent:
  config:
    maxLearningPeriod: 24h 
    learningPeriod: 2m
    updatePeriod: 10m

To customize these values, you can set them when installing the chart:

--set nodeAgent.config.maxLearningPeriod=Xh
--set nodeAgent.config.learningPeriod=Xm
--set nodeAgent.config.updatePeriod=Xm

Behavioral Analysis

Additionally, ARMO Platform uses rules designed to identify well-known attack signatures. These rules are adept at uncovering various threats, such as unauthorized software executions that deviate from the original container image. For example: detection of unpackers in memory, reverse shell activities, and more. Users have the flexibility to create 'Rule Bindings'—specific instructions that inform ARMO Platform which rules should be applied to which Pods. This level of customization ensures that security measures are tailored to the unique needs of each Kubernetes deployment, enhancing the overall security posture and responsiveness of the system.

Malware Scanning

ARMO Platform can scan the nodes for malware using ClamAV, a popular open-source antivirus engine. ClamAV supports scanning of files, directories, and volumes, and can be configured to scan the entire node or only specific directories. You can read more about ClamAV here.

To save resources, ARMO Platform uses its own virus database which is a subset of the latest ClamAV virus database release adapted to the Kubernetes environment.

Viewing Alerts

Another way to view alerts outside of ARMO Platform you can use the following supported exporters:

Prometheus (Alertmanager)

--set nodeAgent.config.alertManagerExporterUrls=localhost:9093 or localhost:9093,localhost:9094

Syslog

--set nodeAgent.config.syslogExporterURL=localhost:514

HTTP

--set nodeAgent.config.httpExporterConfig.url=http://localhost:8080
# Optional
--set nodeAgent.config.httpExporterConfig.maxAlertsPerMinute=1000

STDOUT

--set nodeAgent.config.stdoutExporter=true

Rule Binding

The CR (Custom Resource) runtimerulealertbindings.kubescape.io is used to define the rules that should be enforced by the runtime threat detection & response engine. You can customize the bindings of the rules to the workloads by editing this object.
The CRD supports Kubernetes selectors to bind the rules to specific workloads.
By default all rules are applied on all workloads.

apiVersion: kubescape.io/v1
kind: RuntimeRuleAlertBinding
metadata:
  name: all-rules-all-pods
spec:
  namespaceSelector:
    matchExpressions:
      - key: "kubernetes.io/metadata.name"
        operator: "NotIn"
        values:
        - "kube-system"
        - "kube-public"
        - "kube-node-lease"
        - "kubeconfig"
        - "gmp-system"
        - "gmp-public"
  rules:
    - ruleName: "Unexpected process launched"
    - ruleName: "Unexpected file access"
      parameters:
        ignoreMounts: true
        ignorePrefixes: ["/proc", "/run/secrets/kubernetes.io/serviceaccount", "/var/run/secrets/kubernetes.io/serviceaccount", "/tmp"]
    - ruleName: "Unexpected system call"
    - ruleName: "Unexpected capability used"
    - ruleName: "Unexpected domain request"
    - ruleName: "Unexpected Service Account Token Access"
    - ruleName: "Kubernetes Client Executed"
    - ruleName: "Exec from malicious source"
    - ruleName: "Kernel Module Load"
    - ruleName: "Exec Binary Not In Base Image"
    - ruleName: "Malicious SSH Connection"
    - ruleName: "Fileless Execution"
    - ruleName: "XMR Crypto Mining Detection"
    - ruleName: "Exec from mount"
    - ruleName: "Crypto Mining Related Port Communication"
    - ruleName: "Crypto Mining Domain Communication"
    - ruleName: "Read Environment Variables from procfs"
    - ruleName: "eBPF Program Load"
    - ruleName: "Symlink Created Over Sensitive File"
    - ruleName: "Unexpected Sensitive File Access"
    - ruleName: "LD_PRELOAD Hook"
    - ruleName: "Hardlink Created Over Sensitive File"

Incoming Features

• Custom Policies: Users will be able to define custom policies instead of dealing with the runtimerulealertbindings.kubescape.io object and make smarter and better monitoring customizations as well as define the response policy.
• Response: The response part of the threat CDR solution will include a variety of possibilities to mitigate threats and response to attacks at real time.

Supply Chain Attacks (BETA)

ARMO Platform maintains a comprehensive view of both current and historical application profiles within the system. When an application, such as a Kubernetes deployment, is updated—typically through a new version of the container image—a new application profile is generated and uploaded to ARMO Platform.

ARMO Platform employs sophisticated rules to compare the new application profile with the previous one, enabling the detection of several key changes:

• New Processes: Identification of any newly introduced processes.
• New DNS Endpoints: Detection of new DNS endpoints being accessed.
• New External Network Endpoints: Identification of new external network connections.
• New Data Access Patterns: Recognition of new data being accessed.

These capabilities are crucial for identifying potential supply chain attacks, thereby enhancing the security and integrity of the system.

Anti-Tampering

The ARMO agent includes a robust anti-tampering feature designed to safeguard the integrity and functionality of the agent. This feature protects the agent from unauthorized modifications, ensuring that its security mechanisms remain intact and operational. By implementing advanced detection and prevention techniques, the ARMO agent can identify and mitigate tampering attempts, such as unauthorized changes to the agent’s code, configuration, or operational state. This ensures that the agent consistently performs its security functions without interference, providing reliable protection for your application environments.