- The DMZ model isolates by network zone; a compromised webserver in that zone can often still reach the database it's allowed to talk to.
- Sharing one DMZ across multiple servers means one compromise puts all of them at risk, not just the server that was actually hit.
- Zero Trust doesn't replace segmentation, it changes the basis for it: a Protect Surface built around what needs protecting, not the network zone it happens to sit in.
- Defining those segments is a business decision, not just an IT one: a business or data owner has to own the trade-off per segment.
When talking about Zero Trust and micro segments, we often talk about segments based on data (crown jewels). If we look at how Zero Trust is often presented, it is about segmenting every single server. The most common example is the 3-tier applications; web-, application- and databaseserver, where it is then stated that you should firewall every single one of them.
Though this is not necessarily a bad thing and could improve security, it is only manageable if everything is automated. Which is often not the case in "traditional" and existing environments. If implemented wrong, this could deteriorate your security.
In an existing environment it often makes more sense to start with segments based upon the data or DaaS from a perspective of what you actually want to protect. It is usually not the server you want to protect, but the data.
DMZ origins
The DMZ model (Demilitarized zone) can be found in the physical world, with the DMZ between North and South Korea being the most well-known. The idea of this DMZ is that it is neutral territory. Whenever there needs to be some sort of discussion impacting both parties, they meet in the DMZ. When network operators first started implementing the DMZ model, the idea was same.
The webserver was located in the DMZ and the website was uploaded to this webserver through FTP. If visitors went to the webserver, the website was displayed. It is important? that these are two connections initiated from both parties, like in a real world DMZ.
Nowadays, websites are often dynamic and will serve all kinds of dynamic data. The result of this shift is that often the webserver is still in the DMZ and the database server is in the LAN. To make sure the webserver can access the data, the firewall has a rule allowing the webserver to talk to the database server and hopefully there is some authentication performed by the database server before allowing the webserver access.
The traditional webserver connections
If we look at the connections we still have two connections, but they’re not quite the same as before.
The first connection is from the visitor to the webserver, the second one is from the webserver to the database server. If the webserver gets compromised then all the data on the database server is at risk, because the webserver is allowed to access this data.
Where in the traditional way the compromised webserver was isolated and only data on the webserver was affected. It is especially risky/dangerous if it is a shared database server, meaning it’s serving multiple databases.
The second problem that often occurs is that all servers that are accessed over the Internet are placed in the same DMZ. Which means that if one server in the DMZ gets compromised, all other servers in the DMZ are also at risk.
The old approach
Attack vector
Focuses on where the danger comes from. Everything reachable from the internet sits in the same zone, and the zone's perimeter is what gets defended.
The Zero Trust approach
Protect vector
Focuses on what you're actually trying to protect, usually the data, and segments around that instead of the network zone it happens to sit in.
The Zero Trust Perspective
From a Zero Trust perspective it is important to look from the inside out; what do I want to protect. If it is purely the data, putting the web- and databaseserver in the same segment is perfectly defendable. Especially if segmentation is done in a traditional way, meaning on subnet/routing bases. It is also important to note here that these applications (web- and databaserver) get their own segment and are not put in a shared DMZ!
Keep in mind that Zero Trust is not a technical solution and that it involves several stakeholders.
If the webserver gets compromised now, the same data is affected as in the previous example (assuming the database server is only serving the database for the webserver). However, the incident in itself is isolated and there is no east-west traffic with other applications.
| DMZ model | Zero Trust segmentation | |
|---|---|---|
| Basis for segmentation | Network zone / perimeter | Protect Surface: what needs protecting |
| Trust assumption | Everything inside the same zone is equally trusted | Nothing is trusted by default |
| Blast radius if compromised | Often the whole shared DMZ | Limited to the one Protect Surface affected |
| Who defines it | IT department alone | Business/data owner, with IT and risk |
A shared organizational effort
Defining those segments should be a business effort done by different stakeholders and not only the IT department. The IT department is there to support and can surely help to define the risks from a technical standpoint. Risk- and security managers should be involved in this process to get a clear overview. In the end it is important to point out a business/data-owner per segment. This person is responsible to outweigh the risk and mitigations and make the decisions.
Putting an owner per segment will greatly help the discussions, because segmenting all the individual servers is doable, but comes at a high price and will not necessarily help to reduce the risks defined.
Since DMZ is a network security control, when talking about segments in this post, the Zero Trust segment is the same as a network segment. Normally a segment can consist of far more security controls than only network segmentation.
Conclusion
The traditional DMZ setup is not secure anymore, it doesn't protect what it was supposed to protect. In fact, in a lot of cases there are multiple servers in the DMZ serving different types of data, each with their own risks. There is no protection against lateral movement and thus no isolation in case of a compromise.
Zero Trust will help to overcome this security issue. Zero Trust is not a technical approach and it involves different stakeholders - not only the IT department - to define meaningfull segments and make decissions where measures are the most needed. This will greatly improve security and put the measures (and costs) where they are needed the most.
FAQ
What is the DMZ model in network security?
A neutral zone concept borrowed from physical demilitarized zones. In network terms, an internet-facing server such as a webserver sits in the DMZ, isolated from the internal network behind it.
Why is the traditional DMZ model considered broken?
Modern dynamic websites need the webserver to talk back to a database on the internal network, so a compromised webserver can reach that data. Multiple unrelated servers often share the same DMZ too, so one compromise puts all of them at risk.
What's the difference between attack vector and protect vector thinking?
Attack vector thinking asks where the danger comes from and segments by network zone. Protect vector thinking asks what you're actually trying to protect, usually the data, and segments around that instead.
Does Zero Trust replace network segmentation?
No, it changes the basis for it. Instead of segmenting by physical network location, Zero Trust groups assets around a Protect Surface, what needs protecting, and gives each one its own segment rather than sharing a DMZ.
Who should decide how these segments are defined?
A business or data owner per segment, working with IT and risk/security managers, not the IT department alone. Someone has to own the trade-off between risk and cost for each segment.
Rob Maas is Field CTO at ON2IT, part of the CTO Office under CTO Lieuwe Jan Koning. He works on product strategy and architecture for AUXO, MDR, and ZTaaS, shaping ON2IT's Zero Trust customer journey and AI feature roadmap. He is also a Palo Alto Networks Cyberforce Hero.