Externalizing DMZ-as-a-Service

 We’ve been having a great “cloud DMZs” discussion. It started with a blog post from Ivgeni Broitman at Sentrix titled The DMZ Is So 1998 – Welcome the Cloud DMZ. Broitman begins by asserting DMZ’s have a soft spot: “Organizations frequently place business-critical infrastructure within the DMZ which means that attackers able to enter the DMZ can inflict substantial damage to the overall network.  A more recent approach is to implement a secure DMZ below the traditional DMZ, which creates an additional security layer. And yet – we find that when a website is attacked, all DMZ layers frequently fail, along with the on-premise network, because the infrastructure is shared by both.”

Source: Sentrix

Broitman argues that: “A more effective approach is a Cloud DMZ: a functional replica of the original website which serves a significant portion of the requests to the original site and creates an additional security layer.” Digging deeper into what Sentrix actually does, a datasheet explains it scans the customer website and creates security policies for business-critical web components. It replicates significant parts of the website and serves them from a secure cloud replica. Sentrix can also provide some DDOS protection and it whitelists requests that get passed through to the customer infrastructure.

Concerns with Cloud DMZs

I recently inherited the ownership of the 6,800-strong Security Architecture group on Linked In. There we constantly see blog posts like Broitman’s and can enjoy picking things apart in discussions. A few of my group colleagues raised a number of questions and concerns about cloud-based DMZs:

• What SLA’s can the provider actually provide? 
• How is control of data, infrastructure, and applications really managed?
• What if VMs are over-subscribed? How can you troubleshoot performance problems?
• Every layer that is over public networks provides a new target point for hacking attacks.
• To assume that simply moving to a “Cloud DMZ” will magically solve all internal DMZ problems in and of itself goes a little too far.

I personally commented that the exposure question might be moot since premise-based DMZs are also by definition exposed to the Internet. What new attack surface does moving all or part of the DMZ to the cloud introduce? We need to look inside to see what the cloud DMZ is actually doing. And there I do find some concerns. For scalability, a cloud service provider (CSP) most likely runs atop Amazon Web Services (AWS) or another some other operation, which by the way, provides the anti-DDOS piece. Then, to allow the customer to scale its services, the CSP must also isolate between customer tenants and provide a high level of automation. There’s a lot of moving parts.

Because cloud services attain their low cost and scalability by automating out human administrators, human review, and separation of duty (SOD) a key aspect of providing cloud DMZ assurance would be re-injecting just the right amount of friction into the automation. Otherwise attackers could overrun multi-tenant cloud-based DMZs due to the same problem Broitman cited with traditional DMZs: “We find that when a website is attacked, all DMZ layers frequently fail…because the infrastructure is shared by both.”

Is Connecting DMZ Layers through SSL a Bad Idea?

In addition, someone raised the concern that once you externalize the DMZ you now have the connection to your soft gooey applications exposed with only SSL for protection. “But 2014 was a horrible year for breaches into SSL: First Heartbleed, then Shellshock and later Poodle…“

Granted. But all is not lost. A Cloud DMZ would connect to private enterprise networks, or sites, through encrypted/authenticated connections that aren’t so exposed. Use of a dedicated line might be offered as an alternative to SSL. I don’t think the nature of the connection is the problem so much as the multi-tenancy inside the cloud DMZ which potentially introduces internal attack surfaces. In general, I like to say that all else being equal CSPs need to provide MORE assurance than enterprises in order to deliver the same level of security. Broitman hints that Sentrix might have some creative solutions for protecting itself: “A website implementing a cloud-DMZ can sense an attack in advance and create a decoy location to protect itself against hackers.” 

Conclusions

Finally, two other commentators in the Security Architecture thread observed:

• “My conclusion is that for many companies that do not have the expertise, infrastructure or funding to build out a solid defense-in-depth solution, the cloud DMZ will be a good place to land as long as they have all the needed SLAs, liabilities, penalties, and regulatory issues worked out in their contracts and can enforce them.”
• “Moving web apps to an external/Cloud site can be an effective means for achieving many of the benefits indicated, but caveat emptor applies. It’s also generally true that a ‘Cloud DMZ’ does not necessarily eliminate the need for an on-premises DMZ, so it will typically be an “in addition to” rather than “instead of” the on-prem DMZ implementation.”

Please add comments below to continue the discussion here.