Ideally, it’s good to start thinking about how you’re going to lock down your systems before you deploy them, or at least early on in the process when possible.
You may have noticed, however, that there aren’t many resources for hardening SQL Server 2008 R2. Well, I never thought I’d say this, but it could be argued that the word “hardening” is no longer relevant on systems like R2 that ship relatively secure. Perhaps it’s better to take advantage of the bundled security features and tweak them to your liking.
It all begins with knowing what’s at your disposal. For starters, it’s important to understand the basics of SQL Server 2008 R2. Microsoft’s SQL Server 2008 R2 Reviewers Guide contains some good introductory material on how you can benefit from R2’s new security features. In fact, you actually enable many SQL Server 2008 R2 security settings during installation. From feature selections to server configuration to database engine configuration, your choices for things like default services, service accounts and authentication mode will impact the long-term security of your system. Of course, so will your Windows domain policies and database patching practices.
Going beyond the basics to more widely-accepted standards, there’s nothing out yet on SQL Server 2008 R2 specifically, though the U.S. Military’s Security Technical Implementation Guides and Checklists are an additional resource on database security. Also, keep your eye out for the Microsoft Security Compliance Manager toolkit where SQL Server 2008 R2 security guidance may be published.
Once you understand the security basics, you’ll need to take things a few steps further by validating where your SQL Server 2008 R2 security stands. The best way to do this is to perform an in-depth vulnerability assessment. As far as I know, there are currently no commercial vulnerability scanners with support for SQL Server 2008 R2. If we keep the pressure on vendors like Application Security Inc. and NGS Software, however, I’d expect to see solutions soon.
In the meantime, check out Chip Andrews’ SQLPing tool to help you get started and find live SQL Server systems on your network. Note that when using SQLPing, SQL Server 2008 R2 will show up as 10.5.x. You can also perform manual checks and run generic vulnerability scans from vendors like Qualys and Rapid7 to look for the low-hanging SQL Server fruit.
The ultimate outcome of locking down SQL Server 2008 R2 systems is that you’ll have a solid footing that prevents people from manipulating your systems. You also want to have the greatest amount of visibility and control over the security of your data. By doing so, you can be on good terms with your auditors and regulators when the time comes to walk the walk.
I’m not seeing a lot of SQL Server 2008 R2 in production yet, but almost every SQL Server-based system I evaluate in my work is running with the defaults. This is not a good thing at all with earlier systems like SQL Server 2000, though things got a lot better with SQL Server 2005 where things were locked down pretty well out of the box.
Finally, I believe that Microsoft has gotten it right with SQL Server 2008 and SQL Server 2008 R2. That said, you can’t be passive and assume all’s well that Microsoft secures well. You still need to devise a plan for how you’re going to move forward with a more secure SQL Server environment and be done with it -- once and for all.
ABOUT THE AUTHOR
Kevin Beaver is an information security consultant, keynote speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored eight books on information security including Hacking For Dummies now in its third edition. He's also the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at his website www.principlelogic.com.