Runtime defense

Runtime defense is the set of features that provide both predictive and threat based active protection for running containers. For example, predictive protection includes capabilities like determining when a container runs a process not included in the origin image or creates an unexpected network socket. Threat based protection includes capabilities like detecting when malware is added to a container or when a container connects to a botnet.
Prisma Cloud introduced runtime defense all the way back in our 1.1 release. In releases since then, we’ve continuously added to the feature set. This article describes the architecture of current runtime defense.
Prisma Cloud has four distinct sensors: file system, network, process, and system calls. Each sensor is implemented individually, with its own set of rules and alerting. The runtime defense architecture is unified to both simplify the admin experience and to show more detail about what Prisma Cloud automatically learns from each image. Runtime defense has two principle object types: models and rules.

Container Models

Models are the results of the autonomous learning that Prisma Cloud performs every time we see a new image in an environment. A model is the ‘allow list’ for what a given image should be doing, across all runtime sensors. Models are automatically created and maintained by Prisma Cloud and provide an easy way for administrators to view and understand what Prisma Cloud has learned about their images. For example, a model for an Apache image would detail the specific processes that should run within containers derived from the image and what network sockets should be exposed.
Navigate to
Monitor > Runtime > Container Models
. Click on the image to view it’s model.
There is a 1:1 relationship between models and images; every image has a model and every model applies to a single unique image. For each image, a unique model is created and mapped internally to the image digest. So, even if there are multiple images with the same tags, Prisma Cloud will create unique models for each.
Critically, models are built from both static analysis (such as building a hashed process map based on parsing an init script in a Dockerfile ENTRYPOINT) and dynamic behavioral analysis (such as observing actual process activity during early runtime of the container). Models can be in one of 3 modes:
When running containers in a Kubernetes cluster, Prisma Cloud considers the image, namespace, and deployment (YAML) file for creating models.
  • When there are multiple running instances of an image in the same namespace, Prisma Cloud creates a single model.
  • When there are multiple running instances of an image in the same namespace, but started from different deployment (YAML) files, Prisma Cloud creates multiple container models, one for each deployment.
  • When the same image runs in multiple different namespaces, Prisma Cloud creates separate models for each image in each namespace.

Learning mode

Learning mode is the phase in which Prisma Cloud performs either static or dynamic analysis. Because the model depends on behavioral inputs, images stay in learning mode for 1 hour to complete the model. After this 1 hour, Prisma Cloud enters a 'dry run' period for 24 hours to ensure there are no behavioral changes and the model is complete. If during this 24 hours period, behavioral changes are observed, the model goes back to Learning mode for additional 24 hours. The behavioral model uses a combination of machine learning techniques and typically requires less than 1 hour of cumulative observation time for a given image (it might comprise of a single container running the entire learning period or multiple containers running for some time slice where the sum of the slices is 1 hour). During this period, only threat based runtime events (malicious files or connections to high risk IPs) are logged. Prisma Cloud automatically detects when new images are added anywhere in the environment and automatically puts them in learning mode.
  • Relearn: You can relearn an existing model by clicking the
    Relearn
    button in the
    Actions
    menu. This is an additive process, so any existing static and behavioral modeling remains in place.
  • Manual Learning: Users can manually alter the duration of learning at any time by starting and stopping the
    Manual Learning
    option in the
    Actions
    menu. This should be done with discretion because the model may or may not complete within the time period due to manual interruption. There is no time limit for manual learning and depends on user’s choice.

Active mode

Active mode is the phase in which Prisma Cloud is actively enforcing the model and looking for anomalies that violate it. Active mode begins after the initial 1 hour that the Learning mode takes to create a model. Because models are explicit allow lists, in enforcing mode, Prisma Cloud is simply looking for variances against the model. For example, if a model predicted that a given image should only run the foo process and Prisma Cloud observes the bar process has spawned, it would be an anomaly. Prisma Cloud automatically transitions models from learning mode into enforcing mode after the model is complete. During this period, runtime events are logged.
During the initial dry run period (the first 24 hours), model may switch automatically from Active mode to Learning mode depending on the behavioral changes observed, as mentioned above. This automatic switching only happens during the first 24 hours of model initiation. If violations are observed later on, they are logged as runtime alerts under Monitor > Runtime.

Archived mode

Archived mode is a phase that models are transitioned into after no containers are actively running them. Models persist in archived mode for 24 hours after being archived, after which point they’re automatically removed by an internally managed garbage collection process. Archived mode essentially acts a 'recycle bin' for models, ensuring that a given image does not need go through learning mode again if it frequently starts and stops while also ensuring that the list of models does not continuously grow over time.
Models display all the learned data across each of the runtime sensors to make it easy to understand exactly what Prisma Cloud has learned about an image and how it will protect it. However, what if you need to customize the protection for a given image, set of images, or containers? That’s the job of rules.

Rules

Rules provide administrative control over how Prisma Cloud uses the autonomous models to protect an environment. For example, if Prisma Cloud’s model for the Apache image includes the process httpd, but you know that process bar will eventually need to run within it and you want to ensure that foo never runs, you can use a rule that applies to images named httpd to add bar to the allowed process list and add foo to the blocked process list.
Rules allow administrators to add explicitly allow and explicitly blocked object to each sensor. Rules and models are evaluated together to create a resultant policy. The process for doing so is as follows:
model
(which contains only allowed objects) +
allowed objects from rule
-
blocked objects from rule
=
resultant policy
From the previous example:
model (
httpd
) + allowed object from rule (
bar
) - blocked object from rule (
foo
) = httpd and bar are allowed and foo always is an anomaly regardless of the model
To learn about rules ordering and pattern matching, refer to Rule ordering and pattern matching.
By default, Prisma Cloud has a single rule that simply says ‘use the models’. As with every other rule within Prisma Cloud, you can easily customize these behaviors by creating new rules, applying them to the desired objects with our regex like filtering, and then ordering them properly. Rules are executed sequentially, and once a match is found for the ‘applies to’ conditions, the actions in that rule are enforced. Only a single rule is ever enforced for a given scenario; while rules are combined with models as described above, rules themselves are never combined.

Best practices

One of the key goals is to minimize the amount of work customers have to do to manage runtime defense. For most customers, this means that only the default rule needs to be present and that Prisma Cloud will automatically create and manage models for it. Because the behavioral learning aspects of model creation have been significantly improved most customers will not need to create rules to change model behavior. Some exceptions may be in containers that are long running but change behavior throughout their lifecycle. This is atypical in most environments, as containers that need to be upgraded are typically destroyed and reprovisioned with a new image. However, if you do need to customize rules, here are some best practices for doing so:
Minimize the number of rules
 — Creating static rules requires time and effort to build and maintain; only create rules where necessary and allow the autonomous models to provide most of the the protection.
Precisely target rules
 —  Be cautious of creating rules that apply to broad sets of images or containers. Providing wide ranging runtime exceptions can lower your overall security by making rules too permissive. Instead, target only the specific containers and images necessary.
Name rules consistently
 — Because rule names are used in audit events, choose consistent, descriptive names for any rules you create. This simplifies incident response and investigation. Also, consider using Prisma Cloud’s alert profile feature to alert specific teams to specific types of events that are detected.

Recommended For You