Skip to main content

The home of developer docs at

Network Security

Learn how to make the most of the PAN-OS APIs, SDKs, Expedition, Terraform, Ansible, and more.

PAN-OS

Cloud NGFW

Cortex Data Lake

Cloud-Delivered Security Services

Expedition

Secure Access Service Edge

Discover Prisma SASE APIs, including Prisma Access and Prisma SD-WAN.

Prisma SASE

Prisma Access Configuration

Prisma Access Insights

Prisma SD-WAN

Cloud Native Security

Discover the APIs, tools and techniques necessary for bringing DevOps practices to the cloud.

Cloud Security Posture Management

Cloud Workload Protection Platform

Security Operations

Browse reference docs, tutorials, the XSOAR Marketplace and more.

Cortex XSOAR

Cortex

Palo Alto Networks as Code with Terraform

Hashicorp's Terraform is widely used to build and deploy infrastructure, safely and efficiently, with high levels of automation and integration.

Learn More

Ansible at Palo Alto Networks

The collection of Ansible modules for PAN-OS has been officially certified by the Red Hat Ansible team (list of Ansible certified content) since version 2.12.2.

Learn More
Security Automation at BlackHat Europe 2022: Part 2

Security Automation at BlackHat Europe 2022: Part 2

By: James Holland


In part 2 of this double-header, we look at the operations side of the conference infrastructure. If you missed part one, it’s here.

Automating Security Operations Use Cases with Cortex XSOAR

To reiterate from the previous post, on the Black Hat conference network we are likely to see malicious activity, in fact it is expected. As the Black Hat leadership team say, occasionally we find a “needle in a needlestack”, someone with true malicious intent. But how do you go about finding malicious activity with real intent within a sea of offensive security demonstrations and training exercises?

Without being able to proactively block the majority of malicious activity (in case we disrupt training exercises, or break someone’s exploitation demo in the Arsenal), we hunt. To hunt more efficiently we automate. It’s a multi-vendor approach, with hunters from Palo Alto Networks, Cisco, RSA Netwitness and Ironnet all on-site and collaborating. Cortex XSOAR provides the glue between all the deployed inline and out-of-band security tooling, as well as being the conduit into Slack for the analysts to collaborate and communicate.

An investigation may start from various angles and different indicators, and being able to quickly classify if the source of the incident is a training class is a great start. Without leaving Slack, an Cortex XSOAR chatbot is able to provide an automated lookup of a machine’s MAC address, and tell the analyst: the IP address, the vendor assigned to that MAC address where applicable, the wireless access point the host is connected to (thanks to the Cortex XSOAR integration with Cisco Meraki, docs here), and crucially the firewall zone where the machine is located. In the example below, the “tr_digi_forens_ir” zone tells us this machine is in a training class, specifically the digital forensics and incident response class:

That’s really useful information when examining internal hosts, but how about a lookup for IP addresses which are sending traffic towards the Black Hat conference infrastructure in a suspicious way from the outside, from the Internet? To see if any of the variety of available Threat Intelligence sources have specific information available, and the level of confidence. There’s a Slack chatbot query for that too, powered by Cortex XSOAR:

Or checking Threat Intellignce sources for information about a domain being contacted by a machine in the visitor wireless network which is potentially compromised, and analysing it in a sandbox too?

The chatbot has many features, all available to any analyst from any vendor working in the NOC, with no requirement to learn any product’s user interface, just a simple Slack chatbot:

Other ways of automating our operations included ingestion of the data from other deployed toolsets, like the Palo Alto Networks IoT platform, which below is shown creating incidents in Cortex XSOAR based on the passive device and application profiling it does on the network traffic:

The data from the IoT platform enriches the incident, providing the analyst wish a page of information to quickly understand the context of the incident and what action would be appropriate:

As well as integrating Cortex XSOAR with Cisco Meraki, we also integrated Cortex XSOAR with RSA Netwitness, and were able to use alerts from Netwitness to generate and work through any incidents that looked like potentially malicious behaviour.

We also utilised Cortex XSOAR for some more network-focused use cases. For instance, by leveraging the intelligence data maintained within the PAN-OS NGFWs, we were interested to see if there was any traffic approaching the Black Hat infrastructure’s public facing services from TOR exit nodes, and we weren’t disappointed:

We also leveraged Cortex XSOAR playbooks to provide an OSINT news into a dedicated Slack channel, so analysts could see breaking stories as they happen:

And we even used a Cortex XSOAR playbook to proactively monitor device uptime, which would alert into Slack if a critical device stopped responding and was suspected to be “down”:

Summary

It’s an infrastructure full of malicious activity, on purpose. It gets built, rapidly, to a bespoke set of requirements for each conference. It is then operated by a collaboration of Black Hat staff and multiple security vendors’ staff.

That can only happen successfully with high levels of automation, in both the build and the operation phases of the conference. With the automation capabilities of the PAN-OS network security platform, the orchestration from Cortex XSOAR, and the collaboration across vendors, the Black Hat conference was once again a safe and reliable environment for all who attended.

Acknowledgements

Palo Alto Networks would like to once again thank Black Hat for choosing us to provide network security, as well as the automation and orchestration platform, for the operations centres of the conferences this year in Singapore, Las Vegas and London ♥

Thank you Jessica Stafford, Bart Stump, Steve Fink, Neil R. Wyler and ᴘᴏᴘᴇ for your leadership and guidance. Thank you Jessica Bair Oppenheimer, Evan Basta, Dave Glover, Peter Rydzynski and Muhammad Durrani for all the cross-vendor collaboration along with your teams including Rossi Rosario, Paul Fidler, Panagiotis (Otis) Ioannou, Paul Mulvihill, Iain Davison, and (sorry) everyone else who may be lurking on other social media platforms where I couldn’t find them!

And of course, thanks so much to the amazing folks representing Palo Alto Networks in London, great job team; Matt Ford, Ayman Mahmoud, Matt Smith, Simeon Maggioni and Doug Tooth. Also Scott Brumley for his work on the Cortex XSOAR Slack chatbot during the USA conference earlier this year.

Security Automation at BlackHat Europe 2022: Part 2 was originally published in Palo Alto Networks Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read More on Medium
Security Automation at BlackHat Europe 2022: Part 1

Security Automation at BlackHat Europe 2022: Part 1

By: James Holland


In part 1 of this double-header, we look at the build and configuration tasks for the conference.

It’s been called one of the most dangerous networks in the world, and there are many good reasons why each Black Hat conference has its own IT infrastructure built from the ground up.

There are training classes, where attendees learn offensive security techniques, from hacking infrastructure to attacking the Linux kernel, exploiting IIoT, and abusing directory services. There is the Arsenal, where researchers demonstrate the latest techniques, as well as briefings from experts in a variety of security domains. Then add hundreds of eager and interested attendees, who are not only learning from the content at the conference, but may have their own tricks to bring to the party too.

Roll Your Own

A dedicated infrastructure that does not rely (as far as is possible) on the venue’s own network and security capabilities is the only feasible way to host this kind of community of keen security professionals. Building an infrastructure per conference means that a multi-disciplined team, from a variety of vendors and backgrounds, must find ways to make the build as streamlined as possible. Automation is key to the approach.

The Black Hat team chose Palo Alto Networks to provide network security for all three of their conferences during 2022, renewing an annual partnership which now spans 6 years. The partnership includes Palo Alto Networks supplying their staff to work in the conference NOCs, configuring and operating several PA-Series hardware next-generation firewalls (NGFWs). In 2022, the partnership expanded to include the use of Cortex XSOAR to automate security operations.

Automating the Build Process

The build happens in a short period of time; the core infrastructure went from cardboard boxes to “live” in just over one day for the Europe 2022 conference. A design including complete segmentation of each conference area (including segmenting each training class, the Arsenal, the exhibiting vendors, the registration area, the NOC itself, and more), requires a lot of IP subnets and VLANs, multiple wireless SSIDs, and several DHCP servers and scopes. Some DHCP scopes require reservations, particularly where infrastructure components require predictable IP addressing, but there are too many of them for configuration of static addressing to be feasible. And change happens; IT security is a fast-paced industry, and we knew from experience that we would be adding, moving or changing the configuration data as the conference progressed.

With a single source for all of that configuration data, and a PAN-OS network security platform with plenty of automation capability, automation was inevitable, the only choice was the flavour!

Step forward Ansible. With its task-based approach, its ability to bring in configuration data from almost any structured source, and a collection of modules for idempotent configuration of PAN-OS, it was the perfect match for the requirements.

All of those segmented subnets needed configuring with IP addresses, as well as security zones. Here you can see some excerpts from a playbook execution, where Ansible observed modifications in the configuration data source, and changes were made to only to the required items, with the rest being of the configuration left in original state:

This is important; the initial configuration would not be the final configuration, so when re-executing Ansible to make incremental changes, we only want to make modifications where they are needed. This approach also speeds up the processing time for changes.

Below you can also see a long (and truncated, for brevity) list of DHCP reservations required for some of the infrastructure components. They are being configured with a single Ansible task; this is a list of MAC addresses and IP address that definitely does not want to be configured by hand!

The PAN-OS next-generation firewalls are the DHCP servers for every subnet, and at scale, such a large quantity of DHCP servers is also something which nobody would want to configure by hand, so again, Ansible did that for us automatically:

Automatically Keeping an Eye on Suspicious Hosts

It is rare that the Black Hat team has to take any action against a conference attendee; the majority of seemingly malicious activity is usually part of the trainings, a demo in the Arsenal, or something else “expected”. Occasionally attendees approach or cross the line of acceptable behaviour, and during those instances and investigations it is very useful to be able to view the historical data across the conference.

User-ID provides a huge benefit when the network should include known and authenticated users, but at Black Hat conferences, that is not the case. There is no authentication past the pre-shared key to join the wireless network, and no tracking of any person that attends the conference. However, we chose to modify the user-to-IP mapping capability of User-ID to become MAC-to-IP mappings. Being the DHCP server, the PAN-OS NGFWs knew the MAC address of each host as it requested an IP address, so we routed that information into the mapping database. This meant we were able to observe a host machine (without any knowledge of the person using it) as it moved throughout the conference. Even if the machine left the network and joined again later (after lunch!?) with a new DHCP IP address, or if the machine moved between different wireless SSIDs and hence different IP subnets.

Should action be required when a machine is exhibiting unacceptable behaviour, one option is to utilise network security controls based on the MAC address of the host, instead of the IP address. These controls would be applicable no matter which network the host moved into.

Part Two

The second part of this double-header will focus on the operations side of the conference infrastructure, as the team (below) move into threat hunting mode. Carry on reading here…

Security Automation at BlackHat Europe 2022: Part 1 was originally published in Palo Alto Networks Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read More on Medium
The Developer’s Guide To Palo Alto Networks Cloud NGFW for AWS

The Developer’s Guide To Palo Alto Networks Cloud NGFW for AWS

By: Migara Ekanayake


Photo by Glen Carrie on Unsplash

Busy modernizing your applications? One thing you can’t cut corners on is the security aspect. Today, we will discuss network security — inserting inbound, outbound, and VPC-to-VPC security for your traffic flows, to be precise, ​​without compromising DevOps speed and agility. When it comes to network security for cloud-native applications, it’s challenging to find a cloud-native security solution that provides the best in class NGFW security while consuming security as a cloud-native service. This means developers have to compromise security and find a solution that fits their development needs. That’s no longer the case — today, we will look at how you can have your cake and eat it too!

Infrastructure-as-Code is one of the key pillars in the application modernization journey, and there is a wide range of tools you can choose from. Terraform is one of the industry’s widely adopted infrastructure-as-code tools to shift from manual, error-prone provisioning to automated provisioning at scale. And, we firmly believe that it is crucial to be able to provision and manage your cloud-native security using Terraform next to your application code where it belongs. We have decided to provide launch day Terraform support for Palo Alto Networks Cloud NGFW for AWS with our brand new cloudngfwaws Terraform provider, allowing you to perform day-0, day-1, and day-2 tasks. You can now consume our Cloud NGFW with the tooling you are already using without leaving the interfaces you are familiar with; it’s that simple!

Getting Started

Prerequisites

AWS Architecture

We will focus on securing an architecture similar to the topology below. Note the unused Firewall Subnet — later, we will deploy the Cloud NGFW endpoints into this subnet and make the necessary routing changes to inspect traffic through the Cloud NGFW.

Application Architecture

Authentication and Authorization

Enable Programmatic Access

To use the Terraform provider, you must first enable the Programmatic Access for your Cloud NGFW tenant. You can check this by navigating to the Settings section of the Cloud NGFW console. The steps to do this can be found here.

You will authenticate against your Cloud NGFW by assuming roles in your AWS account that are allowed to make API calls to the AWS API Gateway service. The associated tags with the roles dictate the type of Cloud NGFW programmatic access granted — Firewall Admin, RuleStack Admin, or Global Rulestack Admin.

The following Terraform configuration will create an AWS role which we will utilize later when setting up the cloudngfwaws Terraform provider.

https://medium.com/media/d8915d509a0c0702eead9a113506a065/href

Setting Up The Terraform Provider

In this step, we will configure the Terraform provider by specifying the ARN of the role we created in the previous step. Alternatively, you can also specify individual Cloud NGFW programmatic access roles via lfa-arn, lra-arn, and gra-arn parameters.

https://medium.com/media/ca97592b6491495aa21242c76a4077bd/href

Note how Terraform provider documentation specifies Admin Permission Type required for each Terraform resource as Firewall, Rulestack, or Global Rulestack. You must ensure the Terraform provider is configured with an AWS role(s) that has sufficient permission(s) to use the Terraform resources in your configuration file.

Rulestacks and Cloud NGFW Resources

There are two fundamental constructs you will discover throughout the rest of this article — Rulestacks and Cloud NGFW resources.

A rulestack defines the NGFW traffic filtering behavior, including advanced access control and threat prevention — simply a set of security rules and their associated objects and security profiles.

Cloud NGFW resources are managed resources that provide NGFW capabilities with built-in resilience, scalability, and life-cycle management. You will associate a rulestack to an NGFW resource when you create one.

Deploying Your First Cloud NGFW Rulestack

First, let’s start by creating a simple rulestack, and we are going to use the BestPractice Anti Spyware profile. BestPractice profiles are security profiles that come built-in, which will make it easier for you to use security profiles from the start. If required, you can also create custom profiles to meet your demands.

https://medium.com/media/aa4fbade6ffa823fcec6836a47a6f212/href

The next step is to create a security rule that only allows HTTP-based traffic and associate that with the rulestack we created in the previous step. Note that we use the App-ID web-browsing instead of traditional port-based enforcement.

https://medium.com/media/da8119359cfd91cd2d471af2ddc12fde/href

Committing Your Rulestack

Once the rulestack is created, we will commit the rulestack before assigning it to an NGFW resource.

Note: cloudngfwaws_commit_rulestack should be placed in a separate plan as the plan that configures the rulestack and its contents. If you do not, you will have perpetual configuration drift and need to run your plan twice so the commit is performed.

https://medium.com/media/9eeaa739ecbf2c2ab3113b5f05d8f879/href

Deploying Your First Cloud NGFW Resource

Traffic to and from your resources in VPC subnets is routed through to NGFW resources using NGFW endpoints. How you want to create these NGFW endpoints is determined based on the endpoint mode you select when creating the Cloud NGFW resource.

  • ServiceManaged — Creates NGFW endpoints in the VPC subnets you specify
  • CustomerManaged — Creates just the NGFW endpoint service in your AWS account, and you will have the flexibility to create NGFW endpoints in the VPC subnets you want later.

In this example, we are going to choose the ServiceManaged endpoint mode. Also, notice how we have specified the subnet_mapping property. These are the subnets where your AWS resources live that you want to protect.

In production, you may want to organize these Terraform resources into multiple stages of your pipeline — first, create the rulestack and its content, and proceed to the stage where you will commit the rulestack and create the NGFW resource.

https://medium.com/media/3af82ed097ccfb15ed2ced3400baaa22/href

At this point, you will have a Cloud NGFW endpoint deployed into your Firewall subnet.

You can retrieve the NGFW endpoint ID to Firewall Subnet mapping via cloudngfwaws_ngfw Terraform data resource. This information is required during route creation in the next step.

https://medium.com/media/8e3e8465f5a224b6761da982f7477075/href

Routing Traffic via Cloud NGFW

The final step is to add/update routes to your existing AWS route tables to send traffic via the Cloud NGFW. The new routes are highlighted in the diagram below. Again, you can perform this via aws_route or aws_route_table Terraform resource.

Learn more about Cloud NGFW

In this article, we discovered how to deploy Cloud NGFW in the Distributed model. You can also deploy Cloud NGFW in a Centralized model with AWS Transit Gateway. The Centralized model will allow you to run Cloud NGFW in a centralized “inspection” VPC and connect all your other VPCs via Transit Gateway.

We also discovered how to move away from traditional port-based policy enforcement and move towards application-based enforcement. You can find a comprehensive list of available App-IDs here.

There is more you can do with Cloud NGFW.

  • Threat prevention — Automatically stop known malware, vulnerability exploits, and command and control infrastructure (C2) hacking with industry-leading threat prevention.
  • Advanced URL Filtering — Stop unknown web-based attacks in real-time to prevent patient zero. Advanced URL Filtering analyzes web traffic, categorizes URLs, and blocks malicious threats in seconds.

Cloud NGFW for AWS is a regional service. Currently, it is available in the AWS regions enumerated here. To learn more, visit the documentation and FAQ pages. To get hands-on experience with this, please subscribe via the AWS Marketplace page.

The Developer’s Guide To Palo Alto Networks Cloud NGFW for AWS was originally published in Palo Alto Networks Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read More on Medium