What is a dedicated DMZ?

The goal of this article is to introduce some basic DMZ architectures on the concept level in order to understand implementation scenarios of external facing applications and WAF solutions. There will be no technical network diagrams but merely some high level boxes with some arrows – there is no intention to become more technical than necessary. This post is the follow-up on the article “What is a DMZ?”. Please read the previous post if you are not yet familiar with the term DMZ.

The ideas behind these security architectures are simple, however, they are rarely discussed nor really understood within many organizations, except by the network specialists. This is a pity at best, a dangerous situation at worst. It is not only a matter of HR shortage of network specialists, it goes at the very heart of maintaining a consistent security boundary. The danger lies in the highly dynamic interaction between IT and business management which makes it difficult to maintaining security consistency on enterprise level on the security boundary.

Many IT installations start with a sound architecture on the green field. However, enterprise IT and IT technology is a highly dynamic environment and the initial intentions and ideas will alter over time, together with personnel fluctuations. This is neither good nor bad, it is just a reality that needs to be addressed. New business needs, technologies and applications will emerge and numerous change requests will gradually transform the initial installation into something – probably different.

This should happen with oversight and understanding of the wider enterprise context and overall security setup. However, the realities are often driven by short-term projects on a tight budget, seeking short cuts and picking the low hanging fruits. In such a situation security is often treated as second thought and rather seen as hindrance. This is daily business – and the challenge is to maintain a consistent security setup over time for the benefit of the enterprise as whole. A balance must be found between such projects goals and the initial enterprise security goals. This is very difficult to achieve if the underlying security architectures are only understood by a handful of specialists. Such basic concepts should be available more broadly during the discussion of projects and budget decisions.

A lot has already been said the last few years about the vanishing role of the security perimeter. Some technology implementations simply cut through the perimeter which requires to shift the focus to multi-layered defense in depth and end-to-end security. Very true, however, the perimeter cannot simply disappear. It must be seen within the larger context on enterprise level. The security measures on different layers fulfill different security purposes – and need to be orchestrated. As such, the boundary (perimeter) will stay and it still is a key area for any organization to have it under control.

The following introduces 4 high level DMZ scenarios and some thoughts on internal segmentation. This list not meant to be exhausting and authoritative as variations and specialized scenarios for other needs are conceivable. However, the stake-holders should recognize such patterns within their own infrastructure and take them into account.

1. Dedicated DMZ for web applications

This setup is especially interesting for a large organization in order to profit from the reuse potential of a solid security infrastructure.

Web applications are placed behind the entry server in firewall separated network segments – appropriate to their classification and protection needs. Guiding principle is to separate the public applications from the other web applications which require some kind of user authentication.

The reasoning behind this is that public applications are accessible to the whole world – and as such are exposed to all possible hacking attempts. Such applications should be considered as not trusted. This DMZ should therefore be considered as black hole DMZ in the sense that no access should happen to other networks. Maybe an exception to its own dedicated DB layer for e.g. housing the content management data of the web application. This DB segment would inherit the same trust level as the public network segment, i.e. zero, and it should not contain any sensitive data.

The characteristics of this design template is that a Web Entry Server as central security gateway controls all access towards the web applications. Large organizations have a number of web applications so that it makes sense to leverage the reuse potential of a security infrastructure for all applications. A smaller number of applications would probably lead to the situation that the Web Entry server layer would collapse into the application layer by removing one firewall.

The entry server controls the access to all URL resources on the application layer. If the Internet user wants to access an application that requires authentication, the entry server will redirect the request to the login service first. The authenticated session will only be established after successful authentication has been established and the authorization decision has been made. The entry server will enforce this authorization decision for each request and application involved, creating a SSO authentication domain.

Template for a dedicated DMZ infrastructure for web applications
Template for a dedicated DMZ infrastructure for web applications.

A public application does not have authentication and can be accessed by all Internet users. The threat profile is therefore far larger than for applications with authenticated known users. It makes sense to treat applications without authentication as application with zero trust level and to place public and authenticated applications into segregated DMZ infrastructures in order to prevent attack vectors from public applications. The only access path allowed goes over the Web Entry Server, which is a highly trusted security infrastructure.

Overall characteristics of such a setup:

  • A WEB Entry Server with dedicated DMZ creates multiple layers of defense for web applications
  • Increasing security for authenticated applications by separation public applications into separate network segments: e.g. public and non-public applications
  • Web Entry Server WAF filtering protects applications against common types of attack
  • Web Entry Server authentication and access control features protects applications against sophisticated attacks
  • Possibility to bundle applications into SSO authentication domains

2. Dedicated DMZ for outbound business services

This outbound scenario is for using external SOA services in a secure way. Technology wise speaking it is based on http, however, there are 2 different use cases: Contract based low entropy http outbound (for application services) and high entropy http outbound (for human beings). The security goals for both cases are the same: To filter out external malware and to prevent internal data leaks. However, it makes a huge difference for implementing a security solution if traffic payload and behavior can be anything or if it is just limited to a small set of predefined patterns.

Internal applications/services will always following a small set of patterns based on a contract, furthermore, they always connect to same external services. XML/SOAP templates and certificates need only to be implemented once on a validation forward proxy if such external services base on SOAP web services and use server certificates. Everything else beyond what is explicitly allowed will be discarded. This is a so-called white list approach for handling web services which does not require a lot of effort. The second use case involves browsing of all internal users. It is very hard to catch all possibilities of browsing behavior and it requires an always growing black list of forbidden services and malware in order to be on the safe side. This is the so-called black list approach – basically a never ending night mare.

Template for a dedicated DMZ for outbound business services.
Template for a dedicated DMZ for outbound business services.

It makes a lot of sense to separate both use cases into 2 forward proxy infrastructures because the SLA requirements are completely different. It would not be an issue if browsing would not be possible for 2 hours. However, 2 hours might create huge problems if this happens to a business application/service.

Overall characteristics of such a setup:

  • Dedicated for outbound services based on web technologies
  • For efficiency purposes: Separate web browser traffic (from employees) from web services traffic of business applications (e.g. SOAP/XML)
  • Data validation on the web service proxy: 1) data validation setup change after application change, 2) data validation for each communication
  • All data on the browser proxy needs to be checked for data leakage

3. DMZ for supporting the IT infrastructure

It makes sense to have a separated DMZ for supporting IT infrastructure services, e.g. external facing DNS server or the external email infrastructure. External communication related to infrastructure services are less difficult to secure than it is for web applications. Industry standard filtering technologies can be used for securing such communication. It is furthermore likely that such external communication is based on formal contracts. Infrastructure does not change with the speed of business applications, an IDS/IPS is most likely to be successful in such an environment.

Template for a dedicated DMZ for IT infrastructure.
Template for a dedicated DMZ for IT infrastructure.

Overall characteristics of such a setup:

  • No business applications
  • Only infrastructure applications and services with few changes/long life-cycle
  • In- and outbound can be easily controlled, separating would not bring much
  • Content validation can be left to dedicated proxies or infrastructures like virus check for mail, etc.

4. DMZ for supporting VPN connectivity infrastructure

Template for a dedicated DMZ for supporting a VPN connectivity infrastructure.
Template for a dedicated DMZ for supporting a VPN connectivity infrastructure.

Overall characteristics of such a setup:

  • Only authenticated users are involved, based on contracts and trust.
  • High trust level proxy and login infrastructure is required for allowing remote access to employees (comparable to a web entry server)
  • Partner remote connectivity often requires a dedicated case-by-case approach. However, on the proxy layer is some reuse potential.

Afterthoughts

These DMZ structures are rarely fully implemented as it can be costly. However, it makes sense to recognize such patterns and the thought process involved when creating a DMZ. There is a good change to find a large number DMZ in large global companies – all implemented with different approaches in each region. It is important to have a consistent approach at the boundary because everything which is not filtered or blocked at the boundary is a potential security risk. Multiple layers of defense are required – from the boundary to the internal network, covering technologies, infrastructures, processes and user behavior.

A similar segmentation approach can also be applied to segment the internal network into different trust zones. However, it makes sense to think twice before starting to implement network zones. There is no limit of possible trust and use case scenarios. Implementing a network zone is easy but it requires a lot of understanding in order to create a consistent structure from enterprise perspective. It requires even more understanding and effort in order to keep them consistent over time. A technical implementation will also require to define a zone policy, a zone owner, and to design a zone change management process with the involved stakeholders so that the initial purpose of these zones will evolve in a secure and consistent way.

2016/02/05 © ACROSEC Inc.