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 deployment; 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 DaaS1 from a perspective of what you actually want to protect. It is usually not the server you want to protect, but the data.

The origins of the DMZ

The DMZ (Demilitarized zone) model 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 the 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.

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.

This happens because we tend to focus on where the danger comes from (attack vector), instead of focussing on what we really try to protect (protect vector).

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 Broken DMZ Model

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.

This happens because we tend to focus on where the danger comes from (attack vector), instead of focussing on what we really try to protect (protect vector).

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 databaseserver) get their own segment and are not put in a shared DMZ!

Keep in mind that Zero Trust is not a technical approach and it involves different 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.

A shared business 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.


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, but keep in mind that Zero Trust is not a technical approach and it involves different stakeholders – not only the IT department –  to define meaningful segments and make decisions where measures are required. This will greatly improve security and put the measures (and costs) where they are needed the most.

1DaaS: Data, Applications, Assets, Services

Rob Maas
Thought Leader

Rob Maas