When is a firewall, not a firewall? Not to be cute or rhetorical, it’s a serious question because the devices that masquerade as firewalls today provide a lot more than just an access control on the edge of your network(s). Some of our influential analyst friends dubbed the category next generation firewall (NGFW), but that criminally undersells the capabilities of the device.
The “killer app” for NGFW remains being able to enforce security policies based on applications (and even functions within applications), as opposed to just ports and protocols. This technology has matured since we last covered the enterprise firewall space in Understanding and Selecting an Enterprise Firewall. Virtually all firewall devices (except very low end gear) being deployed now have the ability to enforce policies on applications in some way, shape or form. Yet, as with most new technologies, having the functionality doesn’t mean the new capabilities are being used particularly well. Using application-aware policies is a different way of thinking about network security and that’s going to necessarily take time for the broader market to adapt to.
At the same time, many of the network security vendors continue to integrate their previously separate FW and IPS devices onto a common architecture/platform. They’ve also systematically added network-based malware detection and some light identity and content filtering/protection features. If this sounds like UTM, that shouldn’t be surprising since the product categories (UTM and NGFW) provide very similar functionality, just in different ways under the hood.
Given this long awaited consolidation, we find the network security market in a state of evolution. Besides these additional capabilities integrated onto the NGFW device, we are seeing bigger chassis-based models, smaller branch office devices and even virtualized and cloud-based form factors to extend these capabilities to every point in the network. We are seeing greater levels of threat intelligence integration to provide the ability to block current threats.
Thus it makes sense for us to revisit our research from a couple of years ago since the drivers for your selection and procurement have changed over the past few years. Yet, as we mentioned above, these devices are a lot more than firewalls. As such, we will use the horribly pedestrian Network Security Gateway moniker to describe what network security devices look like moving forward. Thus we’re pleased to launch the Network Security Gateway Evolution series, describing how to most effectively use the devices for the Big 3 network security functions: access control (FW), threat prevention (IPS), and malware detection.
Given the forward looking nature of our research, we’ll dig into a few additional use cases where we’re seeing, including data center segmentation, branch office protection, and protecting the pesky private/public cloud environments.
We’d like to thank Cisco and Palo Alto Networks for being the initial licensees of the paper resulting from the blog series. As always, we develop the research using our Totally Transparent Research methodology, ensuring no outside influence on the research.
The Path to NG
Before we jump into how the NSG is evolving, we need to pay some respect to where it’s been. The initial use case for NGFW was sitting next to the existing port/protocol firewall and providing visibility on which applications where being used andy by whom. When you got the report showing the gory detail of all of the nonsense your employees do on the network (using corporate devices) at the end of the product test, it was pretty enlightening for the network security team (and executives).
Once your organization saw the “light” in terms of real network activity, you couldn’t unsee the information. So you had to take action by enforcing policies on these specific applications. This included capabilities like blocking email access via a webmail interface, sending files up to Dropbox, or posting pictures on Facebook. It sounds kind of trivial nowadays, but a few years ago organizations had a very difficult time enforcing those kinds of policies on web traffic.
Once the devices were enforcing policy-based control on the application traffic, and the devices matured to achieve feature parity in areas like VPN and NAT with existing devices, we started to see significant migration to these new devices. Some of the existing network security vendors couldn’t keep pace in the face of these NGFW competitive threats and it’s resulted in a dramatic shift in enterprise market share over the past few years, and created a catalyst for multi-billion M&A.
The next step has been the move from NGFW to NSG by adding non-FW capabilities, like threat prevention onto the devices. Yes, that means the ability to not only enforce positive policies (access control), but also look for attacks similar to an existing network intrusion prevention device (IPS). The first versions of these integrated devices weren’t comparable to a standalone IPS, but as time marches on we expect the NSG’s threat prevention capabilities to reach feature parity. Likewise, these gateways are increasingly integrating the ability to detect malware files as they enter the network providing additional value.
Finally, when a company couldn’t replace their existing firewalls (typically for budget or political reasons), they may have had more flexibility to look at replacing the web filter. Given the NSG could enforce policies on web applications, block bad URLs, and even detect malware, the standalone web filter took a hit. Similar to the IPS, the NSG does not provide true feature parity with standalone web filtering devices yet. But many companies don’t need all of the features in a web filter – making the NSG a good fit for that use case.
The Need for Speed
As we’ve shown, the NSG has (and will continue to) add more and more functionality to the integrated device. This requires an increasing amount of compute power to enforce all of these policies at wire speed. And it’s not like networks are slowing down. Thus the first generation of NGFW became scale constrained pretty quickly. As such, the vendors continue to invest in bigger iron, including chassis and better distributed policy management options, to meet the scalability requirements.
As networks continue getting faster, will the devices be able to keep pace allowing all of these capabilities to be run on a single device? Moreover, do you even need to run all of your stuff on the same device? Not necessarily. This brings up an architectural discussion we’ll have later in the series. Just because you can run all of these capabilities on the same device, doesn’t mean you should…
Alternatively you could run a NSG in “firewall” mode, just enforcing access control policies. Or you could deploy another device in “threat prevention” mode, looking for attacks. Does that sound like your existing architecture? Of course, since there is merit to separating function in some cases depending on the scale of the environment. But what’s different is the ability to manage all of these policies from the same console, and change the capabilities of the box through an interface, as opposed to using a forklift.
We’ll also cover how you actually migrate to this evolved network security platform. Of course, most folks don’t have unlimited budget and unless your existing network security vendor isn’t keeping pace (and there are a few), there may not be a short term catalyst forcing your hand to migrate. That gives you the benefit of time, and allows you to consciously figure out the proper timing to introduce these new capabilities. We’ll wrap up the series by digging into a process to figure out how and when to introduce these new capabilities, deployment architectures and how to select your key vendor.
In the next post, we’ll dig into the firewall features of the NSG and describe how those continue to evolve and why it matters to you.