When you're in charge of a company's security, you'd better be on the approval list for resources placed in the DMZ.
The DMZ is the portion of a network that exposes applications and infrastructure to the world. Typically, it contains things like corporate websites, storefronts, VPN concentrators and Outlook Web access.
Before I came to this company, any server placed in the DMZ had to be available to the public Internet. Now, that's a scary requirement. Since my arrival, I've expanded the criteria considerably.
Although we have no storefront and only one main corporate website, an Nmap scan of our externally accessible DMZ resources yielded almost 50 individual items. And many of those resources were unknown, unpatched or lacking in even basic security configurations. That sort of thing is great ammunition when I'm criticized for my in-depth interrogations about new candidates for the DMZ or modifications to existing DMZ infrastructure.
In sticking with my No. 1 philosophy, most of my questions relate to the rule of least privilege. For example, I almost immediately ask, "What will this resource be used for, and who will need access?" One time, the answer to the question about access to a server was, "Just two of us." I was able to convince them that an internal development network was a better place for that server.
For those servers that do make it into the DMZ, I try to restrict availability to ports 80 (http) and 443 (https). Prior to this rule, we had all sorts of ports open in the DMZ, including Remote Desktop, which is probably the top method for unauthorized access. I've also created a security baseline using data gleaned from various websites. For example, the Center for Internet Security has some decent security configuration documents and tools for various devices and operating systems.
All DMZ resources must be managed, meaning we can do inventory tracking, configuration management, security patching and so on. Of the 50 DMZ resources identified in my last audit, only eight were managed.
Next, if there's no need for a DMZ resource to communicate with a back-end server (aside from monitoring, log management and general administration), then the firewall should block access.
I also want every DMZ resource to have an identifiable business owner. My investigation of current DMZ resources revealed that more than 15 servers and associated applications had no identified owner.
I also require that certain security, application and event logs must be enabled for all DMZ resources, and they must be configured to send logs to our security event and incident management tool.
I also found that we had research and development DMZ resources (otherwise known as lab machines) comingled with production DMZ resources. I immediately had the network team create a separate virtual LAN and protect that segment with the DMZ firewall. Lab resources are sometimes considered the Wild West, and I wanted to ensure that there were strict controls protecting the production DMZ as well as the internal network from the lab resources. The challenge here is that sometimes a lab resource needs to connect to a machine on the internal network for business reasons. Each case has to be tackled individually.
My next task is to take these and other requirements and author a DMZ policy. In setting up policies, I have to take into consideration where the company sits on the overall security spectrum. I recognize that if we enabled all security settings, resources could be rendered unusable. The trick is to strike a balance between security and usability based on what's at stake. This is otherwise known as risk management.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Join in the discussions about security! computerworld.com/blogs/security