Mainframe > Administrator > Security

Living Next Door to the DMZ


Illustration by Bob Scott

Bookmark and Share

Many of us remember news clips or history lessons about demilitarized zones (DMZs). If we were lucky, we didn't live near one, but we understood the need for these buffers, designed to ensure the safety of each border and provide stability far beyond those borders. All social and political tensions aside, the DMZ is actually a relatively safe place compared to the interstate highway. It's safe because each side is vigilant about monitoring and securing the physical space between the two countries. Nobody can get in or out of the DMZ without each side knowing about it, and inspections and validations are required to gain entry.

As this term is applied to computer security and network topology, the origins of a DMZ should be kept in mind. Physical separation or isolation needs to be guaranteed; monitoring and maintenance of the DMZ must be diligent; and who or what's allowed to pass through the borders of the DMZ must be carefully evaluated. If the need to pass through the DMZ is authentic and validated, passage through the DMZ is permitted. If a questionable path is taken or an inappropriate package or payload's discovered, progress through the DMZ must be denied. The DMZ is bounded by two firewalls, which are very much like the fences and fortresses of the military DMZ. These firewalls are the enforcers - or guards - responsible for the validation and passage of traffic in and out of the DMZ.

Defining the Computing DMZ

To ensure the same terminology is used as the DMZ moves from the military to the enterprise, the following is a baseline definition: In the enterprise, a DMZ should be thought of as a perimeter network, or the space between an external network - often the Internet - and a private or protected network. The perimeter network is home to a publicly available service, providing isolation - with the ultimate goal of protecting the private network and its private services in the enterprise. Figure 1 helps illustrate the DMZ and the terminology as it applies to the enterprise.

There are many ways to talk about or describe the firewalls and areas of a DMZ in the enterprise. Some use tactical military terms like "bastion" and "choke point" for the firewalls, while others use the colors of a stoplight to describe the zones that firewalls create. The red zone is unsafe, identifying an area where users aren't trusted, likely the area outside the bastion firewall. The yellow zone brings the notion of caution with a little more trust and control. This is the area found between the bastion and choke firewalls. The green zone is an area of safety in the enterprise, sitting protected behind the choke firewall. No matter how you describe the DMZ, as the necessary elements to fortify mission-critical data and applications are examined, it's clear the IBM* System z* platform should play a role.

As the fundamentals of a DMZ are examined, the strengths of System z hardware and software will become evident for this critical enterprise entity. The DMZ can exist next door to the enterprise jewels running on z/OS*, with both the DMZ and enterprise data safe and sound at home on the mainframe. The DMZ needs to be bounded or protected by two firewalls to create a safe environment or zone for a publicly available service, such as a Web server.

The bastion firewall protects the service from the outside world and the many attacks that can come from this unprotected environment. The choke firewall sits between the public service - a Web server in this case - and the private network, acting as the last line of defense between the safer, more controlled DMZ and the critical business applications found in the private network. The choke firewall will only let known traffic from the service pass through to the secure private network. A typical scenario is illustrated in Figure 2, with a Web server that's available via the Internet. The Web server needs to be isolated, via a DMZ, from the enterprise's internal network and transaction and data services and, more importantly, from the potential attacks and threats found on the Internet.

In this example, it's seen that an Internet-banking customer can access the bank's Web site to transfer funds from a savings account to a checking account. The bastion firewall will thwart attacks from the Internet while allowing legitimate customers to safely access and manage bank accounts via the Web server. The choke firewall provides another layer of protection or level of indirection by only permitting the known Web server to pass traffic through to the application server. All other traffic would be stopped. There's no communication path for a malicious user or any malicious code to get through the DMZ, since there's no networking path from the bastion firewall to the choke firewall.

A personal firewall can be deployed in a separate image for purposes of isolation, or it could be integrated into the image it's protecting, much like the firewall used to protect individual workstations.

Peter Spera is a senior software engineer with IBM. Peter can be reached at spera@us.ibm.com

Advertisement

Buyers Guide

Search our new 2013 Buyer's Guide.

Search Companies


Search Products


Advertisement

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link

Related Articles

A Perfect Union

Features | New encryption facility for z/OS strengthens mainframe bond.

Avoiding Security by Obscurity

Trends | Data security is not just an IT department issue.