Cisco and IBM: Solving Customer Challenges through the Power of Partnerships

Complexity is one of the top challenges our customers face today. CISOs not only want to enable their teams to detect and respond to threats faster, they want to simplify workflows and streamline operations at the same time. In our annual CISO surveys, we’ve been seeing a trend toward vendor consolidation, which tells us CISOs are looking for ways to make their solutions simpler.

Vendors typically work in siloes to solve these kinds of challenges. But at Cisco, we believe we can achieve more through collaboration. That’s why we’ve been working in partnership with IBM Security to provide joint customers an in-depth, end-to-end defense strategy while simplifying their vendor relationships.

The average organization juggles 45 different security vendors. Leveraging the breadth of Cisco and IBM’s security portfolios allows our customers to drastically reduce that number of vendors while still using best-in-class products. The reduction in vendor surface creates more than just technical efficiencies. By consolidating vendor relationships, customers can maximize their buying power through vehicles like Enterprise Agreements, as well as simplify contract management and support cases.

Leveraging Cisco and IBM strengths

At Cisco, we believe we have excellent technologies to help customers prevent threats to their businesses, and with products like Cisco Threat Response, we even speed up various elements of the technical response. With IBM, we have focused our initial integrations on QRadar and Resilient product lines to help customers further prioritize threats and better assist with their response both at a technical and business level.

Let’s say you had an insider attack. The Cisco/IBM integrated solutions enable faster investigations of suspicious behaviors that could compromise credentials or systems. For example:

◉ Cisco Stealthwatch looks for behavioral indicators of compromise in activity traversing the network, including encrypted traffic without the need to decrypt the data. IBM QRadar builds on that detection, as well as other Cisco solutions like Firepower Threat Defense, to correlate events from network traffic and logs to help security teams quickly prioritize threats.

◉ Cisco Identity Services Engine helps you associate malicious activity with specific user credentials, and you can quarantine the user and lock down network access right from QRadar.

Responding to the attack is not just about gathering the information. You also need to understand how the business responds to the threat — is this something that needs public release of information, do you need to involve law enforcement, will this result in employee termination, and so on. To help operationalize incident response, you can use investigation results from all the integrated solutions to create a report in Resilient.

Innovative solutions to address customer needs

Many of the Cisco/IBM collaborative solutions are unique for the industry, and they’re based on lessons Cisco and IBM have learned from our extensive customer bases and our threat intelligence teams, Cisco Talos and IBM X-Force.

To make breach response more efficient, earlier this year we integrated Cisco Advanced Malware Protection (AMP) for Endpoints with QRadar and IBM Resilient SOAR. These integrations enable security teams to do things like:

◉ Receive AMP for Endpoints telemetry directly in QRadar for a consolidated view of events across endpoints and ability to search, analyze, and correlate them.

◉ Pull AMP for Endpoints data into Resilient to investigate events, automatically bring the results into an incident, and get more details on detected threats, then quarantine detected malicious files.

Since threats evolve quickly, defenses can’t rely on one mechanism alone. We work together in various other ways to help you detect unknown threats like ransomware or speed up response time. For instance:

◉ Resilient customers can submit suspicious malware samples to Cisco Threat Grid to get detonated, with the hashes sent back to Resilient. This can stop malware or ransomware before it ever reaches the end user.

◉ IBM Resilient users can query Cisco Umbrella for a list of blocked domains, save them to a data table, and delete or add new ones — preventing end users from accessing risky internet connections.

We’re listening to your feedback

Because we’re invested in the results that this collaboration can produce for our customers, we’re continuously expanding and improving our integrated solutions based on your feedback. The latest examples are enhancements made to the Firepower Threat Defense and QRadar SIEM integration, which accelerate threat investigation and remediation by correlating events across network, applications, and users.

Our customers wanted to dig deeper than the top-level summaries previously available. We listened — and the new, enhanced Firepower app that we’re releasing provides a higher level of detail in the integrated dashboard.

With Firepower Threat Defense and QRadar, you can answer questions like:

◉ Which hosts in my network are potentially compromised?

◉ Which hosts are known to be compromised?

◉ What malware is most often observed in my network?

◉ Which hosts have sent the most malware?

This is just one of the new enhancements and expansions we’ve been making as part of our alliance, and more are on the roadmap. By reducing complexities, increasing visibility, and improving threat defenses, our collaboration is improving outcomes in areas that are top of mind for our customers.

Continue reading

The Circus is Coming to Town and Why You Should Stay Away

We are entering the integrated era

You’ve probably noticed the recent headlines of a few one-trick ponies getting together to form their own three ring circus.  These events underscore a paradigm shift that is underway – the security world is entering the integrated era.  Nowadays, customers want comprehensive solutions with seamless integrations across their endpoint, cloud and email security programs.  Standalone vendors are just now realizing this and are scrambling to partner up with one another to satisfy the market’s demands.  As an ambassador of Cisco’s integrated security portfolio, I would like to formally address these three vendors by saying: Congratulations – you finally realized what your customers need.  But let me issue a caution: you’re going about it all wrong!

The new reality

A lot of things have fundamentally changed how users work today.  Applications, data, and user identities have moved to the cloud, branch offices connect directly to the internet, and many users work off-network.  This has given users an unprecedented ability to access, create, and share information online, which has concomitantly increased the risk of them exposing sensitive information.  Additionally, advanced attackers have matured beyond the traditional defense models that rely on a patchwork of point solutions – they no longer rely on a single attack technique, and instead use multipronged approaches that may combine email phishing, fileless malware, and malicious websites.

Practitioners must protect against internet-born threats, phishing attacks, have control and visibility into their endpoints, and be able to quickly respond to incidents that arise – that’s a tall order for many reasons.  First, the average enterprise has 75 security tools running in its environment.  Second, most of these tools don’t communicate with one another.  The sheer volume and complexity associated with responding to this information overload while simultaneously trying to correlate disparate datasets across multiple disaggregated sources is daunting. Security teams often find themselves drowning in a deluge of data and facing unmanageable workloads that make it nearly impossible for them to do their jobs well.  This leaves them feeling overwhelmed and unmotivated, and further undermines cyber risk management by increasing the likelihood of them not responding to the threats that matter most fast enough, or missing them altogether.  Additionally, 79% of respondents in Cisco’s 2019 CISO Benchmark Report said it was somewhat or very challenging to orchestrate alerts from multiple vendor products.  To paraphrase, this implies that 79% of the security community does not view ‘Frankensteining’ multiple point products together as a solution to their problems!

Now, don’t get me wrong – I love animals, am an avid fan of the Ringling Brothers, and think that one-trick ponies getting together is abso-friggin-lutely adorable.  But frantically moving from console to console while correlating disparate threat data is a myopic approach that doesn’t solve the underlying problem.  The inconvenient reality is that there always are and always will be threats to respond to, and with attack surfaces continually growing, the problem is only getting more complex.  The only way to stand up to advanced attacks is by taking a highly integrated architectural approach to security.

Successful security integrations require a minimum of these 5 things – everything else will fail sooner or later:

1. Comprehensive coverage – Platforms that cover major threat vectors, like web and email security, span across all endpoints, and integrate with network security tools.

2. Intelligence sharing & automated response – Actionable threat intelligence that is shared amongst all incorporated solutions for data enrichment purposes, so that responses are automated (rather than ‘suggested’) and if a threat is seen once anywhere, it is immediately blocked everywhere.

3. Centralization – Features and capabilities that allow users to consolidate information from multiple solutions on a single pane from which they can dynamically pull observables about unknown threats and kick off investigations.

4. Improved time to remediation (TTR) – Proven ability to significantly reduce TTR to enable SecOps teams to work more quickly and efficiently, thus decreasing likelihood of an incident becoming a full-blown breach.

5. Reliable integration – Integrations that wouldn’t disappear because one company changed their mind regarding their strategic direction or got acquired.

Security that works together for the integrated era

Fortunately, at Cisco, we foresaw this paradigm evolution years ago and invested in building a seamlessly integrated security platform across our SIG, email security, endpoint security, and advanced sandboxing solutions, along with our network security tools like IPS and NGFW.  Backed by Cisco Talos – the largest non-governmental threat intelligence organization on the planet – real-time threat intelligence is shared amongst all incorporated technologies to dynamically automate defense updates so that if a threat is seen once, it is blocked everywhere.  Teams can also kick off threat investigations and respond to incidents from a single console via Cisco Threat Response (CTR), which is a tool that centralizes information to provide unified threat context and response capabilities.  In other words, Cisco’s integrated security portfolio, underscored by Threat Response streamlines all facets of security operations to directly addresses security teams’ most pressing challenges by allowing them to:

◈ Prioritize – SecOps teams can pinpoint threat origins faster and prioritize responding to the riskiest threats in their environment.

◈ Block more threats – Threat Response automates detection and response, across different security tools from a single console, which allows SecOps team to operate more efficiently and avoid burnout.

◈ Save time – Threat intelligence from Talos is shared across all integrated tools, so that you can see a threat once and block it everywhere.

As the largest cybersecurity vendor in the world, only Cisco has the scale, breadth and depth of capabilities to bring all of this together with Threat Response – and best of all, it’s FREE!  Cisco Threat Response is included as an embedded capability with licenses for any tool in Cisco’s integrated security architecture.

Let’s compare the following two scenarios:

Scenario 1 – A patchwork of non-integrated security tools:

Security teams must review alerts from multiple solutions, correlate disparate datasets from various disaggregated sources investigate each threat.  They triage and assign priorities, perform complex tasks with tremendous urgency with the goal of formulating an adequate response strategy based on situational awareness and threat impact, potential scope of compromise, and the criticality of damage that can ensue.  This process is laborious, error-prone, and time-consuming, requiring an analyst to manually swivel through multiple consoles quickly.  We’ve run internal simulations, in which all of this on average takes around 32 minutes.  SOC analysts are left drained and high-severity threats risk being overlooked.

Scenario 2 – Cisco’s integrated security platform:

Security teams see an aggregated set of alerts from multiple Cisco security tools in Threat Response’s interface.  The alerts are automatically compared against intelligence sources, SOC analysts can visualize a threat’s activities across different vectors, kick off an investigation, pinpoint the threats origin, and take corrective actions immediately – all from a single console.  In our internal simulations this took 5 minutes.

Bottom line: Cisco’s integrated portfolio with Threat Response brings the time it takes to deal with a potential threat down from 32 minutes to 5 minutes, which is 85% faster than the non-integrated patchwork scenario!

Continue reading

Secure Multi-Tenancy Part 2: Going Multi-Instance

Requirements Overview

In the previous blog post, we went over the common requirements for partitioning a single physical security appliance into multiple virtual firewalls. We talked about how this logical separation brings a lot of complexity into environments where true data and management plane isolation between different tenants is not required. It was further established that even the full isolation requirements are not truly addressed by the existing virtual firewall solutions. A single tenant can easily consume a disproportionally large amount of shared CPU and memory resources, thus impacting everyone else on the same physical appliance. As such, there was a clear need for a better solution to this problem.

A multi-tenancy solution for Cisco Firepower Threat Defense (FTD) had to overcome these constraints. The goal was to address the management simplification and routing separation requirements through different features. We wanted to concentrate specifically on management and traffic separation in a multi-tenant environment. Our virtual firewall instances would be completely isolated from each other in terms of CPU and memory resources, such that no individual tenant could exceed its allocation and impact someone else on the same Firepower appliance. This approach would extend to management sessions, where each tenant could use a separate Firepower Management Center (FMC) instance and push configuration changes completely independently. Last but not least, we wanted to eliminate the disparity in feature support when running virtual firewalls. If we support something within a single application, the same support should extend to a multi-tenant deployment going forward. These were very ambitious goals, but we managed to come up with an elegant solution.

Sizing Expectations

Before diving deeper into our solution, I want to say a few words about virtual firewall scalability. Traditional stateful firewall platforms support up to several hundreds of virtual contexts. However, this scale obviously comes with a large degree of resource sharing. If a security appliance is capable of delivering 50Gpbs of basic stateful firewalling, dividing it into 200 security contexts yields about 250Mbps of average throughput per tenant. This may be suitable for some environments, but then one should also consider packet-per-second (PPS) rates. Assuming a relatively powerful stateful firewall that does around 20 million PPS in the best case scenario, it comes down to only about 100 thousand PPS per each of the 200 tenants – a level easily exceeded by a single server in a modern data center.

As we start looking at more advanced firewall features, such as Intrusion Prevention Services (IPS), URL filtering, file and malware inspection, cloud sandboxing, and especially encrypted traffic inspection, performance implications become even more pronounced. There is frequently an order of magnitude of difference when comparing a threat-centric security application to a basic stateful firewall running on the same hardware. Getting a little over 20Mbps of threat-protected throughput per tenant is rarely acceptable, especially when migrating from a classic firewall feature set. If a tenant required 250Mbps of protected throughput before transitioning to a threat-centric product, their needs would not change simply because the firewall has to spend more cycles on much deeper inspection after the migration. As such, the expectations for tenant scale will be significantly reduced when migrating from Cisco ASA (Adaptive Security Appliance) and similar classic stateful firewalls to FTD.

Firepower Multi-Instance Capability

Firepower 4100 and 9300 appliances were meant to deliver multi-service security capabilities by design. The currently support ASA, FTD, and Radware Virtual DefensePro applications. When we looked at all of the possible multi-tenancy solutions for FTD, I immediately thought of extending the physical platform capabilities to host multiple instances of security applications on a single security module — this is how the multi-instance term was coined. Leveraging a common hypervisor for this did not seem very exciting, so a Docker container was picked as a form factor of choice. This approach leverages a proven application virtualization framework and enables future portability beyond the hardware appliances. Container-based FTD instances on Firepower 4100 and 9300 appliances would become available first, but we envision building a similar ASA package with mix-and-match capabilities in the future.

Given our desire to provide complete data plane and management plane separation, each FTD instance would get a completely independent CPU, memory, and disk reservation. Unequally sized instances can be deployed, and the firewall administrator gets to decide a CPU core allocation for each instance – memory and disk are sized automatically based on this assignment. This is important to ensure that a single FTD instance cannot impact any other instances running on the same module or appliance. Given a finite number of available CPU cores, it obviously puts a constraint on the maximum total number of instances that can reside on a particular Firepower appliance. As we had established earlier, a total tenant count with a threat-centric security application is significantly lower than with a basic stateful firewall on the same hardware platform. As such, the full resource separation requirement is more important to most customers than scaling to hundreds of oversubscribed virtual firewalls.

Each FTD container behaves like a separate firewall with its own software image. This means that individual instances can be upgraded, downgraded, or rebooted completely independently. One would no longer have to stand up a separate physical appliance to test software upgrades on a single tenant. Furthermore, each FTD instance would have dedicated management CPU cores to ensure no contention between different tenants during configuration deployment, event generation, and monitoring. An administrator can even assign different FTD containers on a single blade to be managed by different FMC appliances. Most importantly, each instance would support the same complete feature set as a full-module FTD application – no more exceptions for multi-tenancy.

In order to support the new multi-instance capability, Firepower 4100 and 9300 platforms would introduce several new network interface assignment models. Physical and Etherchannel interfaces can be shared between two or more instances or assigned exclusively to a single FTD container. Furthermore, one would gain an ability to create VLAN subinterfaces directly on the chassis Supervisor and assign them to instances on the same shared or unique basis. Needless to say, the instances would be able to communicate to each other directly on the shared data interfaces or VLAN subinterfaces – this includes supporting inter-instance multicast connectivity for dynamic routing. A management interface can be shared across multiple FTD containers as well, but inter-instance communication would be blocked in order to support the fully isolated model.

The following figure illustrates a hypothetical deployment where a single Firepower module runs a set of unequally sized ASA and FTD instances with a combination of shared and unique interfaces:

Looking Forward

The Firepower multi-instance capability definitely represents a unique and novel approach to deploying secure multi-tenancy. I am obviously very excited about this idea, and there are many new directions that it opens for us and our customers. As we are finalizing this feature for the public release, feel free to leave a comment about what additional details you would like me to cover in the next post on this topic.

Continue reading

Security Multi-Tenancy Part 1: Defining the Problem

Pre-Virtual Virtual Firewalls

Nowadays, everyone likes to talk about network function virtualization. Most security vendors build their firewall products to run on a few popular hypervisors. However, the “virtual firewall” term predates this virtualization craze. Many firewall administrators use this nomenclature to describe an ability to create multiple virtual partitions or contexts within a single physical security appliance. Each of these virtual firewalls has its own configuration, stateful connection table, and management capabilities. However, they may not be as independent or isolated as one would assume – more on this later. Even though Cisco Adaptive Security Appliance (ASA) software supported virtual firewalls with multiple-context mode for quite some time, we deliberately delayed similar functionality in our threat-centric Firepower Threat Defense (FTD) product in order to get it right. As any decent engineer would tell you, getting the right solution starts with fully understanding the problem. Namely, why do our security customers deploy virtual firewalls?

Understanding Use Cases

As it turns out, not all customers deploy multiple security contexts specifically for multi-tenancy. Some look for routing table separation, where each virtual firewall represents a separate Virtual Routing and Forwarding (VRF) domain. This functionality comes in handy especially when trying to protect several internal organizations with overlapping IP spaces. Other firewall administrators leverage multiple-context mode to separate and simplify policy management across different domains. Instead of looking at a single flat policy, they break it up into smaller chunks based on individual network segments. This may also involve management separation, where administering individual security contexts is delegated to other organizations. A common example here is a big college where several departments manage their own networks and configure individual virtual firewalls on a shared physical appliance at the extranet edge. Other customers go even deeper and require complete traffic processing separation between different tenants or network segments. For instance, one typically does not want their production applications to be affected by some traffic from a lab environment. As these requirements add up, it becomes clear how most existing firewall multi-tenancy solutions come apart at the seams.

Reality Check

There are several operational considerations that need to be taken into account when deploying virtual firewalls.  All security contexts on a single appliance run the same software image, so you cannot test upgrades on a limited number of tenants. Similarly, they all live or die together – rebooting just one is not possible. When it comes to features, you need to keep track of which are not supported in the virtual firewall mode. Often enough, these subtle nuances come up when you are already so far down the implementation path that turning back is either expensive or completely impossible. But wait, there is more!

While virtual firewalls can certainly be used for routing or policy domain separation, it comes with a lot of unnecessary complexity. One needs to create firewall contexts, assign different interfaces, configure them all independently, and then keep switching back and forth in order to manage policies and other relevant configuration. If you need a single access policy across all of your contexts, it must be independently programmed into each virtual firewall. Luckily, features like VRF help in avoiding multiple-context mode by enabling routing domain separation only. When it comes to policy simplification, some of my customers found managing multiple virtual firewalls too cumbersome, converged back into a single security context, and leveraged Security Group Tags (SGTs) to significantly reduce the rule set. Unless you indeed require complete separation between tenants, it makes very little sense to deploy virtual firewalls.

When it comes to management separation, multiple-context mode seems like a perfect fit. After all, each tenant gets their own firewall to play with, all without impacting anyone else. Or is that really true? Even though each virtual firewall has its own independent configuration, they all run within a single security application on a shared physical device. In most implementations, it means that the management plane is shared across all of the virtual contexts. If one tenant is pushing a lot of policy changes or constantly polling for connection information, this will inevitably impact every other virtual firewall that runs on the same device. However, the real problem lies within the shared data plane.

Despite the perceived separation, all virtual firewalls ultimately run on shared CPU, memory, and internal backplane resources. Even when assigning different physical interfaces to different security contexts, all of the traffic typically converges at the ingress classification function in the CPU. While one sometimes can configure maximum routing or connection table sizes on per-context basis, it still does not limit the amount of network traffic or CPU resources that each particular tenant consumes. In order to classify packets to a particular virtual firewall, the system must spend CPU cycles on processing them first. If a particular tenant is getting a lot of traffic from the network, it can consume a disproportionally large amount of system CPU resources even if this traffic is later dropped by a rate-limiter. As such, there is never a guarantee that one virtual firewall does not grow too big and impact every other security context on the same box. I have seen many cases where firewall administrators were caught completely unaware by this simple caveat. Not being a problem with any specific vendor, this is just how most virtual firewalls are implemented today.

Thinking Outside the Contexts

After looking at the use cases and analyzing challenges with existing virtual firewall implementations, I knew that our approach to implementing multi-tenancy in FTD must fundamentally change. An ideal solution would provide complete management and traffic processing separation across all tenants, so one virtual firewall truly cannot impact anyone else on the same box. This separation should extend to independent software upgrades and reloads. At the same time, all of the available FTD features should always be supported when implementing virtual firewalls. Not only must it simplify the experience for an end user, but also significantly cut down on both development and testing times.

While these may have seemed like impossible requirements, I had a really cool idea on how we can get there for our customers. This novel approach builds on the multi-service capabilities of our Firepower platforms as well as such developing trends as application containerization.

Continue reading