Unifying Cyber Defenses: How Hybrid Mesh Firewalls Shape Modern Security

The traditional castle-and-moat model of cybersecurity is outdated due to the evolving perimeter caused by remote work and fluid data access. Organizations must integrate security at every touchpoint. The proliferation of IoT devices increases entry points for cybercriminals, necessitating a unified approach to endpoint security.

Advanced technologies like AI and quantum computing are transforming cybersecurity, making threats more sophisticated and encryption standards vulnerable. The convergence of technologies, such as networked sensors and big data, expands the attack surface while improving AI capabilities for both attackers and defenders. The increasing sophistication of cyberattacks, as seen in incidents like the SolarWinds hack and Colonial Pipeline attack, highlights the need for proactive, integrated security strategies.

Critical infrastructure vulnerability, regulatory considerations, and the necessity of collaborative security practices underscore the importance of a Unified Security Platform to provide adaptive defenses and foster a security-conscious culture within organizations. The Hybrid Mesh Firewall emerges as a vital component in this landscape, offering the flexibility and comprehensive protection required to meet modern cybersecurity challenges. Before we delve into “What is Hybrid Mesh Firewall”, let us discuss a few customer problems:

Key problem areas for customers

1. Misconfigurations and vulnerability exploitation

One of the most significant issues plaguing organizations is the prevalence of misconfigurations and the exploitation of these vulnerabilities. Despite having multiple security products in place, the risk of human error and the complexity of managing these systems can lead to critical security gaps.

2. Rapid attack execution

The speed at which cyber-attacks can be executed has increased dramatically. This necessitates even faster defense responses, which many traditional security setups struggle to provide. Organizations need solutions that can respond in real-time to threats, minimizing potential damage.

3. Hybrid environments

The modern workforce is distributed, with employees working from various locations and using multiple devices. This hybrid environment requires robust protection that is enforced as close to the user or device as possible. The conventional approach of backhauling remote user traffic to a central data center for inspection is no longer viable due to performance, scalability, and availability constraints.

The emergence of SASE has transformed how network and security solutions are designed, providing connectivity and protection for a remote workforce. However, the shift to distributed controls has become inevitable, presenting its own set of challenges. Many customers deploy best-of-breed security products from different vendors, hoping to cover all bases. Unfortunately, this often results in a complex, multi-vendor environment that is difficult to manage.

4. Siloed security management

Managing security across different silos, with multiple teams and solutions, adds to the complexity. Each system must operate effectively within the principles of Zero Trust, but ensuring consistent performance across all products is challenging. Security systems need to work cohesively, but disparate tools rarely interact seamlessly, making it hard to measure and manage risks comprehensively.

The hybrid mesh firewall solution

Hybrid mesh firewall platforms enable security policy enforcement between workloads and users across any network, especially in on-premises-first organizations. They offer control and management planes to connect multiple enforcement points and are delivered as a mix of hardware, virtual, cloud-native, and cloud-delivered services, integrating with other technologies to share security context signals.

By unifying various firewall architectures, Hybrid Mesh Firewalls ensure consistency and coherence, proactively identifying gaps and suggesting remediations for a holistic approach to network security.

Benefits of hybrid mesh firewalls

1. Unified security management: By consolidating various security functions into a single platform, Hybrid Mesh Firewalls simplify management and reduce the likelihood of misconfigurations. Administrators can oversee and configure all aspects of network security from one place, ensuring that no critical security gaps are overlooked.
2. Proactive threat identification and remediation: The platform continuously monitors the network for vulnerabilities and misconfigurations, such as when a team managing the Secure Service Edge (SSE) solution inadvertently allows direct access to a risky file-sharing site. In such cases, the firewall promptly alerts the admin and provides a remediation flow, ensuring only low-risk apps access the internet directly while other traffic is securely tunneled. This proactive approach prevents incidents before they occur, safeguarding the network from potential threats like data exfiltration or malware infiltration.
3. Real-time response: With the capability to respond in real-time to threats, Hybrid Mesh Firewalls ensure that security measures keep pace with the speed of attacks. This rapid response capability is crucial for minimizing damage and maintaining business continuity.
4. Zero trust enforcement: Each component of the security system operates independently but within the overarching principle of Zero Trust. This means that the endpoint protection software on a remote user’s device functions correctly, regardless of the firewall configuration at the data center, and vice versa. Every element of the security infrastructure works to ensure that trust is never assumed and always verified.

Beyond remote work: Securing workloads everywhere

The need for robust security extends beyond the realm of remote work. Modern organizations are leveraging a mix of private and public cloud environments to run their workloads. Whether it’s a private data center, a public cloud provider like AWS or Azure, or even multiple public clouds, the security landscape becomes increasingly complex.

Hybrid Mesh Firewalls are designed to secure workloads regardless of their location. This approach ensures that security policies are consistently applied across all environments, whether on-premises, in a single public cloud, or across multiple cloud providers.

Securing hybrid workloads:

1. Consistent policy enforcement: By providing a unified platform, Hybrid Mesh Firewalls ensure that security policies are consistently enforced across all environments. This eliminates the risk of discrepancies that can arise from using different security products in different locations.
2. Integrated visibility and control: With integrated visibility into all network traffic, Hybrid Mesh Firewalls allow administrators to monitor and control security policies from a single interface. Centralized management is crucial for identifying and mitigating risks across diverse environments.
3. Scalability and flexibility: As organizations grow and their infrastructure evolves, Hybrid Mesh Firewalls offer the scalability and flexibility needed to adapt to new requirements. Whether adding new cloud environments or scaling up existing ones, the firewall platform can grow with the organization.

Conclusion

The need for Hybrid Mesh Firewalls has never been more critical. As organizations navigate the complexities of a distributed workforce, hybrid environments, and the ever-evolving threat landscape, a unified, proactive, and real-time approach to network security is essential. Hybrid Mesh Firewalls offer the consistency, control, and comprehensive protection needed to secure modern hybrid environments effectively. By addressing the key problem areas of misconfigurations, rapid attack execution, and siloed security management, they provide a robust solution that meets the demands of today’s cybersecurity challenges and beyond.

Source: cisco.com

Continue reading

Secure Firewall & Multicloud Defense: Secure Connectivity With Simplified Policy Across Clouds

Most of our large customers today have datacenters and leverage multiple clouds to maximize flexibility and agility for meeting their business needs. Traditionally, the security for these environments has rested with different teams, each having their own tools and processes. But as our application and IT environments become more interwoven, the complexity of the environments and the challenge of securing them has massively increased. Siloed tools and teams are now part of the problem, generating new gaps and blind spots. Attackers are growing more sophisticated and taking advantage of these new challenges. In fact, last year, 39% of breaches spanned multiple environments and cost organizations an average of $4.75M per breach globally.

It is time to rethink how organizations approach the hybrid-multicloud security strategy — converging the fabrics between on-premises and cloud network security to foster collaboration across teams and deliver a unified edge security strategy.

Today, we are we’re bringing on-prem and cloud security together into one unified platform through the Cisco Security Cloud to marry the power of Cisco Secure Firewall and Cisco Multicloud Defense. Combined, these solutions provide multi-environment customers with greater visibility and protection across environments, more consistent control to reduce risk, and simplified security policy creation to alleviate complex operations.

This year at RSA Conference 2024, customers can experience where security meets the network with new capabilities between these solutions — as part of our unified security platform.

Multicloud networking: Secure connectivity from ground to cloud

Imagine you have an application on-prem that needs to talk to an application in the cloud, how would you approach this challenge? Traditionally, organizations have had to rely on 3rd party native tools. However, these services can be costly — especially as you scale applications and environments. And as you scale, the complexity increases, reducing visibility and control of critical security functions. Now, by leveraging our unified platform with the Cisco Security Cloud, customers can build these connections in house with secure site-to-cloud and cloud-to-cloud connectivity between applications and environments. With this, organizations will be able to securely scale hybrid cloud operations while reducing cost and maintain visibility and control of their connections and data.

New network object sharing further simplifies policy creation across multi-environments

In many cases today, organizations are building, deploying, and managing policies in silos. This disparate method strains teams — creating laborious, redundant steps in the policy building process, leads to increased risk of human error and cues the dreaded swivel chair scenario — hopping between numerous tools and platforms to build policies.

At Cisco Live EMEA, we announced general availability of network object sharing for static objects. Today at RSA Conference, we’re reducing multi-environment complexity even further with the ability to now share dynamic objects using our unified management fabric. This gives organizations a single location to pool objects, simplifying policy building and management across environments. Baked into the Cisco Security Cloud platform, this capability empowers organizations to easily share objects between Secure Firewall and Multicloud Defense, reducing complexity, removing duplicative processes, and stopping the pain of maintaining yet another case of siloed operations across separate solutions.

As we continue to innovate across the Cisco Security Cloud, synergies across the network security portfolio will continue to grow. The launch of these shared capabilities between Cisco Secure Firewall and Cisco Multicloud Defense is a significant step towards converging the fabrics of best-in-class data center and cloud security to protect customers from ground to cloud.

Looking to get started? Understand your risk by signing up for our free Cloud Visibility and Risk Report. Powered by Cisco Defense Orchestrator and Cisco Multicloud Defense, our solutions run alongside your clouds to help you understand your risk with pervasive visibility into assets and connections — our experts then provide you with actionable security insights and recommendations to better protect your infrastructure.

Source: cisco.com

Continue reading

The New Normal is Here with Secure Firewall 4200 Series and Threat Defense 7.4

What Time Is It?

It’s been a minute since my last update on our network security strategy, but we have been busy building some awesome capabilities to enable true new-normal firewalling. As we release Secure Firewall 4200 Series appliances and Threat Defense 7.4 software, let me bring you up to speed on how Cisco Secure elevates to protect your users, networks, and applications like never before.

Secure Firewall leverages inference-based traffic classification and cooperation across the broader Cisco portfoliowhich continues to resonate with cybersecurity practitioners. The reality of hybrid work remains a challenge to the insertion of traditional network security controls between roaming users and multi-cloud applications. The lack of visibility and blocking from a 95% encrypted traffic profileis a painful problem that hits more and more organizations; a few lucky ones get in front of it before the damage is done. Both network and cybersecurity operations teams look to consolidate multiple point products, reduce noise, and do more with less; Cisco Secure Firewall and Workload portfolio masterfully navigates all aspects of network insertion and threat visibility.

Protection Begins with Connectivity

Even the most effective and efficient security solution is useless unless it can be easily inserted into an existing infrastructure. No organization would go through the trouble of redesigning a network just to insert a firewall at a critical traffic intersection. Security devices should natively speak the network’s language, including encapsulation methods and path resiliency. With hybrid work driving much more distributed networks, our Secure Firewall Threat Defense software followed by expanding the existing dynamic routing capabilities with application- and link quality-based path selection.

Application-based policy routing has been a challenge for the firewall industry for quite some time. While some vendors use their existing application identification mechanisms for this purpose, those require multiple packets in a flow to pass through the device before the classification can be made. Since most edge deployments use some form of NAT, switching an existing stateful connection to a different interface with a different NAT pool is impossible after the first packet. I always get a chuckle when reading those configuration guides that first tell you how to enable application-based routing and then promptly caution you against it due to NAT being used where NAT is usually used.

Our Threat Defense software takes a different approach, allowing common SaaS application traffic to be directed or load-balanced across specific interfaces even when NAT is used. In the spirit of leveraging the power of the broader Cisco Secure portfolio, we ported over a thousand cloud application identifiers from Umbrella,which are tracked by IP addresses and Fully Qualified Domain Name (FQDN) labels so the application-based routing decision can be made on the first packet. Continuous updates and inspection of transit Domain Name System (DNS) traffic ensures that the application identification remains accurate and relevant in any geography.

This application-based routing functionality can be combined with other powerful link selection capabilities to build highly flexible and resilient Software-Defined Wide Area Network (SD-WAN) infrastructures. Secure Firewall now supports routing decisions based on link jitter, round-trip time, packet loss, and even voice quality scores against a particular monitored remote application. It also enables traffic load-balancing with up to 8 equal-cost interfaces and administratively defined link succession order on failure to optimize costs. This allows a branch firewall to prioritize trusted WebEx application traffic directly to the Internet over a set of interfaces with the lowest packet loss. Another low-cost link can be used for social media applications, and internal application traffic is directed to the private data center over an encrypted Virtual Tunnel Interface (VTI) overlay. All these interconnections can be monitored in real-time with the new WAN Dashboard in Firewall Management Center.

Divide by Zero Trust

The obligatory inclusion of Zero Trust Network Access (ZTNA) into every vendor’s marketing collateral has become a pandemic of its own in the last few years. Some security vendors got so lost in their implementation that they had to add an internal version control system. Once you peel away the colorful wrapping paper, ZTNA is little more than per-application Virtual Private Network (VPN) tunnel with an aspiration for a simpler user experience. With hybrid work driving users and applications all over the place, a secure remote session to an internal payroll portal should be as simple as opening the browser – whether on or off the enterprise network. Often enough, the danger of carelessly implemented simplicity lies in compromising the security.

A few vendors extend ZTNA only to the initial application connection establishment phase. Once a user is multi-factor authenticated and authorized with their endpoint’s posture validated, full unimpeded access to the protected application is granted. This approach often results in shamingly successful breaches where valid user credentials are obtained to access a vulnerable application, pop it, and then laterally spread across the rest of the no-longer-secure infrastructure. Sufficiently motivated bad actors can go as far as obtaining a managed endpoint that goes along with those “borrowed” credentials. It’s not entirely uncommon for a disgruntled employee to use their legitimate access privileges for less than noble causes. The simple conclusion here is that the “authorize and forget” approach is mutually exclusive with the very notion of Zero Trust framework.

Secure Firewall Threat Defense 7.4 software introduces a native clientless ZTNA capability that subjects remote application sessions to the same continuous threat inspection as any other traffic. After all, this is what Zero Trust is all about. A granular Zero Trust Application Access (ZTAA – see what we did there?) policy defines individual or grouped applications and allows each one to use its own Intrusion Prevention System (IPS) and File policies. The inline user authentication and authorization capability interoperates with every web application and Security Assertion Markup Language (SAML) capable Identity Provider (IdP). Once a user is authenticated and authorized upon accessing a public FQDN for the protected internal application, the Threat Defense instance acts as a reverse proxy with full TLS decryption, stateful firewall, IPS, and malware inspection of the flow. On top of the security benefits, it eliminates the need to decrypt the traffic twice as one would when separating all versions of legacy ZTNA and inline inspection functions. This greatly improves the overall flow performance and the resulting user experience.

Let’s Decrypt

Speaking of traffic decryption, it is generally seen as a necessary evil in order to operate any DPI functions at the network layer – from IPS to Data Loss Prevention (DLP) to file analysis. With nearly all network traffic being encrypted, even the most efficient IPS solution will just waste processing cycles by looking at the outer TLS payload. Having acknowledged this simple fact, many organizations still choose to avoid decryption for two main reasons: fear of severe performance impact and potential for inadvertently breaking some critical communication. With some security vendors still not including TLS inspected throughput on their firewall data sheets, it is hard to blame those network operations teams who are cautious around enabling decryption.

Building on the architectural innovation of Secure Firewall 3100 Series appliances, the newly released Secure Firewall 4200 Series firewalls kick the performance game up a notch. Just like their smaller cousins, the 4200 Series appliances employ custom-built inline Field Programmable Gateway Array (FPGA) components to accelerate critical stateful inspection and cryptography functions directly within the data plane. This industry-first inline crypto acceleration design eliminates the need for costly packet traversal across the system bus and frees up the main CPU complex for more sophisticated threat inspection tasks. These new appliances keep the compact single Rack Unit (RU) form factor and scale to over 1.5Tbps of threat inspected throughput with clustering. They will also provide up to 34 hardware-level isolated and fully functional FTD instances for critical multi-tenant environments.

Those network security administrators who look for an intuitive way of enabling TLS decryption will enjoy the completely redesigned TLS Decryption Policy configuration flow in Firewall Management Center. It separates the configuration process for inbound (an external user to a private application) and outbound (an internal user to a public application) decryption and guides the administrator through the necessary steps for each type. Advanced users will retain access to the full set of TLS connection controls, including non-compliant protocol version filtering and selective certificate blocklisting.

Not-so-Random Additional Screening

Applying decryption and DPI at scale is all fun and games, especially with hardware appliances that are purpose-built for encrypted traffic handling, but it is not always practical. The majority of SaaS applications use public key pinning or bi-directional certificate authentication to prevent man-in-the-middle decryption even by the most powerful of firewalls. No matter how fast the inline decryption engine may be, there is still a pronounced performance degradation from indiscriminately unwrapping all TLS traffic. With both operational costs and complexity in mind, most security practitioners would prefer to direct these precious processing resources toward flows that present the most risk.

Lucky for those who want to optimize security inspection, our industry-leading Snort 3 threat prevention engine includes the ability to detect applications and potentially malicious flows without having to decrypt any packets. The integral Encrypted Visibility Engine (EVE) is the first in the industry implementation of Machine Learning (ML) driven flow inference for real-time protection within the data plane itself. We continuously train it with petabytes of real application traffic and tens of thousands of daily malware samples from our Secure Malware Analytics cloud. It produces unique application and malware fingerprints that Threat Defense software uses to classify flows by examining just a few outer fields of the TLS protocol handshake. EVE works especially well for identifying evasive applications such as anonymizer proxies; in many cases, we find it more effective than the traditional pattern-based application identification methods. With Secure Firewall Threat Defense 7.4 software, EVE adds the ability to automatically block connections that classify high on the malware confidence scale. In a future release, we will combine these capabilities to enable selective decryption and DPI of those high-risk flows for truly risk-based threat inspection.

The other trick for making our Snort 3 engine more precise lies in cooperation across the rest of the Cisco Secure portfolio. Very few cybersecurity practitioners out there like to manually sift through tens of thousands of IPS signatures to tailor an effective policy without blowing out the performance envelope. Cisco Recommendations from Talos has traditionally made this task much easier by enabling specific signatures based on actually observed host operating systems and applications in a particular environment. Unfortunately, there’s only so much that a network security device can discover by either passively listening to traffic or even actively poking those endpoints. Secure Workload 3.8 release supercharges this ability by continuously feeding actual vulnerability information for specific protected applications into Firewall Management Center. This allows Cisco Recommendations to create a much more targeted list of IPS signatures in a policy, thus avoiding guesswork, improving efficacy, and eliminating performance bottlenecks. Such an integration is a prime example of what Cisco Secure can achieve by augmenting network level visibility with application insights; this is not something that any other firewall solution can implement with DPI alone.

Light Fantastic Ahead

Secure Firewall 4200 Series appliances and Threat Defense 7.4 software are important milestones in our strategic journey, but it by no means stops there. We continue to actively invest in inference-based detection techniques and tighter product cooperation across the entire Cisco Secure portfolio to bring value to our customers by solving their real network security problems more efficiently. As you may have heard from me at the recent Nvidia GTC event, we are actively developing hardware acceleration capabilities to combine inference and DPI approaches in hybrid cloud environments with Data Processing Unit (DPU) technology. We continue to invest in endpoint integration both on the application side with Secure Workload and the user side with Secure Client to leverage flow metadata in policy decisions and deliver a truly hybrid ZTNA experience with Cisco Secure Access. Last but not least, we are redefining the fragmented approach to public cloud security with Cisco Multi-Cloud Defense.

The light of network security continues to shine bright, and we appreciate you for the opportunity to build the future of Cisco Secure together.

Source: cisco.com

Continue reading

Future-proof with Cisco Next-Gen Firewalls

We have seen an increase in the efforts to future-proof our technology, infrastructure, and our planet. Future-proof means we introduce or create a product or system that is unlikely to become obsolete or fail in the future.

We’ve seen this in how architects are designing bridges and skyscrapers, our global efforts in planet and ecosystem conservation, and in the technology sphere, especially in the efforts around security solutions. What we build now is what will enable the future generation to be the next leaders, thought leaders, and innovators.

Foundation of Futureproofing

At Cisco our purpose is to power an inclusive future for all. We have the technology, solutions, and motivation to bring communities together and drive change for everyone no matter where they live. For this change to take place, we have to offer customers a strong and secure foundation.

This foundation is centered on providing a network with consistent visibility, policy harmonization, and cloud management. Here at Cisco, we provide this level of security foundation through Cisco Next-Generation Firewalls (NGFW). Cisco is helping customers take control of their security landscape, and they can leverage their current Cisco investments to start turning their network infrastructure into additional control points and direct extension to have a complete security architecture.

Cisco’s Future-proof Security Platform

Customers can leverage the power of Cisco to turn their existing infrastructure into an extension of their firewall solution, which leads to a greater evolution of security everywhere they need it. Cisco can turn your customers’ entire network into an extension of the security architecture, experience world-class security controls, and have a unified policy with threat visibility. Let’s talk briefly about each of these points.

Security Architecture Extension

Cisco provides a trusted network security with the deepest set of integration between core networking functions and network security. Whether your customers are looking to get more from their existing network with Application-Centric Infrastructure (ACI) or Identity Services Engine (ISE) or extend their protection across the architecture quickly with advanced threat intelligence, there is a solution available that matches their needs.

World-class Security Controls

Security threats are becoming increasingly complex, but Cisco NGFW appliances can be deployed wherever your customers need them no matter if they are on-premise or across multiple clouds. By protecting customers from hidden threats, Cisco NGFW leverages dedicated hardware to inspect threats hidden in encrypted traffic while maintaining optimal performance.

Cisco offers many parallel solutions that work with Cisco NGFW. If you would like to learn more about these additional opportunities, please contact your Cisco Distribution, Partner, or Marketing account manager.

Unified Policy and Threat Visibility

When your customers invest in Cisco NGFW or update their existing security portfolio to include this solution, they will not only gain stronger security posture, but will also be set up with a future-ready management experience that can evolve with their network. This will help your customers deliver scalable controls across many devices quickly, reduce complexity, stay ahead of threats, and accelerate their security operations.

Tackling new opportunities

Whether you are discussing an upgrade with a customer to be more future-proof or showing how Cisco technology can better secure a customer’s IT landscape, there is a solution that can help them identify, overcome, and prevent challenges from impacting their IT goals. The future is now, and we must help customers look ahead with confidence in their security technology.

Source: cisco.com

Continue reading

Scalable Security with Cisco Secure Firewall Cloud Native

Today, companies invest in making their security controls scalable and dynamic to meet the ever-increasing demand on their network(s). In many cases, the response is a massive shift to Kubernetes® (K8s®) orchestrated infrastructure that provides a cloud-native, scalable, and resilient infrastructure.

This is where Cisco Secure Firewall Cloud Native (SFCN) comes in. It gives you the flexibility to provision, run, and scale containerized security services. Cisco Secure Firewall Cloud Native brings together the benefits of Kubernetes and Cisco’s industry-leading security technologies, providing a resilient architecture for infrastructure security at scale.

Figure 1 – Cisco Secure Firewall Cloud Native platform overview

The architecture depicted above shows a modular platform that is scalable, resilient, DevOps friendly, and Kubernetes-orchestrated. In the initial release of Cisco Secure Firewall Cloud Native, we have added support for CNFW (L3/L4 + VPN) in AWS. Future releases will add support for CNTD (L7) security and other cloud providers.

Read More: 100-490: Supporting Cisco Routing and Switching Network Devices (RSTECH)

Key capabilities of Cisco Secure Firewall Cloud Native include:

◉ Modular and scalable architecture

◉ Kubernetes orchestrated deployment

◉ DevOps friendly with Infrastructure-as-Code support (IaC)

◉ Data externalization for stateless services via a high-performance Redis™ database

◉ Multi-AZ, multi-region, and multi-tenant support

Figure 2 – Cisco Secure Firewall Cloud Native platform components

The architecture depicted above shows the Cisco Secure Firewall Cloud Native platform, which uses Amazon EKS, Amazon ElastiCache™, Amazon EFS with industry-leading Cisco VPN and L3/L4 security control for the edge firewall use-case. The administrator can manage Cisco Secure Firewall Cloud Native infrastructure using kubectl + YAML or Cisco Defense Orchestrator (CDO). Cisco provides APIs, CRDs, and Helm™ charts for this deployment. It uses custom metric and Kubernetes horizontal pod autoscaler (HPA) to scale pods horizontally.

Key components include:

◉ Control Point (CP): The Control Point is responsible for config validation, compilation and distribution, licensing, routes management. CP pods accept configuration from REST APIs, kubectl+YAML, or Cisco Defense Orchestrator.

◉ Enforcement Point (EP): CNFW EP pods are responsible for L3/L4 and VPN traffic handling and VPN termination.

◉ Redirector: Redirector pod is responsible for intelligent load balancing remote access VPN traffic. When the redirector receives a request, it contacts Redis DB and provides Fully Qualified Domain Name (FQDN) of the enforcement pods handling the least number of VPN sessions.

◉ Redis DB: The Redis database has information on VPN sessions. The redirector uses this information to enable smart load balancing and recovery. 

The following instance type is supported for each component.

Initial use-cases:

◉ Scalable Remote Access VPN architecture

◉ Scalable Remote Access VPN architecture with smart load balancing and session resiliency

◉ Scalable DC backhauls

◉ Multi-tenancy

◉ Scalable cloud hub

◉ Scalable edge firewall

Scalable Remote Access VPN architecture

Cisco Secure Firewall Cloud Native provides an easy way to deploy scalable remote access VPN architecture. It uses custom metrics and horizontal pod autoscaler to increase or decrease the number of CNFW Enforcement Points as needed. The Control Point controls configuration, routing, and Amazon Route 53™ configuration for the auto-scaled Enforcement Point.

Figure 3 – Scalable Remote Access VPN architecture

Traffic flow:

1. The remote VPN user sends a DNS query for vpn.mydomain.com. Amazon Route 53 keeps track of all CNFW nodes, and it has “A record” for each node with weighted average load balancing enabled for incoming DNS requests.

2. The remote VPN user receives “Elastic IP – EIP” of the outside interfaces of the CNFW node.

3. The remote VPN user connects to the CNFW node. Each node provides a separate VPN pool for proper routing.

Scalable Remote Access VPN architecture, with smart load balancing and session resiliency

Cisco Secure Firewall Cloud Native architecture with smart load balancing uses Amazon ElastiCache (Redis DB) to store VPN session information. Redirector node consults Redis database to perform load balancing based VPN session count, instead of weighted average load balancing.

The Control Point controls configuration, routing, redirector configuration, and Route 53 configuration for the auto-scaled enforcement point.

Figure 4 – Scalable Remote Access VPN architecture with smart load balancing and session resiliency

Traffic flow:

1. The remote VPN user sends a DNS query for vpn.mydomain.com, and vpn.mydomain.com points to the CNFW redirector.

2. The remote VPN user then sends the request to the redirector.

3. CNFW redirector periodically polls the Redis database (Amazon ElastiCache) to find out the FQDN of the Cisco Secure Firewall Cloud Native nodes with the least number of VPN endpoints. CNFW redirector provides FQDN of the least loaded CNFW node to the remote VPN user.

4. The remote user resolves FQDN, we automatically add “A” record for each CNFW enforcement point in Amazon Route 53.

5. The remote VPN user connects to the CNFW node that has the least number of VPN sessions.

Scalable DC backhauls

The autoscaled Enforcement Points can form a tunnel back to the data center automatically. Cisco provides a sample Kubernetes deployment to enable this functionality.

Figure 5 – Scalable DC backhaul

Multi-tenancy

This architecture provides multi-tenant architecture using cloud-native constructs such as namespace, EKS cluster, nodes, subnets, and security groups.

Figure 6 – Multi-tenancy

Scalable cloud hub

This architecture provides a scalable cloud architecture using CNFW, Amazon EKS, and other cloud native controls.

Figure 7 – Scalable cloud hub

Scalable edge firewall

This architecture provides a scalable architecture using CNFW, Amazon EKS, and other cloud-native controls.

Figure 8 – Scalable edge firewall

Licensing

Cisco Secure Firewall Cloud Native is available starting with ASA 9.16. This release brings CNFW (L3/L4 + VPN) security with Bring Your Own Licensing (BYOL), using Cisco Smart Licensing.

◉ Licenses are based on CPU cores used

◉ Supports multi-tenancy

◉ Unlicensed Cisco Secure Firewall Cloud Native EP runs at 100 Kbps

◉ AnyConnect license model is the same as the ASA AnyConnect license model

Source: cisco.com

Continue reading

Is Your Firewall Permitting and Denying the Correct Flows?

Two days prior, a large US city fell victim to a ransomware attack that disabled a sizable portion of the municipal network. I found myself on an airplane a few hours later.

Our first order of business was to quarantine potentially infected systems away from known-clean systems. In the interest of time, we installed a large Cisco ASA firewall into the datacenter distribution layer as a crude segmentation barrier. Once management connectivity was established, I was tasked with firewall administration, a job that is generally monotonous, thankless, and easy to scapegoat when things go wrong.

Long story short, the network was changing constantly. Applications were being moved between subnets, systems were being torn down and rebuilt, and I was regularly tasked with updating the firewall rules to permit or deny specific flows. After about 30 minutes, I decided to apply some basic automation. Managing firewall configurations using Python scripts is powerful but not particularly new or interesting, so I won’t focus on that aspect today.

Instead, consider the more difficult question. How do you know that your firewall is permitting and denying the correct flows? Often times, we measure the effectiveness of our firewall by whether the applications are working. This is a good measure of whether the firewall is permitting the desirable flows, but NOT a good measure of whether the firewall is denying the undesirable flows. Answering this question was critical to our incident response efforts at the customer site.

How would you solve this problem?

I decided to use the `packet-tracer` command built into the ASA command line. The command supports native `xml` formatting, which makes it easy to parse into Python data structures. Using Python parlance, the output contains a list of dictionaries, each one describing a phase in the ASA processing pipeline. Stages might include an ACL check, route lookup, NAT, QoS, and more. After the phase list, a summary dictionary indicates the final result.

ASA1#packet-tracer input inside tcp 10.0.0.1 50000 192.168.0.1 80 xml
<Phase>
  <id>1</id>
  <type>ROUTE-LOOKUP</type>
  <subtype>Resolve Egress Interface</subtype>
  <result>ALLOW</result>
  <config/>
  <extra>found next-hop 192.0.2.1 using egress ifc management</extra>
</Phase>
<Phase>
  <id>2</id>
  <type>ACCESS-LIST</type>
  <subtype/>
  <result>DROP</result>
  <config>Implicit Rule</config>
  <extra>deny all</extra>
</Phase>
<result>
  <input-interface>UNKNOWN</input-interface>
  <input-status>up</input-status>
  <input-line-status>up</input-line-status>
  <output-interface>UNKNOWN</output-interface>
  <output-status>up</output-status>
  <output-line-status>up</output-line-status>
  <action>DROP</action>
  <drop-reason>(acl-drop) Flow is denied by configured rule</drop-reason>
</result>

Now, how to automate this? I decided to use a combination of Python packages:

1. Nornir, a task execution framework with concurrency support
2. Netmiko, a library for accessing network device command lines

The high-level logic is simple. On a per firewall basis, define a list of `checks` which contain all the inputs for a `packet-tracer` test. Each check also specifies a `should` key which helps answers our original business question; should this flow be allowed or dropped? This allows us to test both positive and negative cases explicitly. Checks can be TCP, UDP, ICMP, or any arbitrary IP protocol. The checks can also be defined in YAML or JSON format for each host. Here’s an example of a `checks` list for a specific firewall:

---
checks:
  - id: "DNS OUTBOUND"
    in_intf: "inside"
    proto: "udp"
    src_ip: "192.0.2.2"
    src_port: 5000
    dst_ip: "8.8.8.8"
    dst_port: 53
    should: "allow"
  - id: "HTTPS OUTBOUND"
    in_intf: "inside"
    proto: "tcp"
    src_ip: "192.0.2.2"
    src_port: 5000
    dst_ip: "20.0.0.1"
    dst_port: 443
    should: "allow"
  - id: "SSH INBOUND"
    in_intf: "management"
    proto: "tcp"
    src_ip: "fc00:192:0:2::2"
    src_port: 5000
    dst_ip: "fc00:8:8:8::8"
    dst_port: 22
    should: "drop"
  - id: "PING OUTBOUND"
    in_intf: "inside"
    proto: "icmp"
    src_ip: "192.0.2.2"
    icmp_type: 8
    icmp_code: 0
    dst_ip: "8.8.8.8"
    should: "allow"
  - id: "L2TP OUTBOUND"
    in_intf: "inside"
    proto: 115
    src_ip: "192.0.2.1"
    dst_ip: "20.0.0.1"
    should: "drop"
...

Inside of a Nornir task, the code iterates over the list of checks, assembling the proper `packet-tracer` command from the check data, and issuing the command to the device using Netmiko. Note that this task runs concurrently on all firewalls in the Nornir inventory, making it a good fit for networks with distributed firewalls. Below is a simplified version of the Python code to illustrate the high-level logic.

def run_checks(task):
    # Iterate over all supplied checks
    for chk in checks:
        # Build the string command from check details (not shown)
        cmd = get_cmd(chk)
        # Use netmiko to send the command and collect output
        task.run(
            task=netmiko_send_command,
            command_string=cmd
        )

Behind the scenes, the code transforms this XML data returned by the ASA into Python objects. Here’s what that dictionary might look like. It contains two keys: `Phase` is a list of dictionaries representing each processing phase, and `result` is the final summarized result/

{
  "Phase": [
    {
      "id": 1,
      "type": "ROUTE-LOOKUP",
      "subtype": "Resolve Egress Interface",
      "result": "ALLOW",
      "config": None,
      "extra": "found next-hop 192.0.2.1 using egress ifc management"
    },
    {
      "id": 2,
      "type": "ACCESS-LIST",
      "subtype": None,
      "result": "DROP",
      "config": "Implicit Rule",
      "extra": "deny all"
    }
  ],
  "result": {
    "input-interface": "UNKNOWN",
    "input-status": "up",
    "input-line-status": "up",
    "output-interface": "UNKNOWN",
    "output-status": "up",
    "output-line-status": "up",
    "action": "DROP",
    "drop-reason": "(acl-drop) Flow is denied by configured rule"
  }
}

In the interest of brevity, I won’t cover the extensive unit/system tests, minor CLI arguments, and dryrun process in this blog. Just know that the script will automatically output three different files. I used the new “processor” feature of Nornir to build this output. Rather than traversing the Nornir result structure after the tasks have completed, processors are event-based and will run at user-specified points in time, such as when a task starts, a task ends, a subtask starts, a subtask ends, etc.

One of the output formats is terse, human-readable text which contains the name of the check and the result. If a check should be allowed and it was allowed, or if a check should be dropped and it was dropped, is it considered successful. Any other combination of expected versus actual results indicates failure. Other formats include comma-separated value (CSV) files and JSON dumps that provide even more information from the `packet-tracer` result. Here’s the `terse` format when executed on two ASAs with hostnames `ASAV1` and `ASAV2`:

ASAV1 DNS OUTBOUND -> FAIL
ASAV1 HTTPS OUTBOUND -> PASS
ASAV1 SSH INBOUND -> PASS
ASAV1 PING OUTBOUND -> PASS
ASAV1 L2TP OUTBOUND -> PASS
ASAV2 DNS OUTBOUND -> PASS
ASAV2 HTTPS OUTBOUND -> FAIL
ASAV2 SSH INBOUND -> PASS
ASAV2 PING OUTBOUND -> PASS
ASAV2 L2TP OUTBOUND -> PASS

For the visual learners, here’s a high-level diagram that summarizes the project’s architecture. After Nornir is initialized with the standard `hosts.yaml` and `groups.yaml` inventory files, the host-specific checks are loaded for each device. Then, Nornir uses Netmiko to iteratively issue each `packet-tracer` command to each device. The results are recorded in three different output files which aggregate the results for easy viewing and archival.

If you’d like to learn more about the project or deploy it in your environment, check it out here on the Cisco DevNet Code Exchange. As a final point, I’ve built Cisco FTD support into this tool as well, but it is experimental and needs more in-depth testing. Happy coding!

Continue reading

Scaling Application Security with ITD

Ready to scale your enterprise beyond limits?  How about slashing a whole layer of datacenter infrastructure, saving piles of cash in the process?  Or perhaps you’re interested in simplifying your enterprise while adding features, or trying to speed things up without spending money.  Sound too good to be true?  Well, thanks to a new technology from Cisco, you can have your cake and eat it, too.

Cisco Intelligent Traffic Director (ITD) is poised to disrupt data center load balancing. Combined with best-in-class products, such as Imperva SecureSphere, organizations can deploy and manage massively scalable applications securely with unprecedented ease and cost effectiveness.

What is ITD?

Cisco recently released a new feature, Intelligent Traffic Director (ITD) for the Nexus 7k switches that promises to be a disrupting force in the world of load balancing.  There has been an exponential growth in data traffic in the recent years leading to a growth in the deployment of network service appliances in enterprise, datacenter and cloud environments. To address the corresponding business needs, network switch and router architecture has evolved to support multi-terabit capacity. However, service appliance capacity remained limited to few gigabits, an order of magnitude far below switch capacity.

Cisco Intelligent Traffic Director (ITD) is an innovative solution that tries to bridge performance gap between the switch and service appliance(s). It allows customers to deploy service appliance(s) from any vendor with no network or topology changes. With a few simple configuration steps on a Cisco Nexus 7000 / 7700 series switch, customers can create a service appliance cluster and deploy multiple appliance(s) to scale service capacity with ease. The servers or appliance(s) do not have to be directly connected to the Nexus switch.

Application Security

Gartner published a paper called Web Application Firewalls are Worth the Investment for Enterprises in Feb, 2014 that makes the case that “Firewalls and intrusion prevention systems don’t provide sufficient protections for most public-facing websites or internal business-critical and custom Web applications.” Gartner advises enterprises to use a Web Application Firewall (WAF) to protect critical external and internal applications from attacks and threats.

Like other service appliances, a WAF appliance benefits from ITD’s ability to manage large scale traffic loads. Imperva SecureSphere WAF works with ITD, and the combination provides highly scalable application security.

I mention SecureSphere because Imperva was positioned as the only Leader in the Gartner 2014 Magic Quadrant for Web Application Firewalls. Some key capabilities of the SecureSphere WAF are:

◉ Block attacks with laser precision

Accuracy is critical with application security. If you have false positives, you block customers; if you have false negatives, you let the bad guys in.

◉ World-renowned application security research

Security is constantly evolving. To get ahead and stay ahead in the continuous fight against threats, Imperva has a dedicated security research team, the Application Defense Center (ADC), which provides regular signature and policy updates, and up-to-date threat intelligence for Imperva SecureSphere.

◉ Shut down malicious sources and bots

Imperva’s ThreatRadar Reputation Services help detect bad actors using IP reputation feeds of known malicious sources, anonymizing services, phishing URLs, TOR (“The Onion Router”), as well as IP geolocation data.

◉ Stop application DDOS and business logic attacks

Business logic attacks include things like posting comment spam in forums and message boards, scraping web content, and disabling access to your website. All of this can reduce competitive edge, frustrate customers, and damage reputation.

◉ Instantly patch website vulnerabilities

It takes organizations an average of 6 months to patch an application vulnerability once it’s discovered. SecureSphere integrates with vulnerability scanners to virtually patch applications. This allows businesses to stay protected, and fix the vulnerability on their own timeline, thus reducing the window of exposure and the associated costs.

◉ Gain forensics insights with customizable reports

Graphical reports enable organizations to quickly analyze security threats and meet compliance requirements.

◉ Speed up deployment without risk

SecureSphere protects applications without impacting performance and without requiring extensive network changes. It offers flexible inline, non-inline, and proxy deployment options that meet organizations’ diverse requirements. SecureSphere’s Fail-Open capabilities combined with unique, transparent bridge mode saves time and labor with drop-in deployment that requires no changes to existing applications or network devices, and delivers multi-Gigabit throughput while maintaining sub-millisecond latency.

Scaling Application Security

Using ITD in VIP Mode to load balance provides a fast and economical way for organizations to provide highly scalable and available infrastructure.  By leveraging ITD, an enterprise can deploy a single IP address (the VIP), which is then load balanced across many SecureSphere WAFs, with each one protecting the back-end webservers. This is done right from the 7K – There’s no need for an external load balancer in the middle.

Why is this better than other Load Balancers?

By combining Cisco ITD and SecureSphere’s advanced capabilities to monitor and secure HTTP traffic, several key advantages are apparent:

◉ Eliminates the need for external load balancers, freeing up large amounts of budget and resources

◉ You get the advantages of a proxy-type load balancer (1 single VIP represents many webservers), but still get ‘fail-open’ bridges on WAFs

◉ ITD proxies traffic without interfering with the TCP Source IP Address , allowing SecureSphere to leverage the source IP, User and Session details for blocking and alerting.

◉ To work with SecureSphere, ITD requires no modification to HTTP Headers (e.g., X-Forwarded-For), which can break applications and slow down traffic

What does this mean for the future of high performance WAF deployments?

By teaming up the Cisco Nexus 7K with SecureSphere WAFs, organizations can cost effectively deploy scalable, high-availability  WAF farms to handle large amounts of traffic to webservers.  As the web traffic increases, WAFs can be seamlessly added to the pool to scale up with the enterprise. Since every port on the 7K can be used as a load balancer this provides the potential to scale up to multi-terabits of throughput to a SecureSphere WAF cluster.

Continue reading

What is the difference between Cisco ASA 5505 and 5510 series firewalls?

There are many differences between the ASA 5505 and the 5510. 5505 is suitable for small offices and home networks while the 5510 is more suitable for bigger networks.

For guys interested in Cisco study materials “Practice Exams, Syllabus Details, Sample Questions,… etc” I recommend  www.nwexam.com/cisco

Continue reading