1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Vulnerability management
    6. Vulnerability management rules
    End-of-Life (EoL)

    Vulnerability management rules

    Vulnerability policies are composed of discrete rules. Rules declare the actions to take when vulnerabilities are found in the resources in your environment. They also control the data surfaced in Prisma Cloud Console, including scan reports and Radar visualizations.
    Rules let you target segments of your environment and specify actions to take when vulnerabilities of a given type are found. For example:
    There are separate vulnerability policies for containers, hosts, and serverless functions. Host and serverless rules offer a subset of the capabilities of container rules, the big difference being that container rules support blocking.

    Creating vulnerability rules

    Prisma Cloud ships with a simple default vulnerability policy for containers, hosts, and serverless functions. These policies have a rule named Default - alert all components, which sets the alert threshold to low. With this rule, all vulnerabilities in images, hosts, and functions are reported.
    As you build out your policy, you’ll create rules that filter out insignificant information, such as low severity vulnerabilities, and surface vital information, such as critical vulnerabilities.
    Rule order is important. Prisma Cloud evaluates the rule list from top to bottom until it finds a match based on the object filters.
    By default, Prisma Cloud optimizes resource usage by only scanning images with running containers. Therefore, you might not see a scan report for an image when it’s first pulled into your environment unless it’s been run. To scan all images on the hosts in your environment, go to
    Manage > System > Scan
    , set
    Only scan images with running containers
     to
    Off
    , and click
    Save
    .
    To create a vulnerability rule:
    1. Open Console.
    2. Go to
      Defend > Vulnerabilities > {Images | Hosts | Functions}
      .
    3. Click
      Add rule
      .
    4. Enter a rule name and configure the rule. Configuration options are discussed in the following sections.
    5. Click
      Save
      .
    6. View the impact of your rule. Go to
      Monitor > Vulnerabilities
       to view the scan reports.

    Severity-based actions

    Vulnerability rules let you specify trigger thresholds for alerting and blocking. Alert and block actions let you establish quality gates in the CD segment of your continuous integration (CI) continuous deployment (CD) pipeline.
    Alert and block thresholds can be set to different values. The block threshold, however, must always be equal or greater than the alert threshold.
    Setting the alert threshold to off allows all vulnerabilities for the resources in scope (as defined by your filters). Practically, resource nodes in Radar turn green (no issues to report), and scan reports are empty (no issues to report).
    When you create a blocking rule, Defender automatically installs itself as the final arbiter of all container lifecycle commands. This way, Defender can assess a Docker command, your current policy, and the status of an image before either forwarding the command to runC for execution, or blocking it all together.

    Scope

    Scope filters let you target specific resources in your environment. By default, filters are set to wildcards, which applies the rule globally. For more information about supported pattern matching syntax, see Rule ordering and pattern matching.

    Vendor fixes

    Rules can be applied conditionally depending on whether vendor fixes are available. For example, you could tune your policy to block the deployment of containers with a critical vulnerability *only if* the vulnerable package has an update that resolves the issue. Otherwise, the deployment would be allowed to proceed.
    Some vulnerabilities have a vendor status of "Will not fix". This status is applied when vendors don’t intend to resolve a vulnerability because it poses no signficant risk to your environment.

    Rule exceptions

    You can configure Prisma Cloud to:
    • Alert or block on specific CVEs or tags (deny).
    • Ignore specific CVEs or tags (allow).
    Under
    Advanced settings
    , create a list of vulnerabilities and tags, and specify how the scanner should handle them. Leaving the expiration date blank enforces the action until the CVE or tag is removed from the list. If you set an expiration date, and the current date is later than the expiration date, the scanner ignores the directive. The CVE or tag remains in the list even if its expired. It must be manually removed. Notice that for tag exceptions, in case of a conflict (a vulnerability with two tags or more that have different actions in the rule exceptions) there’s no guarantee what action will apply.

    Custom terminal output

    Prisma Cloud lets you create rules that block access to resources or block the deployment of vulnerable containers. For example, you might create a rule that blocks the deployment of any image that has critical severity vulnerabilities. By default, when you try to run a vulnerable image, Prisma Cloud returns a terse response:
    $ docker run -it ubuntu:14.04 sh
docker: Error response from daemon: [Prisma Cloud] Image operation blocked by policy: (sdf), has 44 vulnerabilities, [low:25 medium:19].
    To help the operator better understand how to handle a blocked action, you can enhance Prisma Cloud’s default response by:
    • Appending a custom message to the default message. For example, you could tell operators where to go to open a ticket.
    • Configuring Prisma Cloud to return an itemized list of compliance issues rather than just a summary. This way, the operator does not need to contact the security team to determine which issues are preventing deployment. They are explicitly listed in the response.
    When terminal output verbosity is set to
    Detailed
    , the response looks as follows:
    $ docker run -it ubuntu:14.04 sh
docker: Error response from daemon: [Prisma Cloud] Image operation blocked by policy: (sdf), has 44 vulnerabilities, [low:25 medium:19].
Image          ID       CVE             Package   Version             Severity   Status
=====          ==       ===             =======   =======             ========   ======
ubuntu:14.04   4333f1   CVE-2017-2518   sqlite3   3.8.2-1ubuntu2.1    medium     deferred
ubuntu:14.04   4333f1   CVE-2017-6512   perl      5.18.2-2ubuntu1.1   medium     needed
.
.
.

    Grace period

    Grace periods temporarily override the blocking action of a rule when new vulnerabilities are found. Grace periods give you time to address a vulnerability without compromising the availability of your app.
    When grace periods are configured, alerts trigger as normal, notifying you that the vulnerability exists in your environment. The block action is suppressed for the number of days specified, giving you time to mitigate the vulnerability.
    The start time for the grace period is the date the vulnerability report was published. The end time is the publish date plus the number of days configured for the grace period.

    Blocking based on vulnerability severity

    This example shows you how to create and test a rule that blocks the deployment of images with critical or high severity vulnerabilities.
    1. In Console, go to
      Defend > Vulnerabilities > Images
      .
    2. Click
      Add rule
      .
      1. Enter a rule name, such as
        my-rule
        .
      2. In the
        Severity based actions
         table, set both the
        Alert threshold
         and
        Block threshold
         to
        High
        .
      3. Target the rule to a very specific image. In the
        Images
         filter, delete the wildcard, and enter
        nginx*
        .
      4. Click
        Save
        .
    3. Validate your policy by pulling down the nginx image and running it.
      1. SSH to a host protected by Defender.
      2. Pull the nginx:1.14 image.
        $ docker pull nginx:1.14
      3. Run the nginx image.
        $ docker run -it nginx:1.14 /bin/sh
docker: Error response from daemon: oci runtime error: [Prisma Cloud] Image operation blocked by policy: my-rule, has 7 vulnerabilities, [high:7].
      4. Review the scan report for nginx:1.14. Go to
        Monitor > Vulnerabilities > Images
        , and click on the entry for nginx:1.14. You’ll see a number of high severity vulnerabilities.
        By default, Prisma Cloud optimizes resource usage by only scanning images with running containers. Therefore, you won’t see a scan report for ngninx until it’s run.
      5. Review the audit (alert) for the block action. Go to
        Monitor > Events
        , then click on
        Docker
        .

    Blocking specific CVEs

    This example shows you how to create and test a rule that blocks images with a specific CVE.
    1. In Console, go to
      Defend > Vulnerabilities > Images
      .
    2. Click
      Add rule
      .
      1. Enter a rule name, such as
        my-rule2
        .
      2. Click
        Advanced settings
        .
      3. In
        Exceptions
        , click
        Add Exception
        .
      4. In
        CVE
        , enter
        CVE-2018-8014
        .
        You can find specific CVE IDs in the image scan reports. Go to
        Monitor > Vulnerabilities > Images
        , select an image, then click
        Show details
         in each row.
      5. In
        Effect
        , select
        Block
        .
      6. Click
        Add
        .
      7. Click
        Save
        .
    3. Try running an image with the CVE that you’ve explicitly denied.
      $ docker run -it imiell/bad-dockerfile:latest /bin/sh
docker: Error response from daemon: oci runtime error: [Prisma Cloud] Image operation blocked by policy: my-rule2, has specific CVE CVE-2018-8014

    Ignoring specific CVEs

    Follow the same procedure as above, but set the action to
    Ignore
     instead of
    Block
    . This will allow any CVE ID that you’ve defined in the rule, and lets you run images containing those CVEs in your environment.

    Recommended For You

    Recommended Videos

    Recommended videos not found.

    © 2023 Palo Alto Networks, Inc. All rights reserved.

    Techdocs Logo