SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Security Basics: Defense-in-Depth

In my security presentations, another basic I talk about is defense-in-depth. The idea here is to produce multiple layers of protection against a particular attack. For instance, imagine malicious code against your home computer. This is a case where you likely already practice defense in depth, as this illustration shows.

Defense in Depth

Now if you're using a Mac or if you aren't using Vista or if you're using Firefox with NoScript there may be more or less or slightly different layers. But hopefully the picture conveys the idea. Some attacks will get stopped right away. But other attacks, might require multiple layers. For instance, a worm that tries to infect via RPC but can also be triggered by starting an executable would require all the layers, and in some cases even that may not be enough (for instance, if the user double clicks said executable before AV definitions become available and accepts the prompt by the Vista UAC to run as an administrator). Blaster and its variants come to mind right away, though they proceeded Vista. The idea is that the more different layers we have, the more ways an attack is going to have to work or the more security measures that attack is going to have to beat in order to be effective.

With respect to SQL Server we can put multiple layers in place. Here are some ideas:

  • Hardware firewall segmenting SQL Server off from other systems (with the exceptions of domain controllers)
  • IPSEC policy requiring encryption and being from the right IP to connect to the SQL Server.
  • IDS/IPS monitoring for suspicious activity.
  • NAC/NAP in place to ensure only authorized systems are allowed to be on the network in the first place.
  • Valid credentials to logon to SQL Server if you bypass all of that.

Now these layers don't help us if a web server with access to the SQL Server is compromised, but hopefully defense in depth has been practiced there, as well. But what it does do is make it that much harder for a rogue system on the network to do any direct damage to the SQL Server. There is always the possibility of coming through shared components (in this case the domain controller is the weak link), but if the DC is up-to-date on patches and the IDS/IPS is up to snuff, it may be very difficult to exploit that system to get around to the SQL Server. That's why we should plan a strategy that involves defense in depth when considering the security architecture for a system. We want to make it as difficult as possible for an attack to succeed while still staying within the constraints of what business has provided for overall security of a system.

Another reason to consider defense in depth is when any one control isn't particularly strong or is flat-out missing. For instance, if a third party application has a hard-coded and weak password for a SQL Server login (I've seen it), then the valid credentials to logon just isn't there. After all, anyone who owns the application (or has supported the application) has that login/password combination. As a result, the IPSEC policy restricting what IPs can connect, along with the hardware firewall doing the same thing, and the NAC/NAP ensuring that a rogue system can't grab that IP may all be what we call compensating controls to counteract that login weakness.

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.


Posted by Roger Reid on 6 May 2009

Your last paragraph is an important one, and I'm not sure it's well understood by non-database IT staff.  The third party vendors usually play fast and loose with this.  The most common variation is "everything connects with a single login and password with DBO rights on the database", and it's usually pretty easy to find the password.  Thankfully, most are no longer insisting on ServerAdmin rights - in theory the worst anyone can do is limited to the confines of the database.

But injection attacks usually work by gradual escalation.  In this case, we may have locked the main safe, but we've left the gate, the front door, and the door to the safe room open, giving an attacker a big head start.

Even when you know they won't change it in the current release, we need to keep complaining to vendors who don't create a few basic roles and run their app/db interaction with least privilege practices.

Thanks for a refreshingly brief, to the point article.

Leave a Comment

Please register or log in to leave a comment.