1. Overview

Prisma Cloud’s runtime defense for container file systems continuously monitors and protects containers from suspicious file system activities and malware.

2. File system integrity

Prisma Cloud monitors and protects against the following types of suspicious file system activity:

  • Changes to any file in folders not in the runtime model.

  • Changes to binaries or certificates anywhere in the container.

  • Changes to SSH administrative account configuration files anywhere in the container.

  • Presence of malware anywhere in the container.

3. Malware protection

Defender monitors container file systems for malicious certs and binaries using data from the Prisma Cloud Intelligence Stream. Console receives the Prisma Cloud feed, and then distributes it to all deployed Defenders. You can optionally supplement the Prisma Cloud feed with your own custom data.

When a file is written to the container file system, Defender compares the MD5 hash of the file to the MD5 hash of known malware. If there is a match, Defender takes the action specified in your rules. Defender also looks for attributes that make files suspicious, including signs they’ve been rigged for anti-analysis.

By default, Defender monitors both the container root file system and any data volumes. Container root file systems reside on the host file system. In this diagram, the running container also has a data volume. It mounts the db/ directory from the host file system into its own root file system. Both locations are monitored by Defender.

The following diagram shows how Prisma Cloud protects containers from malicious files:

runtime defense fs 584208

4. File system integrity monitoring

Prisma Cloud ships with a default rule that monitors container file system integrity. You can see this rule under Defend > Runtime > Container Policy > Default - alert on suspicious runtime behavior. The default rule configures Prisma Cloud to continuously monitor and alert on suspicious file system activities in all running containers in your entire environment or cluster. When a rule is triggered, and the effect is alert, an audit is generated. You can view audits under Monitor > Events > Container Audits.

5. File system integrity defense

Create new runtime rules to augment the default rule. Runtime rules enable not only the detection, but also the prevention, of file system integrity violations so that your running containers can be actively defended.

Rule order and pattern matching are critical when designing policy.

The following procedure shows you how to create a custom rule to ensure file system integrity.

  1. Go to to Defend > Runtime > Container Policy.

  2. Click Add Rule.

    1. Enter a name for your rule. Spaces are permitted.

    2. Specify a scope.

      For this example, use an image name for one of your running containers and leave wildcards in all the other fields. For example, alpine:latest.

    3. Leave Prisma Cloud Advanced Threat Protection enabled. For more information, see TATP.

    4. Optionally select Kubernetes Attacks. For more information, see Kubernetes attacks.

    5. Click the File System tab.

    6. To ensure broad file system protection, set File system monitoring to Enabled.

    7. Under Denied & Fallback, set the effect when this rule is triggered.

      • Alert — Generates an audit and raises an alert when an file system integrity violation is detected. Container continues to run.

      • Prevent — Prevents any attempt to violate file system integrity. Container continues to run. For more information, see discrete blocking.

      • Block — Stops the container when an attempt to violate the file system integrity is detected.

        Audits are generated and alerts are sent (email, Slack, etc) when the effect is Alert, Prevent, or Block.
    8. Under Denied & Fallback, leave both Changes to binaries and certificates and Changes to SSH and admin account configuration files set to Enabled.

    9. Rules can augment learned models by explicitly denying folders in the model or explicitly allowing folders that aren’t in the model. The fields for denying or allowing folders are optional. Enter one or more paths. Do not use asterisks. By default, folders in the learned model are allowed, and all other folders are denied.