5 CN-Series Firewall Use Cases

Text Material Preview

<p>1. Use Case Overview</p><p>This lesson provides an overview of the CN-Series use cases that will be addressed in this course.</p><p>CN-Series Business Drivers and Use Cases</p><p>The following section will describe the business drivers and use cases of the CN-Series containerized next-generation firewall.</p><p>Business Drivers</p><p>Click the tabs for more information about the four key business drivers of CN-Series.</p><p>· Zero Trust - Our customers are looking to extend their zero-trust architecture into their Kubernetes clusters to ensure that their containerized applications are appropriately protected.</p><p>· Regulatory Compliance - Companies are eager to adopt Kubernetes and containerized applications whilst still being compliant with policies such as HIPAA and PCI.</p><p>· Cost Optimization - Another key business driver is optimizing the total cost of ownership. Companies are looking to optimize their firewall spending, which is enabled through our Kubernetes service deployment model.</p><p>· Modernization - The final business driver is infrastructure modernization.</p><p>Use Cases</p><p>Here are a few use cases of CN-Series.</p><p>· Layer 7 visibility and control within the cluster</p><p>· Stopping lateral movement of threats</p><p>· Preventing container-specific inbound attacks</p><p>· Egress filtering to prevent data exfiltration and unwanted outbound connections</p><p>· Microsegmentation</p><p>CN-Series Firewall: Containerized Next-Generation Firewall (NGFW)</p><p>CN-Series provides comprehensive security for containerized applications by running a CN-Series NGFW on each node.</p><p>Containerized applications are fully protected inbound, outbound, and east-west traffic.</p><p>· Outbound - Securing outbound traffic from container environments to the internet or to developer resources hosted in sites like Github. Our URL filtering service provides guardrails for developers and other users to ensure that they aren’t connecting to potentially malicious sites. Our firewall’s ability to inspect traffic content, coupled with our DNS Security service guard against data exfiltration to make sure our customers’ critical information stays in the environment where it belongs.</p><p>While some customers may prefer to do this using their perimeter firewalls in their on-prem data centers, customer running Kubernetes environments in the public cloud will require CN-Series to solve this use case.</p><p>· East-West - Customers can use CN-Series to insert Layer 7 traffic protection and advanced threat protection into their Kubernetes environments in order to secure the allowed connections between two containerized applications of different trust levels or to secure the allowed connections between containers and other workload types. This is the customer use case that we talked about earlier.</p><p>Microsegmentation products, like Aporeto/Prisma Cloud, provide granular protection at Layer 3 and 4 to block traffic between workloads that shouldn’t be able to communicate. The key difference is that CN-Series is able to inspect and control allowed traffic at layer 7, as well as enable our Threat Prevention subscription service to detect and stop threats that may be attempting to move laterally across the environment.</p><p>The two types of solutions can absolutely be used together.</p><p>· Inbound - Network security teams can prevent threats riding on inbound traffic to the container environment with our Threat Prevention and Wildfire malware analysis services. Again, depending on the customer’s environment and overall architecture they may elect to do this with their perimeter firewalls on-prem, but a CN-Series or VM-Series would be required to do this in public cloud environments.</p><p>All three of these use cases can be addressed regardless of whether the apps are hosted in an on-prem data center or a public cloud.</p><p>2. Outbound Use Case</p><p>This lesson describes how CN-Series firewalls can secure traffic from container environments to the internet or hosted developer resources.</p><p>Outbound Traffic Protection</p><p>The CN-Series can inspect traffic to detect and block malicious payloads from container environments to the Internet or to developer resources hosted in sites like GitHub.</p><p>The CN-Series firewall prevents data exfiltration by inspecting outbound traffic content originating from a containerized application, including encrypted SSL traffic, and blocks access to suspicious websites and command-and-control servers while allowing legitimate traffic to pass through. As containerized applications reach out to external resources, the CN-Series firewall can protect traffic against data exfiltration and against potentially harmful sites.</p><p>Outbound Architecture</p><p>In the Outbound use case, CN-Series firewalls are deployed to secure outbound traffic from container environments to external resources.</p><p>In the example shown in the graphic, the Ordering App requires access to the Acme GitHub repository. The Ordering App pod generates the initial outbound traffic destined for GitHub. The pod’s outbound traffic is forwarded to the CN-Series firewall using the Kubernetes Container Network Interface (CNI). The Kubernetes CNI plugin provides both connectivity and reachability for all pods within the node.</p><p>Detailed Architecture</p><p>Below explains the outbound architecture in more detail:</p><p>· The CN-Series firewall uses Dynamic Address Groups to determine the source IP addresses of hosts within the Kubernetes cluster. The Kubernetes Plugin for Panorama extracts and updates IP addresses within Dynamic Address Groups so that the CN-Series firewalls have accurate information about container addresses as pods are spun up and spun down.</p><p>· Traffic through the CN-Series firewall is handled by a V-Wire, with a Security Zone called Trust on the inside, and a separate Security Zone called Untrust on the outside. Traffic passing through the V-Wire on the CN-Series firewall, inbound and outbound, is subjected to Security policy rules as well as Layer 7 inspection.</p><p>· Only authorized traffic is permitted using a Security policy rule which states that traffic from the Ordering Dynamic Address Group, using the GitHub-download application, is permitted. When traffic that matches those criteria is allowed, the CN-Series firewall will also inspect the payload for malicious content using a Security Profile to invoke DNS Security and URL Filtering.</p><p>· Any traffic which does not match a rule in the firewall Security policy is dropped. Legitimate return traffic from Acme GitHub Repository is implicitly allowed back to the initiating application pod using information in the firewall’s session table.</p><p>· By deploying SSL-Decryption, the CN-Series firewall can even inspect traffic encrypted with SSL.</p><p>Outbound Traffic Protection: Example</p><p>The outbound use case is about securing outbound traffic from container environments to the internet or to developer resources hosted in sites like GitHub.</p><p>Palo Alto Networks URL Filtering service provides guardrails for developers and other users to ensure that they aren’t connecting to potentially malicious sites. Palo Alto Networks firewall’s ability to inspect traffic content, coupled with DNS Security, guards against data exfiltration to make sure customers’ critical information stays in the environment where it belongs.</p><p>While some customers may prefer to do this using their perimeter firewalls in their on-prem data centers, customer running Kubernetes environments in the public cloud will require CN-Series to solve this use case.</p><p>The image below is an example of outbound traffic protection of a large retailer in Europe. This example shows how apps are stopped from communicating with malicious target and only allows downloads from a trusted source.</p><p>3. East-West Use Case</p><p>This lesson describes how CN-Series firewalls can secure traffic between pods and between containerized applications and other workload types.</p><p>East-West Traffic Protection</p><p>The CN-Series firewall can enforce Threat Prevention policies between Kubernetes namespaces, as well as between a Kubernetes namespace and other workload types (e.g., VMs and bare metal servers),</p><p>to deter threats from moving between your cloud native applications and your legacy infrastructure.</p><p>By implementing WildFire, the CN-Series can detect and block unknown threats. Both these security services provide protection to detect and stop threats that may be attempting to move laterally across the environment.</p><p>East-West Architecture</p><p>In the east-west use case, CN-Series firewalls are deployed to secure lateral traffic from one set of pods to another. The Kubernetes CNI (Container Network Interface) is configured to forward traffic from the Ordering App pods to the Payment App pods through the CN-Series firewall.</p><p>More information about the east-west architecture use case.</p><p>· Role of Dynamic Address Groups - Using Dynamic Address Groups provided by the Kubernetes plugin, the CN-Series firewall maintains details about the IP addresses of hosts in the Ordering-DAG as well as in the Payments-DAG. These Dynamic Address Groups allow the firewall to impose source and destination IP restrictions to traffic within Security policy rules. As pods are spun up or torn down, the firewall maintains an accurate list of IP addresses from both Dynamic Address Groups.</p><p>· Layer 7 Inspection - In addition to the IP-based component of Security policy rules, the firewall can use Layer 7 inspection to allow only traffic that meets the Payments-App signature. Traffic that does not match the signature is denied.</p><p>· SSL-Decryption - By deploying SSL-Decryption, the CN-Series firewall can even inspect traffic encrypted with SSL.</p><p>In this example, the Ordering App and the Payment App are interdependent and need to communicate with one another.</p><p>East-West Layer 7 Traffic Inspection Example</p><p>The second use case is for east-west traffic. You can use CN-Series to insert Layer 7 traffic protection and advanced threat protection into your Kubernetes environments. This allows you to secure the allowed connections between two containerized applications of different trust levels, or to secure the allowed connections between containers and other workload types.</p><p>Microsegmentation products, like Aporeto, provide granular protection at Layer 3 and 4 to block traffic between workloads that shouldn’t be able to communicate. The key difference is that CN-Series is able to inspect and control allowed traffic at Layer 7, as well as enable our Threat Prevention subscription service to detect and stop threats that may be attempting to move laterally across the environment. The two types of solutions can absolutely be used together.</p><p>The following image is an example of east-west traffic protection of a large healthcare provider in the United States. This example shows how the CN-Series firewall can stop lateral movement of threat and gets visibility inside the cluster.</p><p>4. Inbound Use Case</p><p>This lesson describes how CN-Series firewalls can secure traffic from the internet to the container environments.</p><p>Inbound Traffic Protection</p><p>The CN-Series firewall with Threat Prevention and WildFire malware analysis services combine to prevent threats on inbound traffic to your container environment.</p><p>The CN-Series firewalls enables you to defend against malware delivery aimed at container exploits and vulnerabilities and keeps the latest threats from breaching your network. The CN-Series firewalls protect against malware delivery through custom-built signatures that are based on content, not hash, to protect against known malware.</p><p>Inbound Architecture</p><p>The CN-Series firewalls offer a multitude of security capabilities to prevent data breaches into the Kubernetes environments. Traffic content inspection, including inspection of encrypted SSL traffic, ensures that packets containing malicious payloads are identified and remediated.</p><p>In this example, the Security Policy rule states that traffic from Any Source address going to the Destination address Ordering-DAG using the Application Ordering-App has an Allow action. This Security Policy rule has a Security Profile attached that ensures that Threat inspection and WildFire analysis will be used to detect malicious content.</p><p>Inbound Traffic Protection: Example</p><p>Network security teams can prevent threats riding on inbound traffic to the container environment with the Threat Prevention and WildFire malware analysis services. Again, depending on your environment and overall architecture, you may elect to do this with your perimeter firewalls on-prem, but a CN-Series or VM-Series would be required to do this in public cloud environments.</p><p>The image example shows inbound traffic protection of an online gifting company in the United States. This example shows how deep packet inspection and Threat Prevention is used to stop threats.</p><p>100%</p><p>image7.png</p><p>image8.png</p><p>image9.png</p><p>image16.png</p><p>image3.png</p><p>image15.png</p><p>image10.png</p><p>image1.png</p><p>image4.png</p><p>image2.png</p><p>image11.png</p><p>image13.png</p><p>image6.png</p><p>image14.png</p><p>image5.png</p><p>image12.png</p>