An Information Security Place

The simple answer to the title is "yes".  However, that is really not the exact question I am asking here.  The question is really "are DMZ’s actually still DMZ’s?"  Let me ’splain.

I had a client ask me the other day if I was seeing a drop in the use of DMZ’s out there.  We had a quick discussion about it, but it got me to thinking more of the concept of a DMZ, the various implementations of DMZ’s (the point of this post is not to get into the security or various benefits of the different models, so I won’t discuss that or make any judgements on which is the best), the progression of the DMZ concept into the zone concept (and even a little further), and if the term DMZ is even really applicable anymore in the larger scope (or if it even matters). 

Oh, and as a note, you might need to take some of my terminology with a grain of salt if you started your firewall experience with Checkpoint.  I started out with Netscreen, so that affects the way I think about networks and DMZ, and zones.  It all comes out in the wash since they are all doing the same thing, but just wanted to give a warning there.  Also, be prepared for rambling as I flesh this out.  It’s my style.

So anyway, to dig in a bit, let’s briefly define what a DMZ is and look at some of the more common implementations.  The rationale behind a DMZ is to place externally accessible servers (such as HTTP, SMTP, etc) on a segment where potentially dangerous traffic can be isolated.  Simply, you don’t want direct external access to your internal servers.  Makes complete sense.  So, how is this implemented?

Some people implement a DMZ by squashing a bunch of servers in between two firewalls like this:

The external firewall controls access from the Internet to your DMZ, and the internal firewall controls access from your DMZ to your internal network.  Traffic may need to flow between your DMZ and internal network, but at least you can control that to a larger degree than just opening up the world to your servers as you must in the DMZ.  This is physically identical to the military term DMZ, which is the space between two opposing army lines.  Each army controls access to their side of the line.

But the original concept of a DMZ generally costs a bit more because of more hardware.  So in comes the concept of using three interfaces.  Basically, with a three interface box, you let the firewall become the single point where all inside and outside traffic flows, as seen below:

This gives you control in a single box, which keeps cost down.  The DMZ is virtual in this case, since it is created and controlled by routing and policies, but the benefit is the same.

But many smart people outside and inside firewall manufacturers started looking at this at started saying, "Hey, why can’t we put even more interfaces on this?"  Basically, they started allowing for more than one DMZ.  So if you had some externally accessible boxes that you wanted to keep isolated from your internal network AND each other, this allowed you to do so without building more firewalls and adding complexity to your network design.

This was the precursor to the concept of zones, where you could create multiple areas where you wanted to segment off traffic with your firewall.  So if you had multiple server farms, you could have a zone for each one.  That is the point where I think the term DMZ becomes somewhat less effective, but it is still realistic if only used in the segmenting potentially dangerous traffic that is coming from the Internet.  It is still not a DMZ in the physical sense (just like the three interface box), but it still serves the same purpose.

But what about those people who put a firewall between internal segments or between two nodes on their private WAN?  As an example, if you work at ABCCorp and your company bought XYZCorp, you might put in a firewall between the companies when you setup a WAN link.  In that case, you probably would rename zones to something more representative, like "ABCCorp_Network" and "XYZCorp_Network".

Here you are not really isolating traffic in the traditional sense in this case because you are creating a wall between the units.  There is likely not an area where you have some isolated servers.  You are simply controlling access between the two areas.  So there is really no trusted or untrusted side (well, I guess that depends on which side of the firewall you are on and who implemented the firewall, but you know what I mean).   This is more like the concept of a checkpoint in more modern urban warfare scenarios.  There is no real DMZ, just checkpoints as you move from one hostile area to another.  That doesn’t exactly fit since there are no distinctive lines in modern urban warfare, but I think there is a decent fit there.  So the term DMZ does not fit.

Now you can go the next step by creating virtual firewalls, with each FW treated as a separate entity with its own policy set, routing table, etc.  But that is generally used in more of a carrier type of environment or a very large enterprise that needs to maintain total separation between units.  Though this setup can be utilized to perform the same function as a DMZ or a zone, it is generally too complicated for that.

But saying all of this makes me also come back to how I view many issues such as these, meaning what terms make sense or don’t make sense, which terms have been outdated, etc.  Though I thoroughly believe that accuracy is needed when defining terms, I also think that in this case the term is not terribly important.  I think the term is still very valid, even if the DMZ is virtual. 

So basically, use the term if you want (aren’t you glad I gave you permission?)  But I think "zone" is really more accurate in how most DMZ’s are implemented today, both in the hardware and in the actual production installs. 

Vet

I am going to sponge off of Michael’s tip at MCWResearch for my tip of the day.  Michael gives some good advice for configuring and managing firewalls (Michael must be old-school security, since firewalls aren’t needed anymore – right….).

He specifically talks about egress filtering, which is something many companies do not take use in their security.  Michael talks about specifically blocking certain ports, but I think you should go a step further and have default deny on all traffic incoming AND outgoing, then open ports as needed.  It makes sense, but many people do not think outbound needs to be filtered.  But as Michael pointed out, allowing IRC is inviting bots to start popping up on your network, and then the bots continue to report back to the IRC server.  They establish the connection, so no inbound port needs to be open for the attack.

Additionally, I suggest Websense or something similiar to block specific protocol access (again, default deny and allow as needed).  This can be another layer that can protect against web proxies and anonymizers and the like so your users can’t try to get around your firewall.

Vet

I have posted a couple of times on how to be a successful security admin / manager (here and here).  Well, here is another one (ok, enough of the groans).

So, here is today’s advice: stick with the tried and true security.  There are methods of security that have been tested for quite a while now and have proven to be very effective strategies.  A few examples of this are defense-in-depth, risk management, and security awareness.  Let’s look at these a little closer:

• Defense-in-depth: Basically, using multiple, varied, and complimentary security systems stacked in layers to defend against attacks.  This is a method that has been shown to be very effective.  The easiest example (though not the best) is to have anti-virus at the servers as well as the desktop so that a virus missed by one may be caught by the other.  Add into this mix a deep-inspection engine that checks the data as it travels across your network, and you have three layers of security (though you would probably want to make the A/V software at the server level different than the brand on the PCs, to actually have three layers, but I digress).

 

• Risk Management: I really like PCMag’s definition of risk management and risk assessment, so here it is:

Risk management: The optimal allocation of resources to arrive at a cost-effective investment in defensive measures within an organization. Risk management minimizes both risk and costs.

Risk assessment:  report that shows assets, vulnerabilities, likelihood of damage, estimates of the costs of recovery, summaries of possible defensive measures and their costs and estimated probable savings from better protection. A “risk analysis” is the process of arriving at a risk assessment, which is also called a “threat and risk assessment.” A “threat” is a harmful act such as the deployment of a virus or illegal network penetration. A “risk” is the expectation that a threat may succeed and the potential damage that can occur.

• Security Awareness: An initiative that sets the stage for training by changing organizational attitudes to realize the importance of security and the adverse consequences of security failure. Further, awareness reminds users of the importance of security and the procedures to be followed (this one came from here).

So, why did I bother to put down these definitions?  Let me explain.  There could be a number of reactions to these definitions, but let’s focus on two:

1. You may have looked at these definitions and started yawning and complaining about old school security, a bunch of washed up geezers, etc.  or…
2. Maybe you started reading them and wanted to see if the definitions put down were accurate

If you fall into camp 1, then you are probably pretty young or you have just started into security or both.  You fall squarely in the camp of those who believe the perimeter is dead and you may think that there will come some day soon (if if it isn’t already here) a device that will once and for all secure your network and let you relax a bit.  You probably think that many of the old security ways (including above) are not needed.  Just throw some money and security devices on the network and you are doing well.

Then there is the second camp.  You saw some old, familiar, comfortable definitions that really speak to you as central tenets of security.  You say, “hell yea!” when you see another example of these methods paying off.  You do you due diligence and either fill the gaps that appear in an assessment or you mitigate in other ways when the risk is not too high.

For the first camp, I say that you need to start paying attention to these old geezers.  These methods have not been around for this long for nothing.  UTMs are not the end-all-be-all.  NAC and NAP are not god-sends.  Many of these new security appliances fill gaps that exist.   But they are meant to do just that – fill the gaps.  Not be the whole of your security.  The perimeter is not disappearing.  It is still there, but it has started to become flexible.  Old school security guys really don’t have an issue with that.  But when you move all your defenses in the network and drop the external firewalls, then you need to be prepared for the consequences.  And they are coming.  The baddies follow trends, just like the good guys.

And new security people: don’t call us old school folks closed-minded.  A better term is experienced.

Vet