This article can also be found in the Premium Editorial Download "Information Security magazine: Defense-in-Depth: Securing the network from the perimeter to the core."
Download it now to read this article plus other related content.
Remote connectivity, partner extranets, supply chains, on-site consultants, partners and peer-to-peer networks render Bill Cheswick's 1990 network security model of a "crunchy shell around a soft, chewy center" increasingly obsolete. Although inexpensive firewalls are getting smarter and faster, the most significant security issues are on the inside of your network.
Picking the players
Many vendors offer infrastructure security products, and it was difficult to identify those that matched our enterprise-scale requirements.
We invited the major switch, wireless and firewall vendors to participate, including 3Com, Check Point Software Technologies, Cisco Systems, Enterasys Networks, Extreme Networks, F5 Networks, Foundry, Hewlett-Packard, NetScreen Technologies, SonicWALL and WatchGuard. Some declined to participate because of a mismatch between their current product set and our requirements. Others declined because of resource constraints.
The stock response to the challenges of the virtual enterprise has been to heap on protection at multiple layers, augmenting network traffic controls with protocol and application-layer filtering, IDSes, VPNs and other tools. But no one has taken the idea of defense-in-depth to its logical conclusion: turn the network "inside out." Make every part of the network "crunchy." Push firewalls to every device on the network--from database servers to desktops--down to the port level.
To address this problem, we focused on access control and authentication as close to the user as possible. Increasingly, firewalls are showing up within a network to protect servers, segments and subnets from each other. We wanted to see if security technology has advanced to the point where we extend protection, control and logging functions to each device--a granular level of firewall control that goes well beyond anything attempted to date.
Furthermore, if this level of control is possible, is it still too complex to manage?
Accordingly, we challenged firewall and networking vendors to generate a design that "turns the network inside out"--a network that has a crunchy shell and a crunchy inside. Five vendors submitted solutions: 3Com, Cisco Systems, F5 Networks, Hewlett-Packard and NetScreen Technologies (see "Picking the Players").
The responses were both fascinating and a little disappointing. Each vendor takes a different approach to the challenge, and none has the technology to make the network as secure at the port level as a normal firewall does. Still, they advanced some innovative and interesting offerings.
We asked vendors to design a secure network for a typical multinational enterprise with the following characteristics and requirements. The products would need to:
1. Secure a headquarters office consisting of six buildings, 33 floor wiring concentrators, 12,000 Ethernet ports and 3,000 users.
2. Create compatible solutions on a smaller scale for five 100-person regional offices and 100 branch offices with no more than 10 people each.
3. Build a compatible wireless solution for use in all three environments.
4. Describe an integrated management solution so that security controls in the equipment could actually be used.
Architectural diagrams showing how each vendor addresses this infrastructure appear throughout this article.
Each vendor brought many technologies to bear on our hypothetical infrastructure. When it came time to compare proposals, though, we found common key areas to evaluate each response:
Authentication and security enforcement. Each vendor had to say where it was putting firewall services. Although we asked for solutions down to the port level, no one could do that with current technology. Each vendor moved the firewall function into the network, some in more than one place. Some also broke out the two traditional functions of a firewall--user authentication and security enforcement--into different places. We looked at how each vendor proposed to authenticate the users, and then where security enforcement would occur, since both are key to implementing the firewall function. For authentication, we identified the authentication point and method. For enforcement, we looked at both enforcement point and strength (i.e., stateful firewall vs. simple packet filter).
Management. Knowing how difficult it is to manage even four or five firewalls, we wanted to see how each vendor proposed management of a "firewall" that has, effectively, more than 3,000 ports. We hoped to see integrated tools, from the device level up to the policy level.
Branch office/wireless access. Does the vendor solution scale down as well as up? Or would we be stuck with a solution that only worked at the enormous headquarters building? We were looking for integrated security solutions--not islands of security with no centralized control.
We also asked each vendor to provide cost information on their proposal, after giving them a $1 million budget to play with. Predictably, few paid attention to that part of the RFP. Because we got such different solutions, cost became difficult to measure. For example, F5's proposal came in at less than $150,000. NetScreen came in at less than $500,000-but it largely relied on existing infrastructure. HP, which proposed replacing everything with a new switch fabric, quoted $1.7 million. Cisco and 3Com didn't even try to figure out how many pieces we'd need, or the cost.
Overviews of the five solutions show a wide range of architectures, though there were similarities. Each vendor, predictably, played to the strength of its product offerings. None took us up on the option to partner with other vendors to offer a more complete solution:
- 3Com focused on the endpoints, proposing a firewall-on-a-NIC solution to protect servers and,
if budget allows, clients as well (see Figure 1, above). By putting an enforcement point at nearly
every network connection, 3Com offered centralized management and performance without the drawbacks
of software-based personal firewalls. 3Com also used 802.1X, the new IEEE standard for LAN and
wireless MAC-layer authentication: no one gets anywhere on the network without first identifying
themselves. 3Com separated the authentication function (which happens at the network port level)
and the enforcement function (which happens at the NIC level).
- F5 left most of the network untouched--and unprotected--but provided a higher level of data
assurance than anyone else for traffic aimed at the servers. The overall approach was to encrypt
and authenticate everything. F5 proposed putting its Big-IP SSL accelerators in front of every
server, requiring connections to use SSL, with its built-in authentication and encryption.
- HP stayed within the boundaries of the network, though it also focused on the endpoints. Using
its new switching firmware, HP called for both 802.1X authentication and per-port access control
lists to restrict and manage connectivity, giving authentication and enforcement at the port level.
Although HP's enforcement is weaker, using static packet filters, its solution came very close to
the ideal of firewall at the port level (see Figure 2, above). HP also put static access control
lists in the core, supplementing those at the edge. However, HP didn't have much of a solution for
branch offices or management.
- Because of the enormous breadth of its hardware, Cisco gear was all over the network: in every wiring closet and on the servers themselves. Cisco switches used 802.1X authentication at the port level, with users placed on appropriate VLANs and back-hauled to enormous switches in the data center. These switches are loaded: built-in full stateful firewall, intrusion detection services and SSL acceleration. Like 3Com, Cisco separated authentication (at the port level) from enforcement (at the data center or VLAN level).
A closer examination of each of the key areas of evaluation--authentication, enforcement, management and remote access/wireless--reveals just how far security technology has come, and how far it has to go.
Two Paths to Authentication
In a complex enterprise, with thousands of users connecting within the HQ and from satellite offices, knowing who's on the other end of a wire is critical. The solutions follow two general approaches for authentication: NetScreen and F5 employ user-based authentication strategies; 3Com, Cisco and HP rely heavily on 802.1X.
In traditional perimeter firewalls, user authentication is optional, and many enterprises don't implement it. Instead, incoming holes are poked in the firewall based on static information, such as service port numbers or static IP addresses. Perimeter firewalls generally have a very "inside/outside" orientation, with very different policies in each direction.
On the other hand, virtually nothing is static in our hypothetical enterprise. Users will connect to the network at multiple points, getting dynamically assigned IP addresses, not only inside the wired and wireless sections, but also when traveling. For that reason, some sort of user-based authentication is critical.
3Com uses 802.1X authentication against a RADIUS server to activate a port. That's just one of several port-level controls. For desktop environments in which connections are fairly static, 3Com records the MAC address of the first system to connect to a port. Anyone else who tries to connect will cause the port to be disabled. Other port-based controls include blocking unauthenticated traffic and special support for 3Com VoIP phones.
In contrast to 3Com, HP and Cisco use the 802.1X/RADIUS combination to assign users to VLANs when they authenticate. Consequently, the VLAN becomes a security grouping rather than a routing or management grouping. Cisco aggregates the VLANs at the core routers, which then apply full stateful firewalling.
HP, however, doesn't offer full stateful firewall in the core. Of course, you could add a full stateful firewall from a third party, such as Cisco or NetScreen, to secure routing between HP's RADIUS- assigned VLANs.
The 802.1X authentication by 3Com, HP and Cisco was a good, but not perfect, match to the needs of our hypothetical enterprise. Although third-party 802.1X supplicants are available for the majority of desktop and portable platforms (Windows, Mac and Unix), the additional complexity of an 802.1X deployment adds training and deployment costs. Furthermore, because the authenticators provided by HP, 3Com and Cisco all are 802.1X-method agnostic, those vendors managed to sidestep the problem of choosing a compatible Extensible Authentication Protocol (EAP) type (e.g., TLS, TTLS or PEAP) and inner authentication method within the EAP tunnel (e.g., PAP, CHAP), required for wireless authentication.
The 802.1X-based approaches from HP, Cisco and 3Com are inherently multiprotocol and have an explicit forced synchronization step: your desktop will pop up a dialog box asking for authentication (or unlocking of your private key if digital certificates are used) before any packets can go over the LAN or wireless connection.
NetScreen authenticates to the firewall using a browser over an SSL-secured connection (see Figure 3). While VLAN information helps define a user's access control, authentication against the firewall is what sets his detailed network policy. A user authenticates, say, once or twice a day, based on what policy authorizes.
NetScreen's authentication proposal matched the capabilities of our enterprise perfectly, but didn't do as well meeting the security requirements.
Because the authentication is being done far away from the port level, NetScreen left some obvious vulnerabilities open, such as session hijacking. Nor did NetScreen tackle the hard problem of how to get users onto VLANs in the first place. Using their solution as proposed would mean giving up the ability to have users roam around and be placed in the proper security zone--or would mean implementing 802.1X in addition to Web-based authentication.
On the plus side, by simply linking the firewall to an existing Windows-based, organization-wide authentication database using RADIUS, NetScreen leveraged a huge amount of existing infrastructure quickly.
F5 offers an even stronger authentication model than NetScreen, although it also authenticates users at the firewall--in this case, its Big-IP 5100 SSL proxy (see Figure 4). F5 authenticates within an SSL session, and every single TCP connection is fully authenticated using PKI-assigned digital certificates for clients and servers.
By contrast, NetScreen's authentication is Web-based, but not otherwise connected to any particular transaction. The hole opened in the NetScreen firewall after authentication can be exploited using a forged IP address--which is considerably easier to do inside a corporate network than across the Internet.
The disadvantage of F5's approach is that it only works for servers that are protected by the Big-IP and only for SSL-encapsulated data streams. In our general enterprise model, that's great for areas such as a financial management system and the company intranet, but doesn't help restrict access to less significant assets, such as printers and other users, systems, or applications not easily layered on top of SSL.
Both NetScreen and F5 encourage security granularity at the user level, while HP and Cisco fall more naturally at the "group" level, assuming that you can map each group to its own VLAN. 3Com's authentication offers no real granularity--it doesn't tie access control and authorization to its 802.1X authentication, which is completely disconnected from the rules loaded onto its NIC-based firewalls.
Enforcement: Not Quite There
Policy enforcement is the key to our goal to push firewall capabilities as far into the network as possible. No vendor was able to give us true firewall protection all the way to the port level, although some came close.
At first glance, 802.1X authentication looks like the answer, but the problem is that 802.1X authenticates the user at the MAC layer (layer 2), below the IP layer (layer 3). In contrast, firewall rules are expressed in terms of IP addresses, which can change, be forged and don't even get assigned until long after the 802.1X authentication. This means that downloading a policy at the point of 802.1X authentication doesn't give you a complete picture of what the user can and can't do.
HP attempts to resolve this problem by trying to push access control lists (ACLs) to the port once 802.1X authentication takes place. But HP's ACLs are static packet filters, not stateful. While they provide strong protection by blocking traffic, they can't effectively limit traffic to a specific set of services.
HP matched security requirements as well or better than anyone else. The lack of stateful packet filtering and full firewall control was troublesome, but not a deal breaker. In essence, we got firewall to the port level, but not a very good one.
Cisco, like HP, pushes ACLs to the port, but presents a stronger and more secure solution: VLANs connected by high-speed firewalls. Cisco's firewall enforcement uses stateful inspection, but it's in the main data center, somewhat removed from our Grail of port-level control. Cisco proposes installing a firewall blade into its core Catalyst switch for full, stateful firewalling of traffic as it passes between VLANs assigned at 802.1X authentication time (see Figure 5).
While F5's approach is an outstanding component of a full inside-out network security architecture for our hypothetical enterprise, it isn't a complete solution. It focused more on protecting servers and specific application protocols running over the network, rather than the network and every element on it.
F5 builds a perimeter around the servers in the data center, requiring SSL communication to those systems. This gives something no other vendor offered within the network: encryption and per-packet authentication. But it doesn't make the network secure throughout.
3Com's decision to build a secure wall around every network element with firewalls on server (and, optionally, client) NICs provides stateful inspection at the system and user level, but at the cost of ignoring the network itself. Once you're authenticated onto the network, if you can somehow disable your firewall (or if you're on a platform which doesn't have a firewall), you're free to roam.
That said, 3Com's innovative approach is very attractive. The technology is substantially different from personal firewalls: It can't be turned off by software, and the user can't modify policy. It's OS-independent and gets the performance boost of hardware.
The embedded firewalls make practical business sense: Because you can replace NICs incrementally, you could gradually roll out the more secure service very easily. On the client side, however, the solution looked good for desktop users, but not so secure for mobile users. Most laptops have built-in Ethernet ports, so adding another one didn't seem like much of a barrier to misbehaving mobile users. Wireless access was another place where 3Com's solution didn't help.
NetScreen's match to our enterprise requirements was about the same as Cisco's: nice firewalling, but no per-port control. NetScreen enforces security between VLANs at a firewall attached to a switch in the main data center. Because NetScreen doesn't make switches, its high-end 5000-series firewall is hung off a 1 Gbps Ethernet interface on the main switch.
NetScreen adds a twist, depending not so much on VLAN identification of each user as Web-based authentication--both are used to determine access control policies. NetScreen provides granular control, to the user level. There's a danger, however: Because NetScreen is firewalling several hops away from the actual user, anyone on the same VLAN can hijack a connection by impersonating another user's IP and MAC address.
Hard to Manage
Managing the complexities of network devices and firewall policy for thousands of users is no mean feat. The really tough part is figuring out how to communicate security policy to the devices. Not surprisingly, this was perhaps the weakest area of the vendors' responses.
NetScreen and Cisco simplify the task by limiting the number of devices where policy-based management is required. The downside of fewer devices is that parts of the network go unprotected. Given those caveats, NetScreen's management matched nicely with the centralized control strategy we asked for. Its GlobalPro is used to define firewall configuration and policy through one interface. Global Pro also handles VPN configuration and general device management. But NetScreen doesn't deal with anything besides its own firewalls, meaning that user-to-VLAN mappings, switches, the wireless network, etc., require other management tools.
3Com and Cisco adopt similar strategies, but rely on multiple management tools. Here, the issue is integration and coordination. Both 3Com and Cisco's solutions would require the network manager to learn multiple products and, more importantly, keep configuration and policy information synchronized between them.
3Com's embedded firewalls are managed by a central policy server, while configuration is done through its Network Supervisor tool.
Cisco's VMS 2.1(VPN and Firewall Management Solution), a bundled set of management tools, handles configuration of firewalls and switches.
However, our experiences with Cisco's management systems for security give us pause. Although VMS is stable and highly recommended, it's a dead end for firewall/VPN management. Any expansion of firewall-to-the-port functionality would require a different management tool. With a long history of changing products and versions, Cisco's management looks like a risky bet.
HP really left us high and dry when it came to security management. TopTools (or, optionally, HP OpenView) leaves a huge gap between system and network management, on the one hand, and fully managing the security solution. HP's only answer is to manually insert this information into some third-party RADIUS server.
HP couldn't put security management tools on a timeline short enough to meet the needs of our RFP. This raised a red flag.
F5 came at this problem from the minimalist camp, suggesting integration of its Big-IP servers with LDAP to provide an authorization step. But F5 doesn't say how authorization information would be placed into the directory. Moreover, device management, even for the few boxes needed to secure the regional and HQ servers, would still require iControl Services Manager, F5's multidevice management tool.
Remote Access and Wireless
Although the real money in our hypothetical network security project was earmarked for re-engineering the HQ network, we wanted to see whether respondents could scale from the SOHO environment all the way up. Another important point was weak physical access security in branch offices.
Remote access. NetScreen, 3Com and Cisco all offered SOHO solutions. F5, because it only protects servers, didn't look at the branch offices. HP, which has no small office hardware that is enterprise-compatible, didn't address branch office security.
3Com offered a pragmatic solution. It proposed using a local authentication model where usernames and passwords are stored on the network hardware, eliminating the need to somehow propagate RADIUS information down to that level. It was an elegant and efficient solution, despite the management overhead of programming management information into local wireless access points and switches.
NetScreen offered either its NetScreen-5 family of firewall/VPN appliances or, in the case of very small branches, a software VPN. NetScreen's engineers really captured the essence of the physical security problem with the software-based VPN solution, suggesting that we simply treat the branch offices as completely untrusted sites.
Despite the overhead of installing client VPN software, we believe that it would actually be more efficient, since the same configuration could be used for both remote and branch office access. By making the branch offices simply Internet-connected points-of-presence, our enterprise network manager could almost forget worrying about things such as expensive and scarce static IP addresses or remote system management.
Cisco switched from its higher-end PIX firewall (specified at the regional and HQ data centers) to a very cost-effective combination IOS router, firewall and VPN solution.
Wireless. For wireless security, HP, Cisco and 3Com all proposed 802.11 access points protected with 802.1X authentication and key management. NetScreen used the same VPN strategy for wireless as it did for branch offices. F5 didn't have any specific wireless options.
For our enterprise, 802.1X over wireless poses many of the same problems as 802.1X in a wired environment: lack of supplicant support, especially in the traveling, visiting and mobile users most likely to want access to wireless LANs.
A second defect of the wireless strategy was the lack of ACL features on any of the access points given from 802.1X authentication. This means that access inside the network would be essentially undifferentiated unless a VLAN-based strategy for security were used.
Are We There Yet?
After evaluating the vendor proposals, it's clear that we're much closer than we ever have been to pushing security policy and control down to the port level. However, we clearly have a long way to go. Only Cisco and HP even considered the possibility of pushing access control down to the port level, and both will have to advance their technology considerably before this access control will have the power and dynamic control of a real firewall. 3Com's proposal to use embedded firewalls was innovative and exciting, but failed to meet the goal of making the network secure throughout.
In addition, vendors have to work on their management toolkits. While NetScreen, 3Com and Cisco all offer some sort of centralized management tools, none can manage thousands of ports and the dauntingly complex security policy that requires.
Joel Snyder is a senior partner at Opus One, an IT consulting firm in Tucson, Ariz.
This was first published in June 2003