We have come a long way when it comes to DMZs (demilitarized zones). It’s no longer a question of if your organization needs a DMZ, but rather, it’s now a question of how you should design one.
In computer security, a DMZ is a physical or logical subnetwork that contains and exposes an organization’s external services to a larger, untrusted network-usually the Internet. The original DMZ designs included a simple network separated from the internal network, where everything that needed access to the Internet was placed.
Today, there are as many DMZ designs as there are vehicles on the road. You have industrial trucks designed to simply transport goods as cheaply as possible. You have economy cars designed to save money. And you have exquisite Italian sports cars that are sure to make your friends jealous (and fast enough that you always arrive with plenty of extra time for a nice cup of espresso). DMZ designs are a lot like cars: there are many varieties which go by a lot of different names but they all serve the same purpose.
There are hundreds of names that we use for networks today but, essentially, there are internal networks, external networks and DMZs. They may be called partner nets, vendor zones, internal DMZs or security zones. But the reality is that they are all DMZs with a mix of ownership devices, connectivity and risk levels.
Goals of DMZ Design
Goals of DMZ design
If you ask ten network architects about how to design a DMZ, they’ll come back with ten different answers. While variety is the spice of life, as an industry we should have some generally accepted practices of DMZ design.
One of the core tenets of DMZ design is to segregate devices, systems, services and applications based on risk. The goal is to isolate risk, so if something goes bad and the Web server is hacked, it is essential to know what other devices the hacker would have easy access to. Beyond segregation by risk, four other common design approaches are separation by operating system, data classification schemes, trust levels or business unit.
If you look at recent audit and compliance requirements, you’ll see that they include a growing number of specific technical design requirements. In some of the new requirements, we find the mandate to keep the Web and application tier separated from databases-a very good idea. We also see the move back to single purpose servers; for example, your Web server cannot also be your DNS server.
Four Levels of DMZ Design
Four levels of DMZ design
Let’s break DMZ design into four levels, with Level 1 being the simplest design and subsequent levels providing more segmented security.
When we want to build a basic DMZ, we start with a single segment of the firewall. Let’s call this Level 1 in our DMZ design book. This design is fine if you have a few servers that need Internet access. But if you do any e-commerce transactions, you have already outgrown this design.
Many people make the mistake of keeping this design, placing the Web and application servers in the DMZ and the databases on the internal network. This is no longer acceptable. As database attacks become more targeted, the risk of having the database on the internal network requires a more sophisticated design.
Level 2 DMZ designs
A Level 2 DMZ would consist of multiple DMZ networks off of the firewall. This design is a substantial improvement over a Level 1 design. It allows traffic rules to be written between each DMZ for control and segregation. A good start is having separate DMZs for Web and application servers, databases, authentication services, VPNs, partner connections, e-mail and mobile services. This is very feasible today; most firewalls can easily handle tens of interfaces and multiple VLANs on each interface.
Level 3 DMZ Designs
Level 3 DMZ designs
One problem often seen in Level 2 DMZ designs is that overly permissive firewall rules can lead to devices getting Internet access that should never have it. One way to rectify that is to use two firewalls. This design, which we’ll call Level 3, is built with an external firewall and an internal firewall. The DMZ is placed between the firewalls based on access restrictions. Inbound Internet access is allowed into the external DMZ via the external firewall-never directly routed to devices placed in the internal DMZ on the internal firewall. The internal network can talk to the internal DMZ but not the external DMZ.
This Level 3 DMZ design effectively separates Internet-connected devices and the services they require using just two firewalls with their own policies. Most security teams quickly understand the rule base design between externally accessible and internally accessible DMZs. The temptation is to create rules allowing inbound access from the DMZs to the internal network. This should never be allowed. All the services that are needed should be moved into DMZs so that internal networks are never exposed.
This restriction is often violated. A lack of coordination or communication between IT groups, the rush to deploy new applications, network complexity and other factors result in organizations building critical services on their internal networks.
Level 4 DMZ Designs
Level 4 DMZ designs
Level 4 DMZ designs are where things start getting more complicated. A Level 4 scenario would most likely include deploying multiple firewall pairs in parallel along your border rail, and spreading your DMZs out among them, segregated by your choice of metrics. Most people choose to separate the firewalls into business or functional groups, while others like to separate them by trust levels.
Best practices dictate building separate firewall stacks based on Service Level Agreements (SLAs) and data classification. This creates a situation where there is an entirely separate firewall stack for PCI, separate firewalls for user services (such as Web browsing, FTP, e-mail, patching, etc.) and separate firewall stacks for business services. Consider business services placed in DMZs by SLA: 90 percent, 98 percent and 99.9 percent make for three good goals. Designing DMZs by SLA can streamline DMZ management and reduce business disruptions.
In closing, it’s imperative to place as much rigor as possible into the planning and design process. Assume that once the DMZ is live, it may not be so easy to fix major flaws in the design. Internal due diligence can be used as a way to establish strong lines of communication with other stakeholders-whether they are other IT folks, business owners, partners or managers. It can raise your profile within your company as a thoughtful risk manager and strategic thinker. And, perhaps most important, it will invite feedback outside your frame of reference. If one conversation with one person has a significant impact on DMZ design, wouldn’t you want to have that conversation before you design it?
Michael Hamelin is Chief Security Architect at Tufin Technologies. Bringing more than 16 years of security domain expertise to Tufin, Michael has deep, hands-on technical knowledge in security architecture, penetration testing, intrusion detection, and anomalous detection of rogue traffic. Michael has authored numerous courses in information security and worked as a consultant, security analyst, forensics lead, and security practice manager. Michael is also a featured security speaker around the world, widely regarded as a leading technical thinker in information security. Michael previously held technical leadership positions at VeriSign, Cox Communications and Resilience. Prior to joining Tufin, Michael was the principal network and security architect for ChoicePoint, a LexisNexis Company. Michael received Bachelor’s degrees in Chemistry and Physics from Norwich University and did his graduate work at Texas A&M University. He can be reached at email@example.com.