Considerations on DMZ Design in 2016, Part 1

I’m currently involved in a “DMZ Redesign” effort in a sufficiently large enterprise (800+ hosts in “the DMZ”) and I thought this might be an opportunity to reflect on some aspects of “DMZ networks” in a series of posts.

Some of you already know that, at ERNW, we have a tendency to discuss stuff starting with some formal definitions and a bit of abstract (overview) approach. It’s not different this time ;-), so let’s first find out what the term “DMZ” means, what such a thing is considered to be and to deliver, and what the actual state of affairs might be in 2016. Different people within an organization might have quite different understandings in this space.
Further it’s entirely possible that the DMZ networks are not operated by a company themselves but by an outsourcing partner which then means that “placing a system in the DMZ” becomes “ordering a DMZ [network] port” by means of some web-based procedure or ticket system, which in turn might have a number of interesting implications (we’ll have a dedicated post on those).

The most classic compendium on firewalls[1] defines as follows:
“Perimeter network: A network added between a protected network and an external network, in order to provide an additional layer of security. A perimeter network is sometimes called a DMZ, which stands for De-Militarized Zone (named after the zone separating North and South Korea).”

While this definition has gained widespread use over time, it lacks any guidance on implementation details or an explanation of the beneficiaries of the mentioned “additional layer of security”. It should also be noted that – in contrast to the DMZ between North and South Korea – a DMZ as of common understanding is exactly not de-militarized when it comes to technical network defense instruments. In short: while widely known and used, from a technical perspective this is a debatable definition.

Probably referring somewhat to the above, the ISO/IEC standard 27033-1[2] (still) states:
“demilitarized zone / DMZ: perimeter network (also known as a screened sub-net) inserted as a ‘neutral zone’ between networks”.

Again, we don’t consider this explanation as particularly helpful, not least because a DMZ usually is exactly not neutral (but controlled by a dedicated party, for a dedicated purpose and in a way which is considered disadvantageous for another party [that is attackers]).

ISO 27033-4[3] provides a more detailed view:
“The DMZ, referred to as a perimeter network, is a physical or logical subnetwork that contains and exposes an organization’s external services to a public network, usually the Internet. The purpose of a DMZ is to add an additional layer of security to an organization’s internal network; an external attacker only has access to services in the DMZ, rather than any other part of the internal network. All external connections to services should terminate inside the DMZ and DMZ systems should have little or no access to internal systems. Designing a network in this way does not eliminate the risk of an internal network compromise, it merely makes it more difficult. […]
Most organizations may have multiple ‘zones’ or DMZ areas for web, application and database layers and for meeting some compliance/regulatory requirements.”

Taking the above definition into account and from our experience in general “a DMZ” is expected to serve two main (but) different purposes:

• A system placed in a DMZ can itself expect a certain level of infrastructure based protection.
  This is usually based on different controls like traffic filtering, isolation (a system cannot be reached from a huge number of other systems in a broadcast/multicast way), “above standard” monitoring (incl. even active blocking in some cases) of inbound network traffic or potentially a mediation layer (e.g. by means of reverse proxies) which provides isolation, sanitization and maybe even filtering on a upper layer protocol level.
• At the same time a system’s placement (in a DMZ) is supposed to provide some protection for other systems.
  This is based on the assumption that this isolates a (less trustworthy) system from the “internal network”: due to this isolation lateral movement becomes harder (once a system in the DMZ is compromised) and such a placement might provide an additional level of detection capabilities (as one might be able to identify security violations from firewall logs etc.).

It’s important to keep those two angles in mind, which is why we’ll get back to them occasionally in the course of the series. When you talk to network security people many of them particularly think of the “prevent lateral movement” aspect, whereas “application owners” increasingly take a stance most neglecting exactly that one, which can be summarized as follows: “let’s place & operate our app within the corporate network – all those dependencies and interactions with other apps & systems are too complex [to put it into a DMZ] anyway – and ask the guy running the reverse proxies to just enable access to it. We hear those reverse proxies are good for security and he’s an expert so he’ll certainly know which protocols/URLs/database commands & input values to restrict the traffic to. That’s why we don’t have to tell him such gory details (it would be a tedious task to find out on our own), and as a bonus he can handle all that SSL certificate stuff as well. It’s part of *his* job, right?”.

To conclude for today let’s derive some objectives from the above, which will guide our discussions and, maybe, even recommendations in the upcoming parts:

• systems in a DMZ must be protected according to their needs (we’ll discuss in a later post what “their needs” might actually mean).
• operating a DMZ must provide some security value for systems in other networks, usually the organization’s “internal” ones.
• whatever happens should (must) be efficient.
• complexity (see here for a definition) must be avoided which helps efficient operations (and hence security in general).
• whatever comes out of our efforts must be applicable in a setting where $SERVICE_PROVIDER operates the DMZ (as this is a common scenario).

In the next part we’ll cover classification and segmentation approaches in the context of DMZ networks.
Everybody have a great weekend

Enno

 

 

References:

[1] Zwicky/Cooper/Chapman “Building Internet Firewalls“.

[2] Information technology — Security techniques — Network security — Part 1: Overview and concepts.

[3] Information technology — Security techniques — Network security — Part 4: Securing communications between networks using security gateways