Republished with permission from WatchGuard Technologies, Inc.


Interdepartmental Firewalls: 

Where to Put Them (and Why)

by David Piscitello, President, Core Competence

As organizations grow, those unfortunate souls assigned security administration duties quickly learn that there is no “one happy family” inside any organization when it comes to protecting sensitive information from unauthorized access. Consider Ted and Sally’s “success story.” When theirs was a company of ten, Sally handled bookkeeping, marketing and hiring and Ted handled purchasing, shipping, inventory and R&D. Ted and Sally trusted each other, and managing their modest company’s sensitive information could be accomplished by simple policies, over a single network, protected by a single Internet firewall.

By the time their successful enterprise had grown to several hundred employees, Ted and Sally had created departments for finance, human resources, marketing, engineering, operations, and more. They did so to manage their company more effectively, and in so doing they extended their trust to department heads to continue to protect the company’s sensitive information. The department heads, in turn, extended their trust to the security administrator, a.k.a, the firewall guy, and asked for a solution.

Compartmentalization and Interdepartmental Firewalls

The most common use of firewalls today is to enforce a security policy between an organization and the Internet. Most organizations appreciate the need for such protection. In many cases, the security policy that Internet firewalls enforce is straightforward. The primary objective of Internet firewall policies is to protect the organization’s internal networks from unauthorized access by outsiders, and to restrict outsider access to specific hosts and services. A secondary purpose is to control which Internet sites and services may be accessed by insiders (company employees).

A less common but important use of firewalls is to enforce a security policy between departments, business units, or in very large organizations, between the “core” organization and its acquisitions, divestitures and joint ventures. The primary reason to use firewalls in this manner is to isolate or compartmentalize groups and the sensitive data they handle from … well, everyone else! Interdepartmental firewalls reduce insider threats by moving access controls closer to sensitive data and the workgroups that may share that data across a LAN (as shown in this diagram). While certainly not a substitute for authentication, authorization and access controls at sensitive servers, such firewalls have proven effective deterrents against attacks that involve traffic capture, replay, and analysis (sniffing). They are also quite useful in circumstances where a security administrator has (ahem) less control over server configuration than he might wish—if you can’t convince the server administrator to harden his OS, tighten the perimeter around that server, and (loosely speaking) quarantine the workgroup!

Organizations may use a firewall to separate from all other employees a workgroup that processes personnel and financial information. When employees and servers are in the same location, the workgroup would be connected to the Trusted interface of a Firebox or SOHO. The Firebox's External interface would be connected to the portion of the corporate network all other employees access, and configured suitably: the policies applied to the External network interface keep unwanted parties out, and traffic containing sensitive information, in.

Interdepartmental Firewalls and NAT

In addition to enforcing policy, interdepartmental firewalls can also help with IP addressing problems arising from “transitions.” Consider a scenario where a corporation (Awful Big Company, or ABC Co.) acquires a subsidiary of another company (Digital Excitement Foundry, or DEF Co.). Renumbering the acquired subsidiary’s networks into the corporation’s IP address space in these times of scarce IP numbers may take time and planning, but the acquired subsidiary can’t go offline while such planning drags on.

One solution is to have DEF Co. continue to use the IP addresses they already use, and use dynamic or static NAT into ABC Co.'s network until a permanent addressing plan can be designed and deployed. For example, suppose DEF Co. used; this address space will be entered in the Trusted Interface tab of the Network Configuration dialog box on the Firebox (shown here). In companies I've worked with, the External Interface of this interdepartmental firewall is commonly configured with an IP number from an IP subnet to which ABC Co.'s Internet firewall is configured; for example, if ABC Co.'s Internet firewall had a Trusted Interface IP address of, you might configure the External interface of the interdepartmental firewall between ABC Co. and DEF Co. with (in the figure, the rest of 10.0.0./24 is one of possibly many subnets used within ABC Co.).

This practice scales very well for an organization that makes many acquisitions or sees a practical benefit to architecting its internal networks so that individual business units and subsidiaries are insulated from addressing and networking changes caused by acquisitions and divestitures. The resulting topology has many interdepartmental firewalls as spokes around the Internet firewall(s), which serves as the hub(s). A unique and finely-tuned security policy can be asserted at each spoke in the hub, beyond the general “Internet” policy asserted at the Internet firewall. It’s actually very cool.

Interdepartmental Firewalls and VPNs

With the increase in teleworking and employee mobility, it’s not always easy to keep employees and the sensitive information they must access in the same geographic location. But sensitive data must not be compromised. Consider a hospital employee who works from home or from a desktop computer several LAN hops from a server. This employee routinely accesses personal individual medical information (PIMI). His organization will be required by law to keep this information private according to strict guidelines specified in recent Federal legislation (e.g., the Health Insurance Portability and Availability Act).

Ideally, VPN technologies like IPsec could be used to create private, authenticated tunnels “end-to-end” between a user and a server he is authorized to access. IPsec, however, imposes a considerable processing overhead that today can only be mitigated by using hardware encryption. By placing an IPsec-capable Firebox directly in front of a server farm, organizations can provide secure communications as close to servers as possible at a lower cost (one Firebox vs. many crypto-accelerator cards) and with no additional processing or administrative overhead at servers.

Using interdepartmental firewalls to support IPsec tunnels isn’t limited to secure remote access for individual employees or business partners. An interdepartmental firewall placed in front of an entire workgroup of authorized users can tunnel securely using IPsec to the firewall protecting the server farm (as shown here). Firewalls used in this manner allow an organization to concentrate servers in data centers, and even outsource data centers to application or managed service providers without conceding an inch from its security policy.


The interdepartmental firewall often becomes a security necessity for any organization that grows to realize that while all its employees in all its departments share a common affinity as a company, there is a finer “need to know” regarding company information that dissociates these departments. The interdepartmental firewall creates a finer grained definition of the familiar “Trusted” vs. “External” affinities associated with an Internet firewall, a definition that is useful and will in fact become more necessary as governments impose more stringent privacy rights, and as organizations recognize the folly and peril of failing to properly compartmentalize data. The use of interdepartmental firewalls becomes more commonplace as organizations grow and as they expand their collaboration with other organizations. They are not a substitute for host security implemented on servers that host sensitive data, but they are an important complement. ##

Copyright© 2001, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.

Copyright © 1996 - 2001 WatchGuard Technologies, Inc. All rights reserved.
Legal Notice/Terms of Use