While there is no out-of-the-box connector to pull Prisma cloud resource policy alerts into Cisco Vulnerability Management natively, the Data Importer allows you to ingest the data into Cisco Vulnerability Management. To accomplish this, Cisco Vulnerability Management exports a .csv file from Prisma then runs the Cisco Vulnerability Management csv-to-json conversion script and uploads the results .json file into the Data Importer 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 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. Refer to this link for more details on the differentiation between all of these products. Cisco Vulnerability Management’s Prisma connector currently only imports 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 Data Importer script below, resources from Prisma are listed in Cisco Vulnerability Management by their Resource Name as defined in Prisma/AWS. That Resource Name 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 Data Importer 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 through tags. The Cloud Region tag identifies the shared cloud region the resource resides in (such as AWS Northeast), the Prisma Policy Label identifies the policy type (such as PCI-DDS, and Network), 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”.
To normalize vulnerability and asset scoring across all other Cisco Vulnerability Management data points, Prisma policy criticality is mapped to Cisco Vulnerability Management scores in the following way:
-
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.
Finally, 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 Data Importer 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 because 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 want to import resolved alerts into Cisco Vulnerability Management for historical reporting purposes.
Comments
Please sign in to leave a comment.