That “little” AWS Security Group to PAN Migration Project

person holding compass
Photo by Valentin Antonucci on

AWS Security Groups filters the traffic for one or more instances. It accomplishes this filtering function at the Transmission and IP layers, via their respective ports, and source/destination IP addresses.

At least one Security Group is associated to an instance and it carries a set of rules that filter traffic entering and leaving the instances.

Security Groups have a set of rules that filter traffic in two ways: inbound and outbound. The SG has a “Deny All” that allows data packets to be dropped if no rule is assigned to them from the source IP.

The quota for security groups per network interface multiplied by the quota for rules per security group can’t exceed 1,000.

SGs can and should be combined with NACLs and Next Generation Firewalls for a layered approach for an overall security posture.

In this blog/lab I’m going to “transfer” granular SG rules to a Palo Alto NGFW located at a central location and use “generic” SG rules.

Here comes some help!

Expedition is the fourth evolution of the Palo Alto Networks Migration Tool. The purpose of this tool is to help reduce the time and efforts of migrating a configuration from a supported vendor to Palo Alto Networks.


The Ubuntu server should have internet access as the installer script will perform an update of the
Expedition software by connecting to the Palo Alto Networks update servers for Expedition and
additional Ubuntu dependencies, such as MariaDB, Apache Web Server, RabbitMQ, JVM 1.8, etc

  • Login with default credentials ,username=”admin”, password=”paloalto”

Load Devices:

Create Project

Converting SGs to Security Policies

Expedition does not support a direct conversion from AWS SGs or any other cloud service provider construct to PAN as the constructs/policies as those are different objects. The way we found out to do it is first to transform SGs into CSV (comma separated values) and then import to Expedition.

Firewall policies can be a lot more complex and supports a wider range of cases. I’m working with the minimum input required to create a security policy.

From a SG we can extract directly: the protocol, port range, and source:

We can assume the action (allow) and get the destination (inbound rule) or source (outbound rule) querying the SG association. While to create a PAN policy we need:

  • source and destination addresses
  • service
  • action

To create a service we need to combine the protocol and port range and the way we did it was to create a separate file called service containing that information.

Services file example:


The service file will be ingested first by Expedition and the security policy file can refer to it as in the example below:


Thanks to my buddy Ron to come up with a tool to generate those files automagically.

Importing CSV into Expedition

  • importing services

Once the file is loaded, we need to map columns to the proper values:

Then “import data”:

  • importing rules

Once the file is loaded, we need to map columns to the proper values:

Then “import data”:

Corner Cases

  • AWS SG uses “-1” while PAN uses “Any”
  • AWS SG uses “icmp” while PAN refers to it as an application “ping”

Applying Rules to NGFW

Import base config:

Go to export and drag and drop from the left to the right the objects for migration:

And then click “merge”:

After you have created the Final configuration we have to options to deploy it, one is manual XML file export that can be deployed on the PAN device that we are migrating to, or if that PAN device is already connected to Expedition, we can use API calls to send parts of the configuration or the whole configuration to the device.

Another option is to use the API Output Manager:

  • Generate API Requests (atomic = single API call; subAtomic = multiple API calls):
  • Send API Requests:

Checking the result:

Do not forget to commit 😉


Leave a Reply