Designing a secure DMZ

For more information on the term DMZ, see the previous article here: What is a DMZ?
In this article, we will cover the steps in designing a secure DMZ (demilitarized zone). The idea behind the secure DMZ is that your company has certain assets (web, mail, FTP, DNS, etc) that need to be accessible from a public (untrusted) network while still maintaining a certain level of security of these assets and your secured private (trusted) network. By placing the assets in a secured DMZ, only approved access as outlined in the companies security policy is allowed into the DMZ from both the public and private networks making the assets less vulnerable to being compromised by an attacker from the public network than if they were just placed directly on the outside network. At the same time, the secured DMZ ensures the integrity of the private network since no security holes will need to be opened in the firewall to the private network for access to these assets.

NOTE:

Any time that systems are accessible from an untrusted network there is a possibility that the host(s) can be compromised by an attacker. The host(s) could then be used to gain access to private data which can be manipulated and, or defaced. The host(s) could also be overwhelmed by bogus requests exhausting system resources and therefore denying legitimate requests for services (DoS - Denial of Service). The hosts could also be compromised by an attacker and become drones to launch distributed denial of service attacks (DDoS) on hosts in other networks.

That being said, it's very important that you maintain a strict security policy that only allows required services to the host(s). The host(s) operating system and software should also be kept up to date by patching them for any known vulnerabilities. The host(s) and the DMZ network should be monitored by virus/intrusion detection/prevention to detect, inform security staff and possibly prevent potential attacks to the host(s). And perhaps the most important part, the host(s) and DMZ network should be tested for potential problems on a regular basis and the host/network security should be improved and documented in the security policy based on those tests.   
Now, we will design our secure DMZ using a phased approach to ensure that we cover all the bases:

Phase 1: 

Identify the assets that require outside access and the target value of said assets.
We will need to identify the services that we need to provide public network users and come up with a target value rating based on the importance of the service. This will come in handy for developing your disaster recovery/countermeasure plan in case the host(s); were compromised, as well as tuning your intrusion detection/prevention signatures on a per host(s) basis to minimize false positives and maximize true positives.

Phase 2: 

Outline the required protocols, hardware requirements, operating system, and software for outside access to the assets derived from phase 1.
It's important here to do research such that you can make use of the most secure protocols possible when giving the public access to your services. You should also ensure that your host(s) is running the most secure operating system software available to provide said services. Lastly, you should insure that the hardware is robust enough to handle an attack long enough to be detected and stopped prior to the host(s) exhausting all of its resources and being rendered inoperative.

Phase 3: 

Modify your current security policy to accommodate public access to the assets outlined in phase 1 and apply strict guidelines for securing these assets based on the technology required (OS, services, protocols, hardware, intrusion detection/prevention, etc). Patch the host's operating system along with the software running on the host(s) for any known vulnerabilities. Test security of the host(s) and DMZ network on a regular basis. Improve the security on the host(s) and DMZ network based on the previous test results and develop a disaster recovery/countermeasure plan in case these assets become compromised.

It is very important to have a documented security policy for your network with different sections for different types of access and zones of security. A good security policy is the backbone of any well designed and secured network. This will serve as the basis for any future designs and implementations in your network. The security policy will also outline the groups responsible for certain assets and what sort of actions will be taken if a host is compromised both technically and legally. This security policy should always be kept up to date based on emerging threats, vulnerabilities and any potential problems that might be uncovered by regular security testing. In turn, network security should be improved based on the updates made to the security policy.
Phase 4: Build and secure the host(s) by making sure the host's operating system and software are updated, protecting it from any known vulnerabilities and by removing any unnecessary services from the host that could be used in an attack to compromise the host as outlined in the updated security policy.

Phase 5:

Assign and document required public and private addressing space for the DMZ network.
Make sure that you use good design guidelines allowing for future growth when following phase five. Once the systems go into production it is much more difficult to readdress hosts and network devices and change firewall configurations while maintaining an acceptable level of availability if you don't have enough available address space.

Phase 6: 

Configure the DMZ interface and required static network address translation based on the information derived from phase 5, along with the required access rules in the firewall based on the updated security policy.
It’s a good idea to perform a certain level of pinhole testing on the new network configurations prior to going live. This way any required changes can be made to the design and security policy without any critical downtime.

Phase 7:

Implement any extended security measures outlined in the security policy like virus/intrusion detection/prevention.
In most cases, these days virus protection is not enough, specifically if high availability is a strict requirement. Virus patterns and OS patches can only be written once a virus is detected and due to the rate of speed that today’s Internet worms can spread chances are you can be infected prior to the availability of these patterns and patches. These days less skilled coders will take a previous version of a virus, worm or attack and change it slightly to work around virus patterns, access rules, and security patches. Due to this, many types of virus, worms, and attacks can be detected and prevented with a good mix of intrusion detection and intrusion prevention systems based on pattern matches from previous threats.

Phase 8:

Configure the host(s) for secured communication on the DMZ network based on IP the information derived from phase 5 and the security device implementations in phase 6. Then place the hosts in the DMZ network VLAN, PVLAN or physical segment.

Phase 9: 

Test access to the DMZ host(s) and run another set of security tests from the public (untrusted) side of the network on both the DMZ network and the host(s). Use the network topology documents, security policy and testing tools to tune your IDS/IPS signatures to minimize false positives.
This concludes the article on “designing a secured DMZ”, I hope you’ve enjoyed it and learned something along the way. Watch for the third and final article in this series “configuring a secured DMZ” that will be coming soon.