“What could you have done better as an organization to adjust to Log4J?”
This question has resonated with the cybersecurity community for a while now. Within the capabilities of the Prisma Cloud product here at Palo Alto Networks, there are a number of threat landscape views and preventative tools that are available to customers.
In this article, we will review some of the core features that security professionals can utilize to be notified of CVE detection, available API calls within the Prisma Compute console that will help to give a quick view into resources affected by Log4J through the correlated CVE, as well as some advanced preventatives, such as creating a custom CVE or uploading an MD5 malware hash, that are available to users of the console. With these additional tools there will be a better understanding of not only how to get a grasp around aspects of the threat landscape of Log4J in your environment, but also a better way to approach potential future zero-days through utilization of the capabilities of Prisma Cloud.
As is usually the case, the primary tool to be able to handle a new zero-day is being proactive. This could be a runbook, some kind of cloud resource hygiene through scope labeling with established criteria of what resource belongs to what team in which environment, a subscription to a threat intelligence feed that is actively monitored by a person on your security team, or anything that you can imagine to implement to be ahead of the curve in your environment. 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 be good at defending these types of systems, there is a need to be proactive and, hopefully to some extent, innovative.
To begin to be proactive, 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 Compute, there are several ways that these communication notifications can be set up, so that you can 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 Compute, 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
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
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 on through associating the tag with a vulnerability rule. To do this, navigate to the “Defend” menu of the compute 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 correlates 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 in this screenshot:
Figure 3: Scoping CI Vulnerability Rule
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
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 Compute 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
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
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 Compute 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 in this screenshot:
Figure 7: Alert Notification Profile Provider Configuration
After this is 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
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 need as a customer and where the information from the console can be consumed internally that will be explored in a future article.
Figure 9: Setting Email(s) To Notify
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
You can then check the email address, or list of addresses, for an email that will look like the one below.
Figure 10: Sending Test Email
After you have confirmation that this test email is received, you can save the alert profile.
In conclusion, you now set up and created an email integration that is scoped to the tag associated with Log4J to be able to send alerts when that CVE is detected within the specified collections of the deployed images vulnerability rule. You also set up an additional rule that can fail builds in your continuous integration environments that are onboarded into the console based on the same detection scope. Because you set this up with a tag, you can potentially go back and test different packages encompassed by the CVE within the types of environments that you have scoped to the rule. With this knowledge, you now have a template to set this up for any CVE in the Prisma Cloud intelligence stream to be able to, if necessary, have a granular look at the different packages included. You now also have a streamlined approach to getting notifications of detections of Log4J in your cloud environment. We hope that with this tool you will be able to rest assured that your environment is better protected.
About the Author:
Avery King is a cloud security professional specializing in terraform, coding, CSP technologies, and Kubernetes. Avery is a polyglot, threat researcher, coder, avid reader, music lover, chess player, and number theorist. Avery uses a collaborative approach to break down complex problems into solutions for global enterprise customers and leverages his multi industry knowledge to inspire success. Avery loves to work to help you be the best that you can be at learning new technology.
