As such, there needs to be some type of barrier between it and your corporation’s inner sanctum, which hosts the applications that allow your business to function.  The examples are countless, but would include human resources files, proprietary data, as well as general business information which can be (more or less) shared freely within the organization, but should not leave the confines of the corporate intranet.  

Most of us should be aware of the fact that there is a de-militarized zone, or DMZ, between North and South Korea.  The DMZ is a “no man’s land” between the two countries.  Spanning 2.5 miles, there is pretty much nothing there.  A specified number of troops, carrying only specified weapons, may patrol it.  In contrast, the boundaries—the theoretical lines 2.5 miles apart—are heavily fortified.  Unlike this real-world DMZ, a network’s DMZ would not be empty, barren, void of everything.  (OK, technically there are buildings within the DMZ.  Work with me!)  It will have servers which perform various functions.  But since both are heavily fortified boundaries, the term DMZ does present a good metaphor.

As often is the case, the definitions and designations are somewhat fluid.  Typically, though, your network will be arranged like this:

1. The border firewall,
2. Web and email servers, in the outer DMZ,
3. A middle layer, often called the inner DMZ, which hosts applications which process requests coming from the Internet to access your sensitive data, and
4. The sensitive data, stored on servers in the back-end, or core, network.

To maintain the confidentiality and integrity of your data, you should prohibit direct connections from the outer DMZ to the core.  All requests for data should “land on” one of the middleware applications in the inner DMZ, which then can query the core system.

Next time: Host hardening