Prisma Cloud Compute Edition Administrator’s Guide
    : Troubleshoot Vulnerability Detection
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Vulnerability management
    6. Troubleshoot Vulnerability Detection
    Download PDF

    Prisma Cloud Compute Edition Administrator’s Guide

    Troubleshoot Vulnerability Detection

    Table of Contents

    Troubleshoot Vulnerability Detection

    Prisma Cloud offers a comprehensive Intelligence Stream for vulnerability management that draws on threat intelligence from commercial providers, and the open-source community, as well as distinctive vulnerability intelligence curated by Prisma Cloud vulnerability researchers.
    Use this troubleshooting section to verify the accuracy of Prisma Cloud scan results, understand the logic behind scan reports, and provide the details requested in the template when you submit a support request for further analysis.
    This section answers some common questions related to CVE scan reports:
    1. Whether a CVE reported by Prisma Cloud is suspected to be a false positive (meaning there is an assumption that the CVE doesn’t exist on a package/image, but it displays on the Prisma Cloud Console)
    2. Whether a CVE in Prisma Cloud is suspected to be a false negative (meaning there is an assumption that a CVE does exist on package/image, but it does not display on Prisma Cloud Console)

    Prerequisites

    1. Ensure you are running the latest version of Prisma Cloud Compute Console.
    2. Ensure you are running a supported version of Prisma Cloud Compute Defenders. Prisma Cloud Defender version is backward compatible for up to two major releases of Console.
    3. Ensure that the image or OS is supported.
      1. If the problem is in a container, ensure that the image is based on a supported OS.
      2. If the problem is in a host, ensure it is running a supported OS.
    4. The connection to Intelligence Stream is up-to-date.
      1. Navigate to
        Manage > System > Intelligence
        .
      2. Verify that the
        status
         is
        Connected
        .

    Troubleshooting Steps

    After you complete the prerequisite checks, continue to troubleshoot further. The commands below are for Linux distributions but you can use the same process for Windows distributions.

    Step 1: Running the Image in a Container

    Whether troubleshooting for a false positive or a false negative scenario, the image should be searched for signs of the given package or file that has been associated with the CVE. Running the image in a container is a good way to proceed. As a best security practice, always run these experiments in a sandbox environment instead of production.
    Download the image or load it from tar archive on a host protected by a container Defender environment:
    docker pull <imagename> OR docker load -i <image.tar>
    Instantiate a container from the image:
    docker run --rm --detach --name vuln_testing <imagename>
    If the image exits immediately, the entrypoint or CMD associated with it most likely doesn’t spawn a long-running process. In this case, append the docker run command with sleep infinity command to run the container indefinitely.
    $ docker run --rm --detach --name vuln_testing <imagename> sleep infinity

    Step 2: Investigate the Container

    Get the ID of the running container then exec into the running container:
    $ docker ps | grep vuln_testing
$ docker exec -ti <containerID> /bin/bash
    If the bash shell isn’t installed in the image, try alternate shells such as, /bin/sh or /bin/zsh.

    Step 3: Find the Linux Distribution of the Image

    Match the detected OS type in the Console against the listed OS inside the running container to ensure that it was correctly identified.
    $ cat /etc/os-release
    If the os-release file is not found, look for /etc/redhat-release, /etc/lsb-release, or other files matching /etc/*-release.

    Step 4: Locate the Package associated with the CVE

    Locate the package or file that is associated with the CVE that was listed, or that was not detected despite the expectations. Additionally, confirm the version of the package detected inside the container with the one shown in Prisma Cloud Console or, in case of a false negative, which is shown in the other source confirming the CVE.
    Use the find command to look for the package in the filesystem:
    $ find / -name <package_name>
    Example:
    abc@3f61f8497e23:/# find / -name console
/dev/console
/sys/devices/virtual/tty/console
/sys/class/tty/console
    Run the package binary with --version tag if available. You can also search for the version in Console. Go to
    Monitor > Vulnerabilities
    , then click on an image, and select the
    Package Info
     tab.
    Example:
    abc@3f61f8497e23:/# /usr/bin/wget --version
GNU Wget 1.20.3 built on linux-gnu.
    Some other ways to find the package, depending on the type of package are -
    Package Type
    Command
    jar
    find / -iname '*.jar' | grep <jar_name>
    Get the version from the jar name.
    Example output:
    /opt/amq/webapps/hawtio/WEB-INF/lib/httpcore-4.4.4.jar
    Npm/node packages
    npm list | grep -i <package_name>
    sh-4.2$ cd <path>
sh-4.2$ cat package.json | grep -i version
    If investigating false positives, find the package path from image details in Console. Select
    Monitor > Vulnerabilities > Images
    , click on the image, and select the
    Package Info
     tab.
    OS
    For OS packages, use the OS package manager to find the installed package and version.
    For example, you can use the following for RHEL/CentOS/SUSE packages (here searching for the curl package):
    Another example for Debian/Ubuntu:
    python
    For python packages, you can run the following command in the package path (if already known)
    $ cat __init__.py | grep -i __version__
    (OR) in the .dist-info directory.
    $ cat METADATA | grep -i version

    Analyzing Results

    The above steps should help answer whether the vulnerable package exists in the image or not, and answer if a CVE is truly a false positive. If you found the package and the vulnerable version in the image but have questions about the report’s accuracy, you can search the vendor’s official feeds to confirm the source of the CVE report.

    1. "I found the package, but I’m not sure if it’s truly vulnerable."

    Navigate to
    Monitor > Vulnerabilities > CVE Viewer
    , type the CVE ID, and verify the source matching OS of your image, or look for the reference with empty
    Distro
     and
    Release
     if it’s a specific language library.
    You can then directly search vendor feeds to confirm CVE’s authenticity. For OS packages, the relevant vendor site should be consulted. For specific language libraries, the site of that project should be visited. The National Vulnerability Database (NVD) should be used for locating CVE information that is not available on official vendor feeds.
    Vendor vulnerability data may differ between feeds and NVD analysis. For example, in severity, description, or affected versions. Prisma Cloud gives more weight to specific vendor analysis to provide accurate vulnerability data.
    Example 1: A vulnerability was determined to be high severity per NVD analysis, but Red Hat Linux analysis determined the vulnerability to be of high severity on RHEL releases. Prisma Cloud should display high severity in this case.
    Example 2: A vulnerability was discovered in an open-source package and was fixed in the latest release. NVD analysis mentioned the vulnerability affects all releases earlier than the latest release. At the same time, the vulnerability could be fixed on earlier releases on RHEL, with maintainers having backported the patch to earlier releases of the package for RHEL.

    2. "I found the vulnerable package, but Prisma Cloud doesn’t show it’s CVE."

    When looking into a false negative, it is important to confirm the type of the vulnerability (that is anticipated to be "missing" from scan results), where type equals one of the supported formats that Compute currently detects when interrogating an image.
    Supported types:
    • package - an OS package, such as an RPM (Red Hat and derived distributions), dpkg/deb (Debian and derived distributions), or apk (Alpine Linux).
    • jar - the Java Archive format, which is a zip file with a standard structure. The war file format, or web app archive, is also supported.
    • python - a Python library, sometimes consisting of zip archives with varying structures and names (eggs, wheels) or plain text files on disk with supporting metadata text files.
    • nodejs - a NodeJS library, primarily consisting of text files on disk with supporting metadata text files.
    • gem - a Ruby library, consisting of text files on disk with supporting metadata text files.
    • go - a Golang binary, which typically contains dependencies that are statically compiled into it. Where most C programs make use of dynamically linked libraries/shared-objects that are present on the host and pulled in at runtime, Golang binaries usually have their dependencies embedded within them at compile time.
    • app - a binary associated with a well-known application, such as Nginx or PostgreSQL.
    If it is one of the above supported types yet missing in Prisma Cloud Compute’s scan report, verify that the package in question is not installed through an OS package. If a detected Third-party package is sourced from an OS package, and the CVE exists on the official feed of the OS distribution - only the CVE information for the OS package will be shown. For example, if there is a "python" application that was installed through the "python-2.7.5-92.el7_9" rpm package for RHEL7, and CVE-XXX-XXX exists in RHEL feed, the scan will not mark the CVE as vulnerable to the "python" application. Only the relevant information from the official feed will be reflected for the "python-2.7.5-92.el7_9" rpm.
    You can check if a third-party package is sourced in an OS package by running the following with the path where the package is installed:
    If none of the above resolved the issue, then open a support case and provide the following information, so our teams can investigate further.

    Submit a Support Request

    When submitting a technical support request with Palo Alto Networks, provide the following information to help our teams identify the root cause quickly. This information is required to review escalations.
    1. Debug logs: Provide full debug logs through
      Manage > System > View Logs > Upload/Download Debug logs
      . You can also use twistcli to upload logs:
      $ ./linux/twistcli support upload --help
      1. The debug log option is only available on self-hosted Consoles. In the event that you have a SaaS Console, gather the console.log (from
        Manage > System > View Logs
        ) and the defender.log (under /var/lib/twistlock/log directory on host) from the host where the image was first scanned.
    2. Image details
      : If the issue is in a container image, provide the affected container image (image.tar). You may also check if the image can be downloaded from Docker Hub and share a link to pull the image. Always validate the Image ID SHA to ensure it’s the same image. If you are unable to share the image, please provide an image where the issue reproduces that we can analyze.
    3. Scan discrepancy report sheet
      : Ensure you have a spreadsheet with the following columns info filled out from your prior analysis.
      CVE ID
      Package Type
      Package Name
      Package Version
      Path where package is found in image
      CVE Reported in Console? Yes/No
      CVE Reported by any other vendor/source?
      Your explanation/comments
      Example: CVE-2021-38297
      OS
      gnutls28
      3.6.7-4+deb10u5
      /usr/bin/gnutls
      Yes. Suspect it to be a false positive
      I don’t believe this CVE should be reported for this version of package because I don’t see version in NVD.

    Frequently Asked Questions

    I see a CVE in the scan, but it does not appear on NVD or is still under analysis. What is the information I’m seeing?

    When a CVE is assigned to a vulnerability, usually NVD analysis takes place, and it may take multiple days for the NVD site to update with a description and the affected release range. Instead of waiting for the official analysis to complete, our researchers manually review the details of the CVE and add it as a pre-filled CVE to our Intelligence Stream, so you can know you are vulnerable and mitigate the vulnerability before the official analysis is done. See the Prisma Cloud vulnerability feed page for more information.

    What are PRISMA-* Vulnerabilities?

    Our researchers assign a PRISMA-* identifier for vulnerabilities that lack a CVE ID. Many vulnerabilities are publicly discussed or patched without a CVE ever being assigned to them. Our researchers find those vulnerabilities, analyze them and assign a PRISMA ID whenever applicable, so you can know what you need to be aware of. See the Prisma Cloud vulnerability feed page for more information.

    I see CVEs with the Fix status "affected". What are these? Are they false positives?

    CVEs with the status "affected" are CVEs that don’t have a fix yet, and the vendor marked them as affecting the current OS release. Some other vulnerability scanners don’t show them, but these are not false positives. You can also decide to hide the vulnerabilities with no fix under
    Defend > Vulnerabilities
    , edit a vulnerability policy and enable
    Apply rule only when vendor fixes are available
    .

    I see a lot of low-severity CVEs. What are these? Are they false positives?

    You can decide if you want to see vulnerabilities that have negligible severity or "will not fix" status. These CVEs have already been reviewed by the vendor and are not going to be fixed. Although they are not truly false positives, Prisma Cloud Compute doesn’t show these CVEs by default, since the vendor decided a fix is not necessary. You can change this configuration under
    Manage > System > Scan > Unactionable vulnerabilities
    .

    Where do you take CVE information such as severity and fixed version from?

    For known vulnerabilities with a CVE, we rely on the most authoritative source - for OS packages (packages that are maintained by the OS vendor, marked as type "package" in Compute), the CVE details are taken from the specific vendor feed. For other CVEs, the information is taken from official sources like NVD and vendor-specific Security Advisories. For new vulnerabilities missing analysis or undocumented vulnerabilities (such as PRISMA-IDs), we rely on severity determined by our researchers.

    Do all CVEs reported by Prisma Cloud rely on information from NVD?

    The National Vulnerability Database (NVD) is one of the major sources on which the Intelligence Stream relies for accurate CVE information. In addition to using NVD and other vendor sources, Prisma Cloud security researchers analyze vulnerabilities on a daily basis. In case we find any discrepancies between our analysis to that of NVD or any other vendor, we partner with them to correct any missing or inaccurate information. We strive to contribute to the security of the open-source community.

    I see on the Red Hat security page that a CVE affects my OS release, but it doesn’t show up in Prisma Cloud scan. What happened?

    Our Intelligence Stream is drawing CVE information from Red Hat API - using OVAL v2 streams. While the HTML CVE page is already updated, there could be a delay in the API update.

    Why does Prisma Cloud show more vulnerabilities than what I see in the Red Hat catalog?

    The Red Hat Container Health Index analysis is based on RPM packages signed and created by Red Hat, and does not grade other software that may be included in a container image. Thus, non-OS vulnerabilities like jar, python, and others will not be listed on Red Hat Catalog. Furthermore, the Red Hat catalog only shows CVEs that have a fix, meaning there is a security advisory with the fix. "Affected" CVEs (see above) don’t have a fix, and they won’t appear in the Red Hat catalog.

    What is the "Published Date" in Console?

    The published date is the date that the CVE was published by the vendor/project or by NVD. This information is taken from the relevant feed - either the vendor feed or NVD. Please note that the date a CVE is published in NVD is not the date it was analyzed. The CVE can be published in NVD and only later updated with the analysis.

    What is the "Fix Date" in Console?

    The fix date is the date the vulnerability data was fixed by the vendor. When we can’t find the relevant fix date in the official feeds, the published date in NVD is considered as the fix date.

    A new vulnerability is affecting Compute - what should I do?

    If the vulnerability affects Compute that has not yet been addressed, please report it through support channels or to PSIRT.

    A CVE exists in NVD, but I don’t see it in the CVE viewer, what should I do?

    If you believe a CVE that was fully analyzed by NVD is missing from our feeds, please report it through the support channels.

    Recommended For You

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