The Prisma Cloud product from Palo Alto Networks has a number of threat landscape views along with preventative tools to help mitigate the risks of a vulnerability, including zero-day vulnerabilities.
We will examine how Prisma Cloud can notify you of a CVE, what API calls can be used to find the resources affected by a CVE, and how to create a custom CVE to support zero-day vulnerabilities. This article will demonstrate how you as a security professional can get a better understanding around the threat landscape of your environment. For purposes of example, we will use Log4J as our zero-day threat in this article.
The best way to handle any new vulnerability is to be proactive instead of reactive. This could be through the use of a runbook, cloud resource hygiene through scope labeling to know which resources belong to which team, a subscription to a threat intelligence feed that is actively monitored, or anything else that your organization may implement to be proactive. As long as there are threat actors to infiltrate computing systems, there will always be a need to defend against these threat actors. However, this also means that to efficiently defend these types of systems, there is a need to be proactive and, to some extent, innovative.
To start, you need to have knowledge as to what your current computing environment looks like and a way that any changes to that relative baseline can be communicated to you or your security team. In Prisma Cloud Workload Protection, there are several ways that these communication notifications can be set up to enable you to have thresholds of reporting from an incident response team to executive leadership. Within the context of Log4J, allow us to take a look at setting up a way to identify the scope of CVE detection through tagging and correlating that tag to a vulnerability rule that notifies an alert profile.
As in any problem solving use case, it is important to set the scope of work. In Prisma Cloud CWPP, there is a “Manage” menu, with a section dedicated to “Collections and Tags.” Once you have navigated to this view, click on the “Tags” tab on the top left, to be taken to the view that will help us in setting the scope of how to detect a package, the potential individual packages to detect encompassed by a CVE, the types of resources to detect the package(s) in, and the CVE correlated to the package(s).
In order to set this tag scope, the first step is to create a tag definition to be populated. Once you click the “Tag Definition” drop-down menu and select the “Add Tag” button, you can populate the tag name as has been done in this screenshot:
Figure 1: Create new tag_palo-alto-networks
Once this tag is defined, you can navigate to the tag assignment section and assign the scope of what the tag will define:
Figure 2: Create new assignment_palo-alto-networks
As you can see from these menus there is the capability to get granular in the package scope to the software packages corresponding to this CVE, in the threat intelligence stream, as well as the resource scope of where to check for the chosen package set. To have this be as comprehensive as possible you can select “All packages” and “All resources for the scope”.
Next let’s create the link between the scope of what to detect and the resource that we want to scan to detect the CVE through associating the tag with a vulnerability rule. To do this, navigate to the “Defend” menu of the CWPP console and click the “Vulnerabilities” section. Within this section there will be tabs that correspond to different types of cloud resources. We will create two rules in the “Images” resource type under the “CI” and “Deployed” tabs, which correlate to scanning continuous integration build pipelines and deployed image environments that have been onboarded into the console.
In the “Images” tab under the secondary “CI” tab, click on the “Add Rule” button.
This will bring up a dialog box where we can define the scope of the vulnerability rule through associated collections, as well as the configuration option we will need in the “Advanced Settings” section to create the link to the Log4J tag. It is important to note that this assumes that your collections are already where you need them to be in your environment for scoping cloud resources. It is also important to note that the “Alert Threshold” and “Block Threshold” toggles of the “Severity based actions” section should be set to off, as you can see below:
Figure 3: Scoping CI Vulnerability Rule_palo-alto-networks
To create the link to the Log4J tag within the “Advanced Settings” portion of the vulnerability rule, click on the “Advanced Settings” link to populate this within the dialog box and then click the “Add Exception” button. After selecting the “Tag” option instead of the “CVE” option, you can select the tag name of the Log4J tag from the menu. Even though you can set up this rule through the CVE, it is better to utilize the tag scoping functionality to be able to look at individual packages encompassed by a CVE, instead of every package due to the types of environments that you are scanning. Once the tag is added as an exception, you should be looking at something similar to this:
Figure 4: Correlating Tag to New CI Rule_palo-alto-networks
If you wanted to fail a CI build based on the detection of what is encompassed by the Log4J tag you could select the “Fail” effect, but for this article, we are going to keep the effect as being “Alert.” Based on the current capabilities of alert notification profiles, this rule will not be able to correspond to an alert but this configuration will show you how to potentially fail builds in a continuous integration pipeline based on detected CVEs or granularly tagged packages within a CVE.
To scan deployed images, we can configure a similar vulnerability rule within the “Deployed” tab of the images resource type. After navigating to this tab, within the same menu of the CWPP console, select the “Add Rule” button. In the same way that the CI rule was originally set up, the “Alert threshold” and “Block threshold” should be toggled off in order to ensure that the detection scope of the rule is only set to the correlated tag, as can be seen below. One thing to note here is that in your collections selection, you can specify the collections in your environment that have been set up to include resources that have images deployed with potential software configurations that would include Log4J.
Figure 5: Creating New Deployed Images Vulnerability Rule_palo-alto-networks
Also in the same way that the tag was added as an exception in the previous rule, the same configuration needs to be made in this rule to set the proper scope.
Figure 6: Correlating Tag to Deployed Images Vulnerability Rule_palo-alto-networks
Next, let’s set up the alert notification profile. To make this relatively easy, we are going to send this alert to an email address from the Prisma Cloud console, but depending on if you have prior alert profiles set up, you can integrate at least a portion of this process to notify the existing alert profiles.
Within the Prisma Cloud CWPP console, you can navigate to the “Manage” section and select the “Alerts” link. In the “Manage” tab of this view, you can create a new alert profile by clicking on the “Add Profile” button on the right. To configure the initial screen options, you can name the profile and then select the provider as “Prisma Cloud” and the integration as “Email” as can be seen below:
Figure 7: Alert Notification Profile Provider Configuration_palo-alto-networks
After you have configured, you can then correlate the vulnerability rule that was created in the previous step to this alert profile through paralleling the setup of the next view in the dialog:
Figure 8: Alert Notification Profile Scoping_palo-alto-networks
Since the email notification is configured to be sent with Prisma Cloud as the “Provider” via an email integration, the only portion of the settings within this alert profile that we will need to set up is a static list of email addresses. This can also just be one email address to be able to test the alert. There are many options to potentially configure within an alert profile depending on your needs and where the information from the console can be consumed internally.
Figure 9: Setting Email(s) To Notify_palo-alto-networks
Finally, in the summary of the profile, there is an option to send a test email to make sure the specifications will work as intended. Once selecting this option, a green confirmation message will appear.
Figure 10: Sending Test Email_palo-alto-networks
You can then check the email address, or list of addresses, for an email that will look like the one below.
Figure 11: Sending Test Email_palo-alto-networks
After you have confirmation that this test email is received, you can save the alert profile.
You can now set up and create an email integration that is scoped to the tag associated with a vulnerability, such as Log4J, to be able to send alerts when that CVE is detected within the specified collections of the deployed images vulnerability rule.
Additionally, you can create a rule that will fail builds in your continuous integration environments based on the same detection scope. By setting this up with a tag, you can also test different packages encompassed by the CVE within the types of environments that you have scoped to the rule.
You now have a template to set this procedure for any CVE in the Prisma Cloud intelligence stream to have a granular look at the different packages impacted, along with a streamlined approach to getting notifications of detections of a CVE in your cloud environment.
You are now on your way to be better protected.
Paul Burega is a CSE Team Lead. Paul utilizes collaborative approach to break down complex problems into solutions for global enterprise customers and leverage his multi-industry knowledge to inspire success.
