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.

This happens because we often focus on where the danger comes from (attack vector), instead of on what we’re trying 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 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’re trying 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 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.

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.