Part II, Conducting an Investigation Using PAN Logs with Investigator

Posted by Kyle Allen Banta Yoshida on June 24, 2019

In our last installation, “Diving into Palo Alto Networks logs using Insight Investigator, Part I”, we introduced the idea of using Palo Alto Networks sources and the Palo Alto Networks Firewall data model, in conjunction with Insight Investigator, in order to bring that log data to life. Now we will explore a few queries in more detail, such that we can perform an investigation into potential threats.

Let’s start out with a scenario. In the context that I am overseeing network security of my company’s assets, I would regularly check in on a number of health indicators. I wish to be proactive, and this is something that I will likely automate, once I see the value that I need to see from a predefined process. Here I will try to define that process.

Keep in mind that the Center for Internet Security talks about a prioritized set of best practices, focused on stopping the most dangerous threats. With our approach, and with the assistance of Insight Investigator, we can address many facets of this top-20 list of critical security controls. Among them are continuous vulnerability management, malware defense, and data protection. Let’s begin to address these concerns.

One important quantifiable health indicator is the existence of systems that I can confidently identify as having been infected: the presence of malware. Since we are a Palo Alto Networks shop, an immediate thought that comes to mind is, “how much of my network traffic through my PAN firewall involves infected computers?”

This leads me to type this into Insight Investigator: PAN traffic from infected systems.

This search leverages the sources which have been extracted and structured, within the Splunk CIM Malware data model, as well as the Palo Alto Networks Firewall Logs data model. In this environment, you can see that we have many data source types that feed into either / both of these data models. Among them are Cisco, McAfee, Palo Alto Networks, Sophos, and Symantec sources.

We are also presented with a wealth of visual data. Deep insights, within a matter of seconds. First of all, we see the total malware count. It is immediately apparent how much of this malware-related traffic is flowing through our PAN infrastructure. We are beginning to see how powerful it is to join multiple data models, so that we can understand where vulnerabilities exist.

We also know the top 20 endpoints, from which malware is being sent..

There are definitely visually striking elements here. To begin with, the “Top 20 Malware Destination Source IPs” shows a disproportionately huge count (317!) associated with the resource 192.168.0.3, which is ~117 more than the next-most-affected device.

Immediately, we might decide that this requires immediate attention. Should I open up an SSH connection to 192.168.0.3 right away? Should we isolate this resource from the network, with the expectation that any threat will be mitigated? After taking this action, can we breathe freely, knowing that our users and systems are secure?

Well. Not quite. Because Insight Investigator shows us more information. Here we can see the top 20 endpoints from which malware is being sent, by network traffic volume.

We see important information about this resource. But above the bar representing the volume of malware-specific traffic coming from 192.168.0.3, is a much, much, much larger bar. There is nearly 6x the amount of malware-specific traffic flowing from 192.168.0.2.

This huge volume of traffic tells us that it is much more pressing to focus our efforts here. More traffic attributed to known malware implies immediate activity, perhaps an actively spreading infection, something that has high potential to spread dangerously. Isolating 192.168.0.2 from our other systems ensures that the malware does not spread. It is at this point that we can attack the next-highest-severity concern in this scenario: the resource at 192.168.0.3.

Concurrently, it would be prudent to look beyond where we have identified issues. We should delve deeper, beyond the resources themselves, and discover just how those infections made their way into our network (and onto those systems). So here, we type “PAN traffic by user with malware” into Insight Investigator.

Again, as with the last question we asked, this one leverages sources which have been extracted and structured, within two (the CIM Malware and the Palo Alto Networks Firewall Logs) data models.

This time, not only can we see a count of malware, but more specifically we see how that count is associated with each named user. Since our question involved users, it also makes sense that we see the volume of traffic in-and-out, as associated with each user account.

Once again, Insight Investigator shows us very important information in an extremely visually-striking way. The user tng\crusher should be urgently flagged as suspicious, deactivated (removing any access that Ensign Wesley has to any systems), and a deeper dive into these credentials should commence.

The threat to our network is not going to spread, the immediate issue is addressed, and we just saved a ton of time by using the power of joining PAN firewall logs with other data models.

Sign up for the Security Insights Weekly Newsletter.