Application Profiles & Behavioral Baseline

Overview

ARMO Platform uses Application Profiles to understand the expected runtime behavior of workloads in your Kubernetes environment.

An Application Profile is a behavioral baseline that captures what “normal” looks like for a specific workload. ARMO builds this profile during an initial learning period by observing runtime activity such as process execution, file access, network activity, system calls, and other workload behavior.

Once the learning period is complete, ARMO compares real-time runtime events against the Application Profile. If the workload performs an action that was not observed during learning, ARMO can generate an anomaly-based runtime incident.

Application Profiles are used by ARMO’s anomaly detection engine and work alongside rule-based behavioral analysis and malware scanning to provide layered runtime threat detection.

How Application Profiles work

The Application Profile lifecycle includes three main stages:

1. Learning starts

   After ARMO is deployed and the workload is running, the ARMO node agent begins observing the workload’s runtime behavior using eBPF.

2. Runtime behavior is recorded

   During the learning period, ARMO records the workload’s expected behavior and stores it as an Application Profile.

3. The baseline becomes active

   When the learning period is complete, the Application Profile becomes the workload’s behavioral baseline. From that point on, ARMO compares real-time runtime activity against the baseline and detects deviations as anomalies.

What is captured in an Application Profile?

An Application Profile captures runtime behavior observed during the learning period.

Together, these signals create a behavioral fingerprint of the workload. This fingerprint helps ARMO determine whether future runtime activity is expected or anomalous.

Learning period

The learning period is the time window in which ARMO observes a workload and builds its Application Profile.

By default, the learning period is 24 hours:

nodeAgent:
  config:
    maxLearningPeriod: 24h

To customize the learning period globally, set the nodeAgent.config.maxLearningPeriod value during Helm installation or upgrade:

--set nodeAgent.config.maxLearningPeriod=Xh

For example, to set the learning period to 48 hours:

--set nodeAgent.config.maxLearningPeriod=48h

Configure the learning period per workload

You can also define a different learning period for a specific workload by adding the kubescape.io/max-sniffing-time label to the Pod template.

For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        kubescape.io/max-sniffing-time: "5m"
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:latest

Use this option when a specific workload requires a shorter or longer learning window than the default configuration.

What happens during the learning period?

During the learning period, ARMO observes the workload and builds the Application Profile.

Anomaly-based detections for that workload depend on the completed Application Profile. This means that anomaly detection becomes effective after the learning period is complete and the baseline is established.

Rule-based behavioral analysis and malware scanning are not dependent on a completed Application Profile and can operate immediately after deployment.

Profile status

You can review the Application Profile status from the workload view in ARMO Platform.

Typical profile statuses include:

Profile scoping and workload changes

Application Profiles are created per workload and represent the behavior of a specific workload version.

Routine Kubernetes operations, such as restarting a Pod or scaling a Deployment, do not usually require a new learning period because the workload behavior is expected to remain the same.

However, when the workload changes in a meaningful way, ARMO may build a new Application Profile. Examples include:

• A new container image version
• Changes to environment variables
• Changes to mounted volumes or runtime configuration
• Other workload specification changes that may affect runtime behavior

This allows ARMO to keep the behavioral baseline aligned with the current version of the application.

How the baseline is used for anomaly detection

After the Application Profile is completed, ARMO continuously compares real-time runtime events against the learned baseline.

If ARMO observes behavior that was not part of the Application Profile, it can generate an anomaly-based runtime incident.

Examples of anomaly-based detections include:

These detections help identify behavior that may indicate compromise, misuse, lateral movement, or unexpected application activity.

Reviewing and tuning anomaly detections

After the learning period is complete, review anomaly-based incidents to determine whether they represent expected behavior or suspicious activity.

Common examples of expected behavior that may generate anomalies include:

• Scheduled jobs that did not run during the learning period
• Maintenance tasks
• Rare administrative actions
• Traffic patterns that only occur under specific conditions
• New behavior introduced by an application change

If the behavior is expected, you can tune the detection by using runtime incident risk acceptance or by adjusting the learning period for the relevant workload.

If the behavior is suspicious, investigate the incident and handle it according to your incident response process.

Best practices

Use the following best practices when working with Application Profiles and behavioral baselines:

• Allow the default 24-hour learning period to complete before evaluating anomaly detection quality.
• Use a longer learning period for workloads with periodic or scheduled behavior.
• Review anomaly-based incidents after the first learning cycle.
• Tune only behavior that is confirmed to be expected.
• Re-check anomaly behavior after major application changes or new deployments.
• Use Application Profiles together with rule-based behavioral analysis and malware scanning for layered runtime detection.

Relationship to Threat Detection

Application Profiles are part of ARMO’s runtime threat detection capabilities.

They are specifically used by the anomaly detection engine to detect deviations from expected workload behavior. Other runtime detection engines, such as rule-based behavioral analysis and malware scanning, operate independently of Application Profiles.

For more information about ARMO runtime threat detection, see Threat Detection.