Practical Security Solutions

By Ron Collette, CISSP & Mike Gentile, CISSP

ron@cisohandbook.com, mike@cisohandbook.com

According to dictionary.com, the military definition of a demilitarized zone (DMZ) is: “A zone from which military forces or operations or installations are prohibited; tensions exist on both sides of the demilitarized zone”

In the world of corporate enterprise networks, a DMZ represents a protected subnet(s) on a network where systems reside that must communicate with both trusted and un-trusted networks. For clarification, a trusted network is one where the traffic is known, understood, and under direct control of the owner.  An un-trusted network is one that your organization does not own, maintain, or control. An example would be the Internet or a business partner network to which the company is directly connected.

Designing a DMZ correctly is an essential element to achieving a positive risk profile for the organization. As stated above, the DMZ design is critical to establishing and maintaining a perimeter between trusted and un-trusted networks; operating as a gateway between the two levels of trust. A well designed DMZ serves several purposes; it recognizes all of the various types of traffic that passes through it, allows only authorized traffic to pass, and provides “layering” between un-trusted networks and sensitive data locations. An inability to provide these functions is what often leads to a massive increase in risk to an organization. So what should be considered when designing a DMZ?

The most important consideration in the design of a DMZ is to understand the requirements that the DMZ must serve.  Every organization will have different needs for its DMZ and understanding/documenting these factors is crucial to a successful design. This means that anyone using the future DMZ, in any capacity, must be included in the process of gathering requirements. So why is this often not the case?

It is common in many information technology groups for different technology disciplines to communicate ineffectively on these types of projects or really any type of project for that matter. Nowhere is this more common than between the network and application development disciplines; both of which are critical teams for creating a successful DMZ design. They’re important due to the fact that the network team often builds and maintains the DMZ, while application teams build and maintain the applications that will utilize it.  Aside from the obvious, building and maintaining the applications, there are other reasons why application development team involvement is critical.

Application teams provide a detailed knowledge of the manner in which the applications they create function. This knowledge enables them to add value with other common application specific considerations that need to be explored to ensure a strong design. This includes items such as how traffic will flow into and out of the DMZ from both internal and external networks, the types of applications that will require placement in the DMZ, any existing processes such as web publishing or system development life cycles that exist, data encryption needs, as well as applicable test environment scenarios that must be considered.  

Aside from application specific concepts, other technology disciplines are also important to consider. Similar to the application concepts, without a review of these items it is nearly impossible to achieve the most effective design for your environment.  Additional concepts include the following:

Management Functionality of the DMZ: This includes requirements such as the means by which backups, remote management of systems, logging and monitoring, and other maintenance functions will occur.

Operating Systems:  The OSs of the various systems that will reside in the DMZ must be considered in the requirement gathering process.

Data Stores: The types of data, the storage systems, and the supporting protocols should be considered in the requirement gathering process.

Authentication: The mechanism(s) by which people and systems are authenticated must be considered in the requirements process.

Physical Location: The location of all of the systems and components that comprise the DMZ should be considered in the requirement gathering process.

Operating & Security Procedures, Standards, and Guidelines:  These documents ensure that the DMZ is used correctly, efficiently, and securely.  They are often forgotten, but are just as important as the equipment that will comprise the DMZ.

Hopefully, this article demonstrates that there is no such thing as a cookie-cutter solution for the implementation of a DMZ. The key is to capture all the necessary requirements to ensure that your design is correct for the situation, thus producing a custom fit.  With the right design in place, you can ensure both a secure and operationally efficient environment for your organization.