Differences between AWS Security Groups and Palo Alto Networks Virtual Firewall
As enterprises continue to embrace public cloud resources, it is important to keep a keen eye on securing applications and data. Not because corporate data potentially resides in a data center other than your own, but because it is still corporate data – regardless of its locale. Security organizations within the enterprise will need to adjust to corporate applications and data residing anywhere, and being accessible from everywhere – and potentially from any device. This effectively erodes the standard perimeter model for security. The perimeter is now around the applications and data, no matter where they reside.
This transition will require an understanding of what security features may be offered from the public cloud vendor, and equally important – what is not offered. The built-in security offerings within the public cloud are not on par with those offered by the Palo Alto Networks security platform. This document highlights some of those differences – specifically for AWS but the same concepts apply to Azure. Also shown is how the same platform approach taken within the private data center must be extended to the public cloud – or wherever your applications and data are accessible.
A comparison between the two easily reveals that the built-in security features are in reality, no comparison to the Palo Alto Networks platform approach. In fact, they are supplemental and should be deployed together. For AWS, the built-in security cannot be disabled and is a requirement. However, leaving your security posture with only the built- in engine is something that not even AWS recommends.
References and Notes
 AWS Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/
What is the best practice for deploying AWS and Palo Alto Networks VM-Series firewall in the public cloud?
In the AWS VPC, security groups and network ACLs control inbound and outbound traffic; security groups regulate access to the EC2 instance, while network ACLs regulate access to the subnet. Because you are deploying the Palo Alto Networks VM‐Series firewall, set more permissive rules in your security groups and network ACLs and allow the firewall to safely enable applications in the VPC while inspecting sessions for malware and malicious activity.
AWS Security Groups use port/protocol:
“You can use security groups to control who can access your instances. These are analogous to an inbound network firewall that enables you to specify the protocols, ports, and source IP ranges that are allowed to reach your instances. You can create multiple security groups and assign different rules to each group. You can then assign each instance to one or more security groups, and we use the rules to determine which traffic is allowed to reach the instance. You can configure a security group so that only specific IP addresses or specific security groups have access to the instance.”
“A security group acts as a virtual firewall that controls the traffic for one or more instances. When you launch an instance, you associate one or more security groups with the instance. You add rules to each security group that allow traffic to or from its associated instances.”
“If you have requirements that aren't met by security groups, you can maintain your own firewall on any of your instances in addition to using security groups.”
Security Groups and ACLs combined are referred to a “firewall” within AWS:
“A network access control list (ACL) is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. You might set up network ACLs with rules similar to your security groups in order to add an additional layer of security to your VPC.”
AWS Rule Types are simply replaced with the standard port typically used by the application:
AWS Outbound rules follow the same port/protocol syntax:
The following is an example default network AWS ACL for a VPC that supports IPv4 only:
Example AWS ACL creation: