Need to Secure Cloud Native Applications? Take a Look at Airport Security

Securing an airport and securing your cloud-native applications have more in common than you may realize – and two essentials of airport threat prevention nicely illustrate why virtual and container NGFWs are vital for security in the cloud. As digital transformation drives you to move crown jewel applications to public clouds and containers, you need to use the same layered security approach airports typically provide. 

Cloud Native Apps Need to Travel to More Than One Environment

Before we head off to our airport analogy, it’s important to understand that most enterprises today use data centers and multiple public clouds. On top of that, they run workloads, some of which now may be containerized or serverless, but most organizations still have plenty of bare-metal servers, virtual machines and even mainframes. 

But regardless of where workloads run, what companies really care about are the enterprise applications running on top of their hybrid infrastructures. These enterprise applications tend to be highly interconnected. Most apps connect to core services – services such as Active Directory, administration, monitoring and logging infrastructure. Many of these apps also connect to critical databases running on legacy systems such as Solaris or mainframes. Because it's the network that connects these apps, network security needs to span the entire infrastructure. That’s why network protection for cloud native applications needs to be approached holistically. Cloud native applications don’t live on isolated islands or an annex tucked away from the rest of an airport.

Complete network protection requires next-generation firewalls (NFGWs) and identity-based microsegmentation. And because our cloud journey is an ongoing journey, it’s important to gain complete visibility into all the connections made over the network. This includes internet to the workloads, workloads to the internet, and workloads to workloads. 

Scanning and Detection are Vital for Airports – And Your Public Cloud Journey

Visibility into the overall environment is a first step, but only a first step to ward off threats – we’d all worry if airport security was limited to CCTV cameras. Fortunately, airports have two additional and deeper layers of security, which are instructive when it comes to securing cloud native applications: 

1. Full body and luggage scanners: The goal of this layer is to ensure that people heading toward departing airplanes are not carrying anything dangerous. Security agents (such as the TSA in the United States) perform this task with scanning equipment that examines people, luggage and myriad small items. Airport authorities deploy this process at strategic locations. Some airports have only one security and scanning station at the entrance, while bigger airports tend to have one or more at the boundary of each terminal.

And this is where NGFWs come in, because they map to these security scans. Just as security is deployed at strategically chosen perimeters at the airport, NGFWs need to be deployed at carefully chosen perimeters or trust boundaries.  

2. Boarding pass scanners: The goal of this layer of inspection is to reduce the attack surface by minimizing the movement of people into places where they are not supposed to go. Boarding pass scanners are deployed at every gate – typically as close as possible to the boarding entrance of the appropriate airplane. 

Similarly, microsegmentation is another form of access control that reduces the attack surface by minimizing allowed connections between workloads. If you only allow connections absolutely required for applications to function and then block everything else, damage can be significantly minimized because a breach can be effectively contained to the location where it occurs. In cloud-native environments – where workloads are very dynamic and IP addresses are meaningless – microsegmentation policies need to be enforced by using the identity of the workloads. The Palo Alto Networks Prisma Cloud platform delivers scalable, identity-based microsegmentation that complements the capabilities of the NGFW.

Just as boarding pass scanners are deployed at every airport gate, microsegmentation needs to be enforced at every workload, and agent-based solutions are best suited for enforcing microsegmentation policies right at the workload level. 

Understand What Goes into Cloud Native Scanning and Detection

Now, let’s discuss what kinds of protection the NGFWs provide in these cloud-native environments: 

• Inbound Protection: In order to serve applications to users on the Internet, workloads need to accept connections from the Internet. Most modern applications are exposed on HTTPS, and inbound connections are generally protected by cloud-based web application firewalls (WAFs). Still, most workloads – not just Internet-facing workloads – need to accept inbound connections from orchestration and monitoring tools such as Terraform and Puppet, connections on MySQL ports from database admins, and on the ssh/RDP ports from the server admins. 

These allowed connections – combined with software vulnerabilities and the ongoing struggle to deploy patches – increase the risk of attackers breaking into your infrastructure. Case in point, our researchers deployed a containerized version of Drupal 8 fully secured by cloud-native security tools in a public cloud. The container was compromised in 45 minutes. You can read more about this particular attack in our whitepaper, “Five Major Security Threats and How to Stop Them.”

An NGFW continuously being updated from a cloud service, however, can protect these workloads from threats and exploits so your workloads don’t end up being used for bitcoin mining or other malicious activity. 

• East-West Protection: Zero Trust philosophy assumes that it’s not a matter of if but when someone will break into your infrastructure. That’s why you need to have east-west protection in place to prevent threats from moving laterally. Not all applications have the same risk of a breach or the impact on business. Some have higher risk because they run vulnerable software or are directly connected to the internet. Others are just more important in the larger scheme of things because they have access to your business-critical data. 

Deploying an NGFW with threat protection capabilities for all the traffic that crosses the trust boundaries (such as traffic between staging and production or production and PCI environments) allows you to successfully contain a breach and prevent it from moving laterally to mission-critical applications or data. 

• Outbound Protection: Most workloads need to connect outbound to the Internet for activities such as downloading software updates or using public APIs (such as the egress requirements for Terraform and Puppet). This means outbound connectivity on TCP ports 80 and 443 need to be allowed for most workloads with cloud-native access control tools such as AWS Security Groups or Kubernetes network policies. 

Allowing outbound connectivity from port TCP ports 80 and 443 to the Internet also gives attackers the ability to exfiltrate data from these workloads, download malware from dangerous sites on them, and use these workloads to launch DoS attacks on other sites. This means port-level controls won’t cut it for outbound protection. 

You can use the layer-7 filtering capabilities of an NGFW to only allow the required connections and block everything else. The URL filtering capabilities of an NGFW can easily and automatically block connections to any malicious websites on the Internet.

Three Factors Help Decide NGFW Location

Just as airport security must choose where full scanning takes place, network security teams need to choose the trust boundaries where NGFWs will be deployed. Three factors often play into these decisions: 

1. Compliance requirements for the applications, such as the Payment Card Industry Data Security Standard (PCI DSS).
2. Breach risk for an application driven by unpatched vulnerabilities – whether or not the application is connected directly to the Internet (both inbound and outbound).
3. Business impact of a breach, which is driven by how mission critical that application is for the enterprise.

Zero Trust philosophy calls for pushing the trust boundary as close as possible to applications, but operational complexity can keep pushing it back. Most enterprises make boundary decisions based on their security budgets and ability to push security deeper into these environments. 

In the public cloud, Amazon Web Services (AWS) virtual private clouds (VPCs) or Microsoft  Azure virtual networks (VNETs) are generally chosen as the trust boundaries, which calls for NGFWs to inspect traffic going in and out of these perimeters. 

Get Packed Up and Ready to Go

Just like a trip to the airport, security for cloud-native applications and workloads require that you understand the journey, the destination – and what you need to pack. Complete network visibility, identity-based microsegmentation at the workloads, and next-gen firewalls deployed at strategically chosen trust boundaries will move you closer to the Zero Trust posture needed to protect your organization as it moves forward with cloud native applications and workloads. 

For more information about cloud-native risk in your travels, come to the Make It Real! virtual launch event in June. You’ll have a first-class seat as we unveil industry firsts in container network security vital for securing cloud-native applications. Register and save the date for “A Paradigm Shift In Cybersecurity...Intelligent Network Security”

Intelligent Network Security: LinkedIn Live Broadcast

AJ Shipley, vice president of product, and Paul Calatayud, Americas CSO, appeared on LinkedIn Live to answer questions about the industry’s first ML-Powered NGFW. Watch the event on-demand.