Cisco Secure Firewall with SASE Cloud
In the past, network security was typically delivered from the network using the Firewall. However, these times network security extends well beyond just firewalling. We now have different points in the infrastructure that we can use to expand our security posture while reducing the attack surface. You would have commonly heard of Cisco Umbrella Firewall and SASE, along with Cisco Secure Workload security that can be used with your Cisco Secure firewall that is still deployed at the network’s edge. Unfortunately, you can’t send everything to the SASE cloud.
You will still need an on-premise firewall, such as the Cisco Secure Firewall, that can perform standard stateful filtering, intrusion detection, and threat protection. This post will examine Cisco Secure Firewall and its integration with Cisco Umbrella via the SASE Cloud. Firstly, let us address some firewalling basics.
For additional pre-information, you may find the following helpful:
SASE Cloud. |
|
- A key point: Back to basics with the Firewall
A firewall is an entity or obstacle deployed between two structures to prevent fire from spreading from one system to another. This term has been taken into computer networking, where a firewall is a software or hardware device that enables you to filter unwanted traffic and restrict access from one network to another. The Firewall is a vital network security component in securing network infrastructure and can take many forms. For example, we can have a host-based or network-based Firewall.
Host-based Firewall
A host-based firewall service is installed locally on a computer system. In this case, the end user’s computer system takes the final action—to permit or deny traffic. Every operating system has some Firewall. It consumes the resources of a local computer to run the firewall services, which can impact the other applications running on that particular computer. Furthermore, in a host-based firewall architecture, traffic traverses all the network components and can consume the underlying network resources until the traffic reaches its target.
Network-based Firewall
On the other hand, a network-based firewall can be entirely transparent to an end user and is not installed on the computer system. Typically, you deploy it in a perimeter network or at the Internet edge where you want to prevent unwanted traffic from entering your network. The end-user computer system remains unaware of any traffic control by an intermediate device performing the filtering. In a network-based firewall deployment, you do not need to install additional software or daemon on the end-user computer systems. However, it would help if you used both firewall types for a defense-in-depth approach.
The early generation of firewalling
The early generation of firewalls could allow or block packets only based on the static elements in a packet, such as a source address, destination address, source port, destination port, and protocol information. These elements are also known as the 5-tuple. When an early-generation firewall examined a particular packet, it was unaware of any prior packets that passed through it because it was agnostic of the Transmission Control Protocol (TCP) states that would have signaled this. Due to the nature of its operation, this type of Firewall is called a stateless firewall.
A stateless firewall is unable to distinguish the state of a particular packet. So, for example, it could not determine if a packet is part of an existing connection, trying to establish a legitimate new connection, or whether it is a manipulated, rogue packet. We then moved to a stateful inspection firewall and an application-aware form of next-generation firewalling. The stateful inspection examines the TCP and UDP port numbers, while an application-aware firewall examines Layer 7. So now we are at a stage where the Firewall does some of everything, such as the Cisco Secure Firewall.
Cisco Secure Firewall 3100
Cisco has the Cisco Secure Firewall 3100, a mid-range model which can be an Adaptive Security Appliance (ASA) for standard stateful firewall inspection or Firewall Threat Defense (FTD) software. So it can perform one or the other. It also has clustering, a multi-instance firewall, and high availability, which we will discuss. In addition, the Cisco Series Firewall throughput range addresses use cases from the Internet edge to the data center and private cloud.
- Adaptive Security Appliance (ASA) and Firewall Threat Defense (FTD)
The platforms can be deployed in Firewall (ASA) and dedicated IPS (FTD) modes. In addition, the 3100 series supports Q-in-Q (stacked VLAN) up to two 802.1Q headers in a packet for inline sets and passive interfaces. The platform also supports FTW (fail-to-wire) network modules. Remember that you cannot mix and match ASA and FTD modes. You can, however, make FTD operate close to how the ASA works. For example, the heart of the Cisco Secure Firewall is Snort—one of the most popular open-source intrusion detection and prevention systems capable of real-time traffic inspection.
CPU Core Allocation
What’s powerful about the Cisco Secure Firewall is its high decryption performance due to the Crypto Engine. The Firewall has an architecture built around decrypting traffic and has impressive performance. In addition, you can tune your CPU cores to do more ASA traditional functionality, such as termination IPsec and some stateful firewall inspection. In such a scenario, we have an IPS engine ( based on Snort ) but give it only, let’s say, 10%. In this case, we can provide 90% of the data plane to traditional firewalling. So, a VPN headend or basic stateful Firewall would use more data plane cores.
On the other hand, any heavy IPS and file inspection would be biased toward more “Snort” Cores. Snort provides the IPS engine. So the performance profiles can be tailored to how you see fit. So we have configurable CPU Core allocation, which can be set statically, not dynamically.
- Knowledge Check: Cisco’s Firewalling
Cisco integrated its original Sourcefire’s next-generation security technologies into Cisco’s existing firewall solutions called the Adaptive Security Appliances (ASA). Sourcefire technologies were running as a separate service module in that early implementation. Later, Cisco designed new hardware platforms to support Sourcefire technologies natively.
They are named Cisco Firepower, later rebranded as Cisco Secure Firewall, which is the current implementation of Firewalling. In the new implementation, Cisco converges Sourcefire’s next-generation security features, open-source Snort, and ASA’s firewall functionalities into a unified software image. This unified software is called the Firepower Threat Defense (FTD). After rebranding, this software is now known as the Cisco Secure Firewall.
Secure Firewalling Feature: Clustering
Your Secure Firewall deployment can also expand as your organization grows to support its network growth. You do not need to replace your existing devices for additional horsepower; you can add threat defense devices to your current deployment and group them into a single logical cluster to support additional throughput. A clustered logical device offers higher performance, scalability, and resiliency at the same time. You can create a cluster between multiple chassis or between numerous security modules of the same chassis. When a cluster is built with various independent chassis, it is called inter-chassis clustering.
Secure Firewalling Feature: Multi-Instance
The Secure Firewall offers multi-instance capability powered by the Docker container technology. It enables you to create and run multiple application instances using a small subset of the total hardware resources of a chassis. You can independently manage the threat defense application instances as separate threats defense devices. Multi-instance capability enables you to isolate many critical elements.
Secure Firewalling Feature: High Availability
In a high-availability architecture, one device operates actively while the other stays on standby. A standby device does not actively process traffic or security events. For example, suppose a failure is detected in the active device, or there’s any discontinuation of keepalive messages from the active device. In that case, the standby device takes over the role of the active device and starts operating actively to maintain continuity in firewall operations. An active device periodically sends keepalive messages and replicates its configurations to a standby device. Therefore, the communication channel between the peers of a high-availability pair must be robust and with much less latency.
Evolution of the Network Security
Let’s examine the evolution of network security before we get into some inbound and outbound traffic use cases. Traditionally, the Firewall was placed at the network edge, acting as a control point for the network’s ingress/egress point. The Firewall was responsible for validating communications with rule sets and policies created and enforced at this single point of control to ensure that desired traffic was allowed into and out of the network and undesirable traffic was prevented. This type of design was known as the traditional perimeter approach to security.
Firewalling challenges
Today, branch office locations, remote employees, and increasing use of cloud services drive more data away from the traditional “perimeter,” The cloud-first approach completely bypasses the conventional security control point. Further, the overwhelming majority of business locations and users also require direct access to the Internet, where an increasing prevalence of cloud-based critical applications and data now lives. As a result, applications and data become further de-centralized, and networks become more diverse.
This evolution of network architectures has dramatically increased our attack surfaces and did the job of protecting more complicated ones. So we started to answer this challenge with point solutions. Typically, organizations have attempted to address these challenges by adding the “best” point security solution to address each new problem as it emerges. Because of this approach, we have seen tremendous device sprawl. Multiple security products across different vendors can pose significant management problems for network security teams. Which eventually will lead to complexity and then blind spots.
Consequently, our “traditional” firewall devices are being augmented by a mixture of physical and virtual appliances—some are embedded into the network. In contrast, others are delivered as a service, host-based, or included within public cloud environments. Regardless of the design, you will, stall have inbound and outbound traffic to protect.
Inbound Use case
The Firewall picks up every packet, looks at different fields, examines for signatures that could signal an attack is in process, and then re-packed and sends the packet out its interfaces. Still, the technique is relevant. It tracks inbound traffic to tell if someone outside or inside is accessing the private applications you want to keep secure. So, looking at every packet is still relevant for the inbound traffic use case.
So keep in mind while everything is encrypted these days, you need to decrypt traffic to get value for security. So Deep Packet Inspection (DPI) is still very relevant for inbound traffic. So we will continue to decrypt inbound traffic for complete application threat protection with the hope of minimal functional impact.
Outbound Use Case
Then we need to look at outbound traffic. Here things have changed considerably. Some users need to catch up to a firewall and then go to applications hosted outside the protection of your on-premise security stack and network. These are applications in the cloud, such as SaaS applications, that do not like when the network devices in the middle interfere with the traffic.
Therefore, applications such as Office365 make an effort with their design to reduce the chances of the potential of any network and security device from peeking into their traffic. So, for example, you could have mutual certificate authentication with the service in the cloud. So there are a couple of options here besides the traditional DPI use case for inbound traffic use case.
SASE Cloud
One way to examine SaaS-based applications and introduce some cloud security is by using Cisco Umbrella with the SASE Cloud. The SASE Cloud has a cloud access security broker known as Cloudlock. The Cisco Umbrella CASB delivered from the Cisco Cloudlock solution is like a broker that hooks into the application’s backend to determine users’ actions. It does this by asking for the service via an Application Programming Interface (API) call and not by DPI.
SASE Cloud and CloudLock
Cisco Cloudlock is part of the SASE cloud that provides a cloud-native cloud access security broker (CASB) that protects your cloud users, data, and apps. Cloud lock’s simple, open, and automated approach uses APIs to manage the risks in your cloud app ecosystem. With Cloudlock, you can more quickly combat data breaches while meeting compliance regulations. Cisco Umbrella also has a firewall known as the Cisco Umbrella Firewall. We can take the Cisco Umbrella Firewall to improve its policy decision using information gleaned from the CASB. In addition, we map network flows to a specific user action via cloud applications and CASB solutions. So this is one area you can look into.
Endpoint controls
Then we have the endpoint, such as your desktop computer or phone. Here we can collect a wealth of information about each network connection. This information can be fed into the Firewall via metadata. So you can provide both the Cisco Umbrella Firewall and the Cisco Secure Firewall. Again for improved policy. So the Firewall, either the Cisco Secure Firewall or Cisco Umbrella Firewall, does not need to decrypt any traffic. Instead, we can get client context discovery via passive fingerprinting using an agent on the endpoint. So we can get a wealth of attributes you can’t get with DPI. So we can move from DPI to everything and augment that with all other components to get better visibility.
Data Center Security. Use Case:
So if you look at data center security, network firewalls are difficult to insert for two main reasons. Firstly, because of encrypted traffic, developers implement different overlay solutions to help protect their applications. For example, we could have a service mesh overlay technology. So how does the Firewall look at this traffic? But the network will still have to have an entry point. So there will still need to be an edge. So we still need a firewall, and we will always have an edge, and it can be a physical or virtual or a cloud-delivered firewall via a SASE solution.
In this use case, we have a private or cloud-delivered firewall that inspects the application edge. We can implement Zero Trust Network Access (ZTNA) and continuously apply a whole stack of relevant inline security services.
- A key point: Client Zero Trust Network Access (ZTNA)
ZTNA now expands well beyond network admission control. Admission control is no longer a binary yes or no. With ZTNA, user activity must be continuously tracked throughout the application session. Cisco has a Secure Client called AnyConnect, which delivers ZTNA with Firewall. We can have a bunch of technologies here, such as dynamic policies and access lists for granular posture-driven app access to single sign-on with SAML for unified authentication. ZTNA also has certificate-based and Cisco Duo Passwordless authentication.
Cisco Secure Workload
Then we have deeper into hybrid cloud data center use cases. First, we need to look at Cisco Secure Workload. We have network security that spins up a firewall next to the application, so instead of 30000 signatures, you can spin up only what you need. So these tiny firewalls and enforcement points can protect relevant workloads.
For this space, Cisco has what’s known Cisco Secure Workload feature. Cisco Secure workload protects the host OS and file levels in this case. So the main difference is that instead of doing the entire inspection, we can selectively inspect network and service mesh traffic with an inline firewall and API controls. This Cisco Secure Workload feature from Cisco integrates with the public cloud and cloud-native orchestrators.
- A key point: Cisco Secure Workload.
So with a Cisco secure workload, we ingest network telemetry from agents, Netflow/IPFIX, and VPC logs. Then we can have policy recommendations based on observed communication. So with all of these components, we are getting end-to-end application protection. This solution will help you reduce your attack surface to an absolute minimum with zero trust microsegmentation. With this approach to segmentation, we can stop threats from spreading and protect the application with zero-trust microsegmentation, on any workload, across any environment.
Extending the Firewall with SASE Cloud: Cisco Umbrella Firewall
The SASE Cloud with Cisco Umbrella firewall is a good solution that can be combined with the on-premise Firewall. So if you have FDT at the edge of your network, why would you need to introduce a Cisco Umbrella Firewall or any other SASE technologies? or if you have a SASE cloud with a Cisco Umbrella, why would you need FDT?
First, it makes sense to process specific traffic locally. But the two categories of traffic that Cisco Umbrella excels beyond any Firewall are DNS and CASB. Your edge firewall is less effective against some outbound traffic, such as dynamically changing DNS and undecryptable TLS connections. DNS is the bread and butter of Cisco Umbrella.
- Knowledge Check: Cisco DNS-layer security.
DNS requests precede the IP connection, enabling DNS resolvers to log requested domains over any port or protocol for all network devices, office locations, and roaming users. As a result, you can monitor DNS requests and subsequent IP connections to improve the accuracy and detection of compromised systems, security visibility, and network protection. You can also block requests to malicious destinations before a connection is even established, thus stopping threats before they reach your network or endpoints. Cisco Umbrella under the hood can clean your DNS traffic and stop the attacks before they get to any malicious connection.
- A critical point. SASE Cloud: Cisco Umbrella CASB.
Also, for SaaS-based applications and CASB. You can not decrypt those on the edge firewall. The Firewall can’t detect if the user is carrying out any data exfiltration. So with SASE cloud, Cisco Umbrella, and its integrated CASB offering, we get better visibility in this type of traffic and apply a risk category to certain kinds of activity. So now we have an excellent combination. And the cloud security stack does what it does best, processing cycles away from the Firewall.
Cisco Umbrella Integration
So with the Cisco Secure Firewall, they have nice DNS redirection to the Cisco Umbrella Firewall. The on-premise Firewall communicates API to Cisco Umbrella and pulls in the existing DNS policy so the Umbrella DNS policies can be used with the current firewalling policies. Recently, Cisco has gone one step further, and you can have a SIG tunnel between Cisco Secure Firewall Management Center (FMC) and Cisco Umbrella.
So there is a tunnel and have per tunnel IKE ID and bundle multiple tunnels to Umbrella. Now we can have load-balance across multi-spoke tunnels with per-tunnel custom IKE ID. Once set up, we can have certain kinds of traffic going down each tunnel.
- Rise in Ransomware Attacks - March 31, 2023
- Network Connectivity - March 30, 2023
- Carriers Based on Open Ethernet with SONiC - March 28, 2023