How do you explain to experts that a database server should not reside in the DMZ?

Question

Our security experts, database administrators, network team and infrastructure team are all saying it's OK to have the database server located in the DMZ along with the HTTP server and middle-ware server.

Their reason:

If the database server is compromised (because of an insecure middle tier), at least the database server is outside the internal system. If it is inside our network, the hacker can then use the database server to access other systems.

What they are saying is:

1. Let's not put the middle-ware server behind a second firewall and the database server behind a third firewall.
2. Let's use just one firewall (the HTTP server's) in case a hacker wants to get our database's sensitive data, at least that's all they can get.

The second statement was actually said... verbatim.

Please note that this database server will hold sensitive information, including bank details.

Now, are these experts making any sense to you? I'm a software developer, and I can't get their logic. It's like, "Put the jewelry box outside the house so that robbers won't bother getting in for the TV?"

Answer 1

SANS' "Making Your Network Safe for Databases" (http://www.sans.org/reading-room/whitepapers/application/making-network-safe-databases-24) reads a little dated in some sections, but provides a decent "for dummies" level of guidance in the direction you're after.

You could also exhaust yourself poking through the US NIST's resource centre (http://csrc.nist.gov/). I think ISO's ISO/IEC 27033-2:2012 would be on topic too, but don't have a copy at hand to be sure.

You're trying to separate/isolate the most sensitive servers (the database servers) from the most exposed (and therefore vulnerable).

You're proposing a "defense in depth" approach, that seeks to a) prevent attacks where possible, and b) delay their progress (and access to the important stuff) when not.

Ideally, everything is always hardened and patched, servers only listen for traffic on required ports, and only from allowed devices, all traffic "in flight" is inaccessible to unauthorized listeners (through encryption and/or isolation), and everything is monitored for intrusion and integrity.

If all that is in place with 100% certainty, then great, your "opposition" have addressed point a) above, as much as is possible. Great start, but what about point b)?

If a web server does get compromised, your proposed architecture is in a much better spot. Their potential attack footprint, and vector, is much larger than it needs to be.

The justification for separate database from web servers is no different than the justification they've accepted for separating web servers from LAN. More bluntly: if they're so convinced a compromised web server presents no danger to other systems in the same security zone, why do they think a DMZ is required at all?

It's awfully frustrating to be in your situation. At the very least, in your position I'd create a risk memo outlining your concerns and suggestions, and ensure they acknowledge it. CYA, anyway.

Answer 2

It's like, "Put the jewelry box outside the house so that robbers won't bother getting in for the TV?"

Yes, it is exactly like that.

If you don't care about the value of the database, relatively speaking, then sure it makes sense to leave it outside - if the assumption is that the application is horridly insecure, but you need to put it up anyway for whatever reason, and don't want to secure it, then this is makes sense as a way to isolate this horrible insecure system from all the other internal systems.

On the other hand, there really is no excuse to expect to have SUCH an insecure application that allows complete database server takeover. Also there is no real reason to use "exposure" as an alternative to "isolation" - there are simple solutions to do that right too.

When it comes down to it, it sounds like this is one of 2 possible situations:

1. These so-called "experts" are really clueless.
2. There are other business requirements that are being traded off here.

I think your analogy works perfectly. If they then tell you the equivalent of "Actually, those jewelries are fake, oh and btw the TV is really a 60" 5K custom job with gold rims", then that might be a sensible tradeoff (still better to do it right, though).
Otherwise, it's likely that there is no way to explain it, since they are working from a lack of knowledge.

Answer 3

If the database holds card details, it can be very easily argued that you aren't fulfilling the PCI DSS requirement on appropriate protection.

It also fails the sanity checks on single points of failure, and protecting your core assets.

If the data is worth billions, why would you not spend a few thousand more to add layers of protection? Industry good practice is to have layered security zones.

You could point them at PCI, ISF's Good Practice Guide and many others.

Answer 4

If you are suggesting that the database server gets moved from being in the same security zone as the web server to being in the same security zone as some internal systems, then one could reasonably conclude that you are reducing security.

If status quo is that web server and database server are both in the DMZ, and no connections are permitted from DMZ to internal network, then moving the database server from DMZ to internal network would require allowing connections from DMZ to internal network. That would mean you are reducing the security of the internal network without getting significantly better protection for the database.

If you truly believe that the database is more sensitive than the internal network (which may very well be true), then you wouldn't want any compromise of the internal network to get direct access to the database.

So the point you need to make is, that you don't want to move database server from one security zone to another, instead what you want to do is to create an entirely new security zone. To really follow through on that you would actually have to buy an additional firewall and put that between the DMZ and the extra secured network.

Then it boils down to evaluating the cost of buying and maintaining this additional firewall against the additional security it provides.

Answer 5

AvID has already covered the main question, but coming at this from a slightly different angle most firewalls will support multiple interfaces and can provide control of traffic between the interfaces.

Configuring the multiple interfaces to host each of the aspects of the solution (frontend, middleware, backend) would reduce the risk of onward compromise of the database from the web server without necessitating multiple physical firewalls (if that is what the other teams are worried about...is it a cost issue?) and without introducing a route to the internal network.

Just wondering whether this would give you a practical 'lever' to support the argument for implementing some separation i.e. it brings something different to the discussion that they have to counter?

Failing that what about a what-if scenario based on an historic web server vulnerability, which would have resulted in onward compromise of any other server on the same network segment (including the database) and how a layered DMZ would prevent the onward compromise, presumably there would be a monetary cost so it would be 'easy' to illustrate the cost/effort benefit?

Answer 6

Assuming you are attempting to persuade them to do it rather than (necessarily) convince them it is correct:

Explain that when their large customers and prospects come to do a security audit they will fail.

If the obstacle is the business then that will be the only sufficient, and only necessary, reason.

Answer 7

One good argument is that the bar really isn't that high to separate the web servers and database servers into separate DMZ's.

Use a real router/firewall, and put the web servers and database servers on separate VLANs, both of them outside the internal secure LAN, with firewall rules controlling access to the bare minimum required ports from the Internet to the web servers, from the web servers to the database servers, and no access at all originating from the web servers to the secure LAN.

The firewall would also prevent any direct access at all from the internet to the database servers, and tightly control any access from the database servers inward to the secure LAN (for authentication purposes or whatever).

That way, the attacker can't even get to the network containing the database servers directly.

If they get a beachhead on one of your web servers, they're still not on the same network with unrestricted access to attack your database server(s), and if you have any kind of log monitoring in place you should receive notifications about the breach of the web servers before the attackers have had much time to attack anything else.

Even if they then manage to breach your database servers after some period of time through the one open port that the web server gets to use to communicate with the database, they've wasted all that time accomplishing relatively little, during which time you have been aware of their attack, instead of spending all of that time getting into your secure LAN.

They can't even reach the LAN from the DMZ where the web servers live, so their only route into the LAN in any form at all is to hop onto the database servers, protected in the other DMZ. Chances are that your database servers are or will be tied into some kind of enterprisey authentication system (Active Directory or whatever). Do you want that capability in the same DMZ with your public web servers?

If I can be concerned enough about security issues to create guest and DMZ subnets at my home, to have a place to put "things" ("Internet of Things") without having them directly on my LAN, a concern worth billions can surely afford the mindshare and time to do the same thing with important web servers and database servers. I'm doing this at the office with a combination of a stack of several-thousand-dollar Procurve managed L2/L3 switches, a SonicWall UTM and a Ubiquiti EdgeMax router. At home, I have a $100 Ubiquiti EdgeRouter Lite, a $100 managed 8-port HP switch and one Ubiquiti Unifi AP that supports multiple VLANs, and my setup is totally capable of doing what we're talking about.

And I get the peace of mind of not worrying that my network-connected DVR, printer, BluRay player, thermostat and whatever else, running who-knows-what buggy out-of-date firmware with who-knows-what undiscovered exploits, might get hacked and reach out to my computer and personal files over the network.

It isn't super hard for security experts to configure this sort of thing, and it certainly doesn't have to involve separate physical hardware for each firewall. SDN (software defined networking) is all the rage these days, right?

Even the $100 EdgeRouter Lite can forward nearly 1 Gbps through the router, with support for multiple virtual interfaces and firewall rules between all of those interfaces.

One tiny box is really a whole basket full of firewalls.

So if you spend real money on a higher-end router, you'll get all those features and a few more with beefier routing performance.

Even something like the Ubiquiti EdgeRouter Pro 8 gives you 2 million packets per second for only $375, with 8 physical interfaces and VLAN subinterfaces on each of those if you need them. If you need higher performance than that, look to Brocade (Vyatta), Cisco, Juniper, etc. for bigger hardware. Or something like Dell/Sonicwall's SuperMassive series. Or run the Vyatta virtual router on a beefy multi-core Xeon server.

I'm not trying to peddle routers, just making the point that the bar isn't actually all that high to get the kind of security separation you should probably have and obviously want here.

Answer 8

Tell your direct manager that you are not authorized to accept that risk on behalf of the company. Point out that the value of the data in the database is $xxx and that that level of risk acceptance must come from someone authorized to do so, and ask him to champion getting a member of executive management to sign-off on the risk acceptance.

To estimate the value of the data, determine whether it is data tied to PCI DSS (if so, look at the cost-per-customer that Target / Home Depot have incurred in lost sales, credit monitoring, fraud), or if it is PII (if so, look at the financial damage per-patient that the medical systems have incurred in lost confidence, identity theft monitoring, lost reputation), or if it is your company's competitive edge (trade secrets, not-yet-released financials, intellectual property) then the value of the data could be the current valuation of the firm.

If you are given a direct order to accept the risk on behalf of the company, you may be asked to begin acting in the capacity of a company officer, and as such, you have an obligation (possibly a legal obligation) to point out that you are a non-appointed person asked to perform as one, and should brief this up the management chain to the company's board of directors. Be prepared for significant blow-back and to expend significant political capital to make this known.

Good luck!