The recent spate of breaches and attacks targeting various business and government computing systems drives home the message that our (collective) systems are at risk from threats both internal and external. As a database professional, I'm inclined to believe our databases are at particular risk, and here's why:
With this in mind, I am speaking with folks about ways they can improve the security of their database applications built upon Microsoft SQL Server. My objectives are to:
In order to engage a broader audience, I am providing much of this information here as a series of blog posts organized around the high-level practices that should be employed. As entries are posted, I'll convert each of these practices into links to make accessing of this information a bit easier:
Before jumping into specific topics, it's important to note that Microsoft provides guidance on meeting specific security standards. Here are links to the ones of which I am aware. (If you are aware of others, please let me know and I'll work to get them posted here.)
The guidance above and many of the features I'll present in subsequent posts flow from a combination of customer-demand and a commitment to security established following some high-profile failures in the early part of the last decade. Following those incidents, Microsoft now develops all products using the Security Development Lifecycle (SDL) process (which can be adapted for use in your organization).
For SQL Server, the SDL and the overall commitment to security has meant a dramatic drop in the number of vulnerabilities relative to both earlier releases and competitor database management systems. For very security concious organizations, this has meant the adoption of SQL Server for many of their mission critical applications.