The DMZ's not dead

When the "Exchange Ranger" came for a visit at a client site, his advice set the ball rolling for a much-needed upgrade from Exchange Server 2000.

But when it came time to plan out the details, the network guys balked. Buried in the proposal was a recommendation to open a wide swath of internal firewall ports between e-mail services and the message store, essentially collapsing the inner network security barriers. The consultant's explanation? "The DMZ is dead."

That's not what the network guys wanted to hear, and I thought about the exchange again last week as comments circulated regarding Microsoft's recent acquisition of the health record search provider Medstory. While most of the conversations swirled around whether it's a good idea for consumers to host their data with this kind of provider, I wonder how small and midsize health providers will write their applications to work with it.

When Microsoft first pushed the health care components of BizTalk Server, the early .Net application security architecture was wanting. However, there was evidence of at least lip service to the idea that splitting applications into three tiers was a good idea. This separated the client (which could be malicious) from the data and potentially abused business logic by inserting a middle layer of interface management and input validation.

The philosophy of Defense in Depth is based on the idea that stuff invariably fails or is cracked, and it ought to take more than one breach event before control is lost over data or processes. But with this "dead DMZ" talk, the industry seems to be inching away from that idea -- and toward potential trouble.

Improving application security

Microsoft's headfirst dive into service-oriented architecture (SOA) had some interesting implications. If one reads any selection of recent Microsoft developer documentation, much of it reflects the company's internal top-down push for improved application security. By starting with business requirements and mapping them to software components in a consistent service architecture, tighter access control is possible all the way from client to the very back-end data or communication services.

Microsoft has made great strides in application security, to be sure. While placing an ISA server on an unfiltered public Internet connection may still be a sign of a gambling problem, most Microsoft products have progressed from laughable to genuinely securable, and fresh installations of server products no longer include every possible service turned on and a smorgasbord of default passwords. Even for the end user, Microsoft's stepped away slightly from its steadfast assumption that all the world uses Internet Explorer, a boon for those who don't wish to attempt privacy suicide.

The development framework has kept pace for the most part, allowing organizations to customize or develop their own corporate applications that integrate tightly with the .Net SOA. For example, the "Connected Health Framework Architecture and Design Blueprint" shows the path to developing highly modularized application services that fit right in with the off-the-shelf ones.

Zero-sum network security?

Encouraging the collapse of network security controls to allow for tight integration between off-the-shelf and customized systems hosting SOA applications has an unfortunate side effect. In short, the inner firewall of the DMZ becomes Swiss cheese, and servers in the DMZ host much more than interfaces and input validation processes.

We find such things as active directory services and domain member servers in what used to be the DMZ, along with Microsoft "Web Service Enhancements" such as WS-addressing -- which controls something akin to static routing of messages between servers and services.

I'm glad Microsoft's taking application security so seriously, because we're creeping back to a two-tier network security model. Sure, most .Net development diagrams show multiple layers of services with authentication between each level, and it looks like an onion-skin of security. In reality, though, it's often a monolithic model with single modes of authentication, and requires clusters of servers logically located so the compromise of one may be very bad news for all.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark