Chapter 6: Redefining the DMZ--Securing Critical Systems

Overview

Yesterday's notion of the DMZ is dead! That's a bold statement, so let's back up just a moment and define the term "DMZ," which has taken a variety of meanings over the last decade . The original, basic definition of a DMZ as it relates to information security was:

"Short for demilitarized zone; a computer or small sub-network that sits between a trusted internal network, such as a corporate private LAN, and an untrusted external network, such as the public Internet." Webopedia, http://www.pcwebopaedia.com

By this definition, a DMZ refers to an area between a border router and a firewall, or inside the border router but outside the firewall, as you can see in Figure 6-1.

Figure 6-1: A traditional DMZ

More recently, the following definition for DMZ has taken hold:

"A DMZ is a network or part of a network, separated from other systems by a firewall, which allows only certain types of network traffic to enter or leave. In a typical example, a company will protect its internal networks from the Internet with a firewall, but will have a separate DMZ to which the public can gain limited access. Public web servers might be placed in such a DMZ." Wikipedia, http://www.wikipedia.org

This definition is slightly broader, as you can see in Figure 6-2.

Figure 6-2: A modern DMZ

Is a DMZ still the area outside the firewall but inside the border router? Alternatively, is a DMZ a physical LAN "hanging off" of a firewall, or could a DMZ be inside the firewall? Does it really matter what you call a DMZ, or where it is physically located? Many variations of these definitions exist, but these examples will suffice to support our arguments that the notion of a traditional DMZ is dead. Instead, you should think of your network in terms of "security zones," each with its own security policies for access to systems and information within that zone.

The original idea behind a DMZ was to place the "sacrificial lamb" (system) in a non-trusted segment of your network. Today, a DMZ is typically an additional interface "behind" a firewall. If an attacker compromises the system, the hope is that internal trusted systems would be unaffected or unreachable by the attacker. If you hope that the physical DMZ will protect your internal trusted network, we would ask questions such as:

• Do you access DMZ systems from internal trusted systems?

• Do the DMZ systems use authentication directories that reside on the internal network?

• Do DMZ systems access backend databases inside the trusted network?

• Do you store proprietary or confidential information on the DMZ systems?

If the answer to any of these questions is "yes," then your hope may be unfounded.

Today's network must provide ubiquity, availability, and security of information. It's less about placing critical information assets (servers, databases) in a DMZ with special filters, and more about segregating access to those assets by function, wherever they reside throughout the entire network. Business is about secure, real-time access to specific data, from anywhere in the world, 24 hours a day. Think about a typical business today and the functions and data that users might require access to, for example:

• Real-time electronic mail

• Customer Relationship Management databases (CRM)

• Web-based corporate applications

• Remote, secure access to the internal network

• Customer or supplier extranet

Now, are you going to deploy purpose-built mail gateways, customer database servers, and VPN concentrators "outside" your firewall, with replicated data, so that if these systems are compromised, your internal network is safe and secure? We think network security goes much deeper than that. Again, think of different parts of your network as security zones, and take a defense- in-depth approach to designing your network and systems infrastructure. You must identify the risks to your business, develop an all-encompassing security policy, and then implement layered security, consisting of physical, logical, and procedural security mechanisms. All of this is dependent on where a system is located in your network, what data resides on that system, which users need access to the system, and what they need to access. We are not saying that deploying specific systems inside some type of DMZ is inherently bad. We are saying that defense-in-depth extends beyond the concept of a DMZ, from your border router all the way in to your internal network.

This chapter will discuss components , methods , weaknesses, and a checklist for securing critical systems.

• Components of Defense-in-Depth A brief explanation of a defense-in-depth strategy.

• Exposing Weaknesses of DMZs How attackers can impact security through weaknesses in various DMZ implementations .

• Stand-alone Systems in the DMZ Discussion of strengths and weaknesses of replicated data on a stand-alone system in the DMZ.

• Reverse-Proxy Systems in the DMZ Discussion of strengths and weaknesses of a hardened , reverse-proxy system in the DMZ, communicating securely with backend systems in the internal network.