Differences between AWS Security Groups and Palo Alto Networks Virtual Firewall
Symptom
Introduction
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[1].
Resolution
Comparison
The following table is not exhaustive, but highlights a few of the features which are not provided as a part of the built-in security engine within the AWS public cloud. The end of the table lists a few of the AWS specific security controls. It is important to remember that the decision for organizations is not “one or the other”, but to utilize both approaches for a comprehensive security posture.
|
Key Features |
PAN |
AWS |
|
Firewall |
|
|
|
Thousands of applications for visibility and control; ability to create custom applications; ability to manage unknown traffic based on policy |
X |
|
|
User identification and control: VPNs, WLAN controllers, captive portal, proxies, Active Directory, eDirectory, Exchange, terminal services, syslog parsing, XML API |
X |
|
|
Granular SSL decryption and inspection (inbound and outbound); per-policy SSH control (inbound and outbound) |
X |
|
|
Networking: dynamic routing (RIP, OSPF, BGP, multiprotocol BGP), DHCP, DNS, NAT, route redistribution, ECMP, LLDP, BFD, tunnel content inspection |
X |
|
|
QoS: policy-based traffic shaping (priority, guaranteed, maximum) per application, per user, per tunnel, based on DSCP classification |
X |
|
|
Zone-based network segmentation and zone protection; DoS protection against flooding of new sessions |
X |
|
|
Threat Prevention |
|
|
|
Prevention of a wide variety of threats, including vulnerability exploits, malware and botnets |
X |
|
|
Blocking polymorphic malware by focusing on payload, instead of hash or filename |
X |
|
|
Protections automatically updated every five minutes with WildFire |
X |
|
|
Advanced Malware Protection (WildFire) |
|
|
|
Dynamic analysis: detonation of files in a custom-built, evasion-resistant virtual environment, enabling detection of zero-day malware and exploits |
X |
|
|
Static analysis: detection of malware and exploits that attempt to evade dynamic analysis; instant identification of variants of existing malware |
X |
|
|
Machine learning: extraction of thousands of unique features from each file, training a predictive machine learning classifier to identify new malware and exploits |
X |
|
|
Bare metal analysis: evasive threats automatically sent to a real hardware environment for detonation, entirely removing an adversary’s ability to deploy anti-VM analysis |
X |
|
|
Automated signature updates every five minutes for zero-day malware and exploits discovered by any WildFire subscriber |
X |
|
|
Contextual Threat Intelligent Service (AutoFocus) |
|
|
|
Context around attacks, adversaries and campaigns, including targeted industries |
X |
|
|
Accelerated analysis and response efforts, including prioritized alerts for the most critical threats |
X |
|
|
URL Filtering |
|
|
|
Protection against malicious sites exposing your people and data to malware and exploit kits |
X |
|
|
Protection from credential phishing by inspecting webpages to determine whether the content and purpose is malicious in nature. Custom URL categories, customizable alerts and notification pages. |
X |
|
|
File and Data Filtering |
|
|
|
Bidirectional control over the unauthorized transfer of file types and Social Security numbers, credit card numbers and custom data patterns |
X |
|
|
Mobile Security (GlobalProtect) |
|
|
|
Remote access VPN (SSL, IPSec, clientless) and mobile threat prevention and policy enforcement based on apps, users, content, device and device state |
X |
|
|
BYOD: app-level VPN for user privacy |
X |
|
|
Management and Visibility Tools (central policy management) |
|
|
|
Intuitive policy control with applications, users, threats, advanced malware protection, URL, file types, data patterns – all in the same policy |
X |
|
|
Actionable insight into traffic and threats with Application Command Center (ACC), fully customizable reporting |
X |
|
|
Aggregated logging and event correlation |
X |
|
|
Consistent management of all hardware and all VM-Series, role-based access control, logical and hierarchical device groups, and templates |
X |
|
|
GUI, CLI, XML-based REST API |
X |
|
|
Dynamic tagging for policy automation |
|
|
|
Use of granular filtering policies combined with automatic tagging to move compromised hosts between security groups. (e.g., quarantine a host if command and control traffic is seen, for example.) |
X |
|
|
Use of tagging policies to automatically send relevant data to a ticketing system upon security violation |
X |
|
|
General Features |
|
|
|
IP/Port/Protocol based security |
X |
X |
|
Port ranges used within policy |
X |
X |
|
Source and/or destination within policy (note: AWS separates inbound and outbound as separate rules) |
X |
X |
|
CIDR based rules |
X |
X |
|
ACL-like features within a policy |
X |
X |
|
Security applied after traffic enters VPC |
X |
X |
|
Drop vs. Deny distinction within a policy |
X |
|
|
AWS-Specific Features |
|
|
|
Use of an AWS Security Group as a source/destination. |
* |
X |
|
Security applied before traffic enters VPC. *Note: this would be a supplemental feature used in conjunction with Palo Alto Network virtual firewalls. |
|
X |
Effects of using AWS-only security
To utilize only the Security Groups and ACLs available within AWS would be to take your security posture back 25 years in terms of protection. This is due to the port/protocol centric approach of Security Groups. There was a time when using this method was all that was required. When HTTP traffic was only seen on TCP port 80, or when Telnet traffic was only seen on TCP port 23 etc. This simply isn’t the case anymore – and hasn’t been the case for many years. Application traffic not only resides on a wider range of ports, but those ports can often be dynamic in nature covering a huge spectrum. This makes it impossible to create a security policy based on port or port ranges as this opens the door to malware which may use these same well known ports.
Another issue with using strictly port/protocol based security is that many applications potentially use the same port ranges. Modern security requires a way to distinguish between applications, regardless of the port or protocol in use. The following screenshot reveals the port/protocol based security built-in to the AWS model:
Notice the “Type” column in the example. This is not to be confused with application recognition. This is merely a way to choose an application from a list only to have the standard port inserted into the actual rule. To perform application identification, regardless of port or protocol, requires a deep inspection of the session packets. However, this is not how a port/protocol based engine works.
Whether corporate data lives within a corporate data center or the public cloud, it is essential to reduce the attack surface within the security posture. By whitelisting applications which are required for business and eliminating unknown applications, the attack surface may be reduced substantially. When combined with restricting users to accessing only those applications/data needed based on role or group for example, the attack surface is reduced further still. This requires the advanced features of the Palo Alto Networks next-generation firewall. This is true regardless of where the data resides.
Where do the built-in security features of AWS come into the picture? They are used as a supplemental layer of security, rather than a replacement of modern traffic inspection. For example, one could use the Security Groups feature on the perimeter (outside) of the VPC to drop traffic from specific IP ranges (e.g., geo-based, or bad-IP addresses, etc). Another potential use case is to control management to the VPC or to control traffic between VPCs. The requirement for advanced inspection features still exist outside the use of AWS built-in security components.
Summary
In summary, there are two questions to ask when it comes to a “one or the other” approach to public cloud security:
-
Would you be comfortable abandoning your next-generation firewalls at HQ and branch locations protecting users and corporate data (perimeter and data center) and replacing it entirely with an AWS firewall (Security Groups and ACLs)?
-
If the answer is “no,” then does it make sense to use only AWS security to protect your corporate data within the public cloud?
The two components are supplemental and should be deployed together just as you use multiple layers at HQ and branch offices.
Additional Information
References and Notes
[1] 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:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_Network_and_Security.html
“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.”
http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-network-security.html
“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.”
http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-network-security.html
“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:
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html
“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: