Instrumenting Palo Alto Next-Generation Firewalls with Verodin SIP

High-performance security solutions like Next-Generation Firewalls from Palo Alto Networks offer tremendous security potential. To maximize their security effectiveness, the dollars invested, and the resources applied toward mitigating risk, security solutions across endpoint, network, email, and cloud need to be instrumented.

Security instrumentation solutions, such as those offered by Verodin, via the Verodin Security Instrumentation Platform or SIP, provide you with the ability to measure, manage, and improve security effectiveness.

This is accomplished by providing you with a platform to automatically and continuously execute real attacks, safely, within your production environment. In doing so, Verodin helps you determine what’s working, what’s not, and most importantly, helps you instrument your security controls to maximize their security effectiveness. Learn more about how Verodin SIP works here.

This piece will focus on leveraging the Verodin SIP to instrument PAN Next-Generation Firewalls.

Pictured below is the Verodin SIP Director. The Director provides you with a with an ever-growing list of attacks supplied by Verodin with an open content architecture that enables you to chain attacks together to build sequences and pull attacks in from threat intelligence, ISACs, 3rd party PCAP repositories, your local packet captures and many other locations. We actually have an entire blog dedicated to pulling your own PCAPs into Verodin titled, Weaponizing PCAPs for Security Assessments.

As illustrated, an attack behavior is selected on the left. On the right, there is a description of the attack with recommendations on how to execute the attack. You’ll also note the ability to see the PCAP for the attack, we’ll talk more about PCAP viewing later. Finally, there are the Common Detection Alerts. For this attack, there is an Emerging Threats alerts and Palo Alto alert. This prescriptive alerts greatly help in tuning your devices and we’ll cover it in detail later on.

In a nutshell, this is how the process works:

  1. You run attacks with Verodin SIP to validate if the attacks are blocked, detected, logged, and correlated
  2. If you do not see the expected results, you instrument your controls, possibly tuning your systems based on the Verodin prescriptive common detection alerts
  3. You repeat the attacks to validate that your tuning worked correctly
  4. Once working as you want, you automatically and continuously validate your security controls to ensure that defensive regression hasn’t made something that was working stop working, for example, if something that was blocking, alerting or correlating is no longer working as desired, you will be alerted by the Director so that it can be reinstrumented

Now that you have a high-level understanding of how these attacks can be used to validate and instrument your security controls, let’s build out a specific PAN validation sequence.

Note in the below illustration that we’ve filtered our attacks to a specific type, in this case, Bartalex. We can see that there are several Bartalex options. Let’s start with a Bartalex Malware Download and add that attack to our sequence queue. We’re doing this, so we can chain multiple attacks together. Building a sequence of attacks is a more realistic representation of how attacks happen in real-world situations.

The Bartalex Malware Download attack leverages another part of the Verodin SIP architecture called Actors. Actors are controlled by the Director. Actors attack each other. They don’t attack your servers, applications, security controls, etc.

In fact, Actors are only capable of attacking each other and in doing so, they measure the effectiveness of your security controls. When Actors attack each other, you can see what security controls block and or detect the attack. The Director also has integrations with your defensive stack such as your PAN firewall manager, SIEM manager, endpoint security manager, etc.

So, not only is it known, with zero false positives, if the attack was successful (because Actors are attacking other Actors thus you know through the Verodin Director’s results if it was successful or not) but it’s also known if management consoles logged the attack and if that log made it to a SIEM giving you full visibility into how your security controls respond in terms of prevention, detection, and correlation when under this specific attack.

Thus far, we’ve only added one attack to our attack sequence queue. Let’s add a few more and make this a real sequence. In the illustration below, note that command and control activity is the second item added to the queue. First, Bartalex compromised a system and now the C2 activity is initiated. Again, this all happens between Actors.

Note: one of the prescriptive common detection alerts below that’s boxed in red is a Palo Alto message “Bartalex Word Macro Detection.” Please note this as it will become important later.

In the next image, we add Vawtrak to the queue. Bartalex malware is installed, C2 activity occurs and it downloads Vawtrak.

In the fourth and final attack added to our attack sequence queue below, like the Bartalex C2, we’ve added C2 for Vawtrak.

In the above image note the PCAP. PCAPs are made available for most attacks so that you can inspect the PCAP as seen below. Note that the attacks are real. They aren’t a close comparison, something that kind of, sort of, looks like the real attack. They are the real attacks and they are safely launched between Actors. Being able to view the PCAP ensures that you know exactly what is going across the network regardless of it being supplied by Verodin or imported by you.

Now we go into the actual attack sequence we’ve created below. Here we can name it, add a description, order the attack launch sequence, add optional variables like sleep. This is where we can also save it for future use.

In the image below, we’ve used the Verodin Director to assign Actors for this particular attack sequence. The attack starts with an Actor in the Desktop Zone. For example, this might be a user that downloaded Bartalex in a Word or Excel file containing the malware.

The Desktop Zone Actor communicates with the Internet Zone Actor. The Internet Zone Actor is an Actor acting as a “bad guy” somewhere on the Internet. From a deployment perspective, your Verodin Internet Actor usually lives somewhere outside of your core network. It might be in an Amazon or Microsoft Cloud, in a separate datacenter, in the Verodin Cloud, etc.

As we can see below, when the Desktop and Internet Actors communicate with malicious attack behavior going between them there is a chance for Snort to detect and for PAN Firewalls to detect and even block the attack. Both Snort and PAN have the ability to also log to an integrated SIEM or log manager like Splunk.

Now that we’ve built our attack sequence and we’ve assigned the Actors to be part of that sequence, it’s time to launch the attack to validate the security controls. As pictured below, all four sections of our attack have completed. The results of the attack sequence are as follows:

  • Bartalex Malware Download
  • Unsuccessfully Blocked, Successfully Detected
  • Command & Control – Bartalex, Instruction Retrieval
  • Successfully Blocked, Successfully Detected
  • Malicious File Transfer – Vawtrak, Download
  • Successfully Blocked, Successfully Detected
  • Command & Control – Vawtrak, Instruction Retrieval
  • Unsuccessfully Blocked, Successfully Detected

In the image below, let’s drill into the “Bartalex Malware Download.” In this example, the Verodin Director has integrated with two defensive stack systems. The PAN firewall management console and Splunk.

As we can see, PAN picked up the attacks between the Actors. And, PAN and Snort successfully logged the attacks to Splunk. In this particular instance, the policy that was set on PAN was configured to simply alert and not block.

Being able to validate what’s actually blocking vs. what’s simply being detected is a powerful capability for any security control. Also, now we know exactly what needs to be done to block this particular attack in the future. We can adjust the PAN policy to block. Then we can revalidate the PAN firewall to ensure that the adjustments were successful. Then we can set Verodin SIP to automatically and continuously validate the PAN firewall over time – once an hour, once a day, twice a week, etc., in order to combat defensive regression.

Let’s take a look at the “Command & Control – Bartalex, Instruction Retrieval” section of the sequence pictured below. For this portion of the validation, we see that the C2 activity was blocked and created events.

Drilling into this portion of the sequence we see the following details below.

We see that the Bartalex C2 network behaviors triggered alerts in the PAN firewall manager and within Splunk.

Note that for PAN and Splunk we see the prescriptive common detection alert for Palo Alto “Bartalex Word Macro Detection” that I mentioned earlier and said to take note of.  This is a fantastic validation that the attack which was run, triggered using the exact prescriptive common detection alert from Verodin. This prescriptive information can be used to tune for improved prevention, detection, and correlation.

In short, Bartalex C2 alerts look like this on your network, based on your security controls and your configurations. If you want to prevent, detect and correlate, using the prescriptive common detection alerts from Verodin, you will know how to write your rules, signatures, etc.

In the example below, the PAN firewall policy was configured to not only alert but also prevent the attack. This is great and is likely the result you would want. However, when the events show up in Splunk, they don’t match a rule, and therefore don’t create a notable event which means it is unlikely that anyone will notice there was attempted C2 activity.

Luckily, as with the prescriptive common detection alerts from Verodin, we can see the events that show up in Splunk from Palo Alto and Snort under the Splunk “Message” section. These events can be used to create a search within Splunk that yields a notable event.

Once you write the Splunk search, you can re-run the attack sequence to validate that it fires correctly and then have it automatically and continuously validate that the notable events continue to alert over time. We’ll cover more details specific to Splunk in future pieces, but tuning SIEMs can be very complicated as highlighted in a previous blog titled SIEMs Sometimes Suck. Verodin SIP makes validating SIEMs are doing what you want and tuning them much easier.

Solutions like Palo Alto Next-Generation Firewalls can perform exceptionally well with proper instrumentation and validation. With Verodin SIP you are able to automatically and continuously manage, measure, and improve security effectiveness. Your risk decreases. The resources needed to tune and achieve value also decrease. And the value gleaned from your solutions as well as the effectiveness of the people and processes related to those solutions increases dramatically.

Learn more about Verodin SIP here.

back to blog