Jody Brazil
CEO at FireMon
Check Point and stateful inspection firewalls won the early battle against proxy firewalls (Part 1: Early Days). It’s easy to suggest that it was all about the inspection technology, but that misses a key innovation of the Check Point solution: Policy Management. Stateful inspection firewalls winning out over the proxy competition in the mid-90s was due, in significant part, to ease of management.
Much of this article is focused on Check Point. This is primarily due to the dominant role Check Point played in the firewall market in the late 90’s and early 2000’s. However, it is also likely due to my exposure to Check Point in those years. I welcome your perspective and look forward to your comments.
The mid-90’s was a time when networks were rapidly evolving. For example, ethernet was an option, but not always the local network protocol in use (remember token ring?). Connecting to the Internet was not assumed, it was discussed. Dial-up was still common, and AOL was the dominant player. To suggest that firewalls were mainstream technology would misunderstand the Internet as mainstream. One of the implications of this fast-changing network was a significant amount of ignorance and inexperience. In this context, the manageability of a firewall should not be overlooked as a key market driver for the eventual winner in this market.
Today, in software development, we talk about User Experience and Usability. While those weren’t the buzzwords at the time, the reason we talk about them today mattered just as much then. Customers “liked” the product better. So while security and performance mattered, the usability of the Check Point firewall GUI should not be dismissed.
To quote a Gauntlet sales rep at the time, “It didn’t matter who the prospect was, every account I went into, I had to fight the Check Point GUI – and usually lose.”
Check Point introduced their firewall with central management and a very innovative user interface. A few of the key capabilities included:
- A graphical rule editor
- Central object repository shared among the firewall policies
- Central logging
- Multi-domain management and OPSEC
The Check Point Policy Editor
The concept of a firewall rule being a 5-tuple of source, destination, protocol, port (protocol and port were combined into a single object referred to as a service) and action existed long before the Check Point policy editor. Early access control lists supported this concept in the 80’s. However, Check Point changed the paradigm with the graphical rule editor. No longer was it necessary to know CLI syntax to create a rule. A mouse and a few clicks is all it took.
In addition, rule editing was augmented with useful features like copy and paste, user-defined comments, multiple objects per column. This last point about multiple objects per column was revolutionary. Prior access control lists only supported a single source, single destination and single service in the respective columns. The support for multiple objects made each rule more powerful, and editing a policy often became an act of modifying an existing rule versus creating new rules. Much of this policy editor was predicated on another advancement, the central object repository.
The Check Point Central Object Repository
Historically, access control lists were created with a reference to a specific IP address for the source or destination. This worked, but if a system’s IP changed, it meant that every rule would need updated. Similar to reusable source code, Check Point realized that creating a central object repository and using those objects in the rules would be a better strategy. Now if a host changed its IP, only the object needed to be updated, and the policy would automatically properly reflect that update since the policy used a reference to the stored object. In addition, it was possible to create groups of these objects (and groups of groups) to enable reuse of common groups of objects throughout the policy. These were significant advancements for more effective policy management.
Central Logging
An extremely common problem with firewalls is blocking the wrong traffic. Particularly when placing a firewall between two networks that had previously not been segmented, which in the late 90s was the case with nearly every new firewall deployment. The central logging of all firewall logs that was also easily searchable made diagnosing policy errors very obvious and comparatively simple. A user could report an issue, provide a source IP / destination IP combination, and an administrator could find the “drop” log in the log viewer and the associated rule that caused the drop (or alternatively find an “accept” log and tell the user they were wrong). Mistakes were, and still are, common with firewall policy administration, so easy troubleshooting was a key value-add to any firewall platform.
Multi-Domain Management and OPSEC
In the early 2000s, Check Point doubled-down on the power of management by introducing multi-domain management with Provider-1 and integration APIs with OPSEC. Both were a significant bet on the power of management to separate Check Point from other firewall competitors – and it worked.
Provider-1, as the name would suggest, was targeted at the provider community, telecommunications and managed service providers. While providers were early adopters of the technology, enterprises quickly found reasons to be consumers of the product as well. Key capabilities including permission control, management and UI performance by splitting up large policies and object databases, and global rules that could be applied and enforced globally were all key features desired by large enterprises. In large part, these were limitations in the standard management platform. While some could argue that Check Point should have fixed the management platform versus requiring customers to pay a significant premium for Provider-1, customers saw the benefits and were willing to pay for these advanced management capabilities.
OPSEC was a partner program and collection of APIs released by Check Point to encourage third-party product integration. Early successes including reporting products that used the Log Export API (LEA), URL filtering products using the URL Filtering Protocol (UFP) and management products, such as FireMon, using the Check Point Management Interface (CPMI).
The program and integrations were a huge success. Today, there are well over 100 OPSEC partners offering some integration capability into the platform. This ecosystem of security products gives customers added value and confidence in their investment. Today, we take API integrations for granted, but in 2001 at the launch of OPSEC, this was not nearly as common.
Cisco and the CLI were a Dominant Player
The market wasn’t completely dominated by Check Point and the GUI. While Check Point established itself as a leader in the firewall market with a powerful and easy to use GUI, Cisco remained true to its roots with a command line interface (CLI) in the Pix. The Pix was an earlier competitor in the firewall market, dating back to 1994 and acquired by Cisco in 1995. The familiarity of Cisco and the CLI to network administrators made the Pix the preferred choice when the network team was responsible for security.
Check Point would chip away at this advantage with their security features and GUI aided by a slow shift in enterprise organizational structure where security would become a separate group from the network team. As this shift happened, the existing relationship Cisco had with the network team played a diminishing role in firewall vendor selection.
The enhanced management capabilities helped establish Check Point’s position in the market and reinforced the value of management for security products. But, just as performance helped Check Point beat the proxy in the 90’s, in the years ahead, performance would once again be a key decision criteria, and this time Check Point would be threatened.