The goal of this article is to introduce some basic DMZ secure architectures on the conceptual 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 DMZ in a Nutshell: An Introduction. Please read the previous post if you are not yet familiar with the term DMZ.

It’s not rocket science, it’s business science!

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

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

This should happen with foresight, oversight and understanding of the wider enterprise business 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 afterthought and rather seen as hindrance. This is a sad reality in daily business – and it is often a challenge 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 especially as base during budget decisions.

The perimeter does not disappear, what disappears are easy solutions!

A lot has already been said in 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 security perimeter does not disappear, what disappears are easy solutions at the security perimeter when every communication is tunneled through some “Firewall friendly protocols”.

The perimeter must be seen within the larger context on enterprise business level. A multi-layered defense in depth happens on many different layers. This still requires awareness about security boundaries – and which need to be consistently orchestrated in order to make sense and in order to provide a good cost/benefit ratio. As such, the perimeter will stay and security boundaries are key areas for any organizations in order to do business.

The following introduces 4 high level DMZ scenarios and some thoughts on internal segmentation. This list is not meant to be exhausting and authoritative as variations and specialized scenarios for other needs are conceivable. However, the relevant 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 architecture infrastructure.

Web applications are placed behind the secure access gateway network segments which are separated by in firewalls, appropriate to their classification and protection needs. Guiding principle is to separate public applications from 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 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 security gateway in front of the web application controls any further access. 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 behind and make it a central security access gateway. A smaller number of applications would probably lead to the situation that this layer would collapse into the application layer by removing the firewall between security gateway and web applications.

This security gateway controls the access to all URL resources on the application layer. If the Internet user wants to access an application that requires authentication, it will redirect the request to the login service. The authenticated session will only be established after successful authentication has been established and the authorization decision has been made. The security gateway 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.

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 and identified 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 security gateway, which ideally would be a highly trusted security infrastructure.

Overall characteristics of such a setup:

A security proxy as access gateway with dedicated DMZ creates multiple layers of defense for downstream web applications
Increasing security for authenticated applications by separation public applications into separate network segments: e.g. public and non-public applications
Filtering services protect applications against common types of attack
Authentication and access control features protects applications and data
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 external malware and to prevent internal data leakage. However, it makes a huge difference for implementing a security solution if traffic payload and behavior can be anything or if it is limited to a small set of pre-defined patterns.

Internal applications/services will always follow 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 all internal users who browse on the Internet. It is very hard to catch all possibilities of browsing context 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 nightmare.

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 is interrupted for 2 hours. However, 2 hours interruption 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.

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.

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 WAF/WAM)
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. It is probable to find a large number of 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. As such micro-segmentation might be helpful in order or encapsulate this complexity within individual applications or services.

A technical implementation will also require to define zone policies, zone owners, 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.