End-of-Life (EoL)

Runtime defense for file systems

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

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.

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:

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

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
    6. To ensure broad file system protection, set
      File system monitoring
    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
        , or
    8. Under
      Denied & Fallback
      , leave both
      Changes to binaries and certificates
      Changes to SSH and admin account configuration files
      set to
    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.

Recommended For You