Importing Prisma Alerts into Cisco Vulnerability Management via the KDI Connector

While there is no out-of-the-box connector to pull Prisma cloud resource policy alerts into Cisco Vulnerability Management natively, the Kenna Data Importer allows us to ingest the data into Cisco Vulnerability Management. We accomplish this by exporting a .csv file from Prisma then running the Cisco Vulnerability Management csv-to-json conversion script and uploading the results .json file into the Kenna KDI connector. A crafted metadata file to map Prisma fields to the corresponding Cisco Vulnerability Management fields has been attached below.

Note: Prisma cloud-native alerts are unrelated to container/image/etc. vulnerability data which can also be provided by Prisma in “Prisma Compute” or “Prisma Enterprise”, formerly known as Twistlock. Prisma cloud resource policy alerts are provided by a SaaS solution that is formerly known as Redlock. Please check this link for more details on the differentiation between all of these products. Cisco Vulnerability Management’s Prisma connector currently only pulls in vulnerability data from containers and images, not any policy alerts from cloud-native resources such as S3 buckets or security groups.

Prisma to Cisco Vulnerability Management Asset Details Mapping

When using the KDI script below, resources from Prisma are listed in Cisco Vulnerability Management by their Resource Name as defined in Prisma/AWS. This is mapped to the host name field in Cisco Vulnerability Management. The Resource ID is mapped to the external ID in Cisco Vulnerability Management to ensure that resources are not duplicated. This external ID serves as the locator for each resource and should be set as the primary locator for this KDI connector.

The Cloud Account Name is mapped to the “Owner” field in Cisco Vulnerability Management for quick identification and querying.

Additional asset details are available via tags. The Cloud Region tag identifies the shared cloud region the resource resides in (e.g. AWS Northeast), the Prisma Policy Label identifies the policy type (e.g. PCI-DDS, Network, etc.), the Cloud Type tag identifies the shared cloud provider, and the Cloud Account ID identifies the AWS or other cloud account ID.

Prisma Policy Alert to Cisco Vulnerability Management Vulnerability Mapping

Policy violations are reported in Prisma as alerts and given a criticality of High, Medium, or Low.

The provided metadata file maps these alerts into Cisco Vulnerability Management as vulnerabilities. The “scanner_id” field corresponds to the Alert ID in Prisma. This is the unique identifier for each separate policy such as “AWS access keys not used for more than 90 days” or “AWS S3 buckets do not have server side encryption”.

In order to normalize vulnerability and asset scoring across all other Kenna data points, Prisma policy criticality is mapped to Kenna scores as such:

• High = 10

• Medium = 8

• Low = 6

The vulnerability name in Cisco Vulnerability Management is mapped to the Policy Name in Prisma, and the Recommendation field in Prisma is mapped to the solution field in Cisco Vulnerability Management. The same Description field is used in both Cisco Vulnerability Management and Prisma.

Lastly, the Alert Time field in Prisma is mapped to the “Last Seen” field in Cisco Vulnerability Management.

Usability Tips and Risk Meter Examples

The resource data being imported through the KDI script pairs well with hierarchical risk meters (HRM) in Cisco Vulnerability Management. Here is an example of a possible HRM tree:

• All cloud assets - (tag:"Cloud Type*")

  • AWS assets - (tag:”Cloud Type:aws”)

    • AWS Virginia assets – (tag:”Cloud Region:AWS Virginia”)

  • GCP assets - (tag:”Cloud Type:gcp”)

    • Corporate Website Cloud Resources – (owner:”Corporate Website”)

  • Azure assets - (tag:”Cloud Type:azure”)

    • Unauthorized Access Attempts in Azure – (tag:”Prisma Policy Label:*Unauthorized Access*”)

Known Issues

• Time zone is not included in the dates generated by the script due to Prisma outputting the date and time in a non-standard format.

• Policy labels are not comma delineated into separate tags. This means that if a specific policy matches three different policy types it will receive a single Cisco Vulnerability Management tag that includes all three types as opposed to three separate tags. This was intentionally done to reduce tag bloat, advanced search syntax can be leveraged to target specific policy labels in a single tag.

• Policy type is not imported due to redundancy as policy label is more descriptive.

• The attached metadata file is not configured to import alerts in any state other than “open”. You can modify the metadata file to map the other statuses if you care to import resolved alerts into Cisco Vulnerability Management for historical reporting purposes.