I just saw this, but you should be aware. There’s a potential Denial of Service/Elevation of Privilege bug in SQL Server. Here’s the bulletin:
There are QFE and GDR patches for versions since 2008, but you need to read carefully to determine which one to install on your systems.
Today’s editorial at SQLServerCental is entitled: We Don’t Care about Data and IT Security. It’s by Brian Kelley (author, blog, twitter), and I think it’s worth a few minutes of your time to read.
It’s aimed more at executives, and certainly talks about the disconnect between actions and words. People talk about security being important, but rarely seem to make fundamental changes that might improve things.
I tend to agree, though I also think it’s not as cut and dried, and often we have a disconnect in what we really want or need from security. Do we need chip-and-pin cards v our signature ones? It’s arguable that the former are more secure, but there have been incidents, and without a doubt the large scale of the US credit card market would mean more and more attacks. There is an argument that the devil we know is better than the one we don’t.
However there certainly are not great coding practices in many organizations. I think we far, far too often do not train or show new developers how to code more securely. We also don’t require older developers to change their habits to implement new techniques that limit issues. We also don’t bother to review code that consultants write and require security. It’s far too easy to “just get it into production” for many people.
Overall, I tend to agree with Schneier and Brian in that we need to rethink security in our languages, but also fundamentally in how computer systems work. We also need a culture of security, something that won’t take place until we mature as a digital civilization.
At SQL Bits this year I attended a security presentation from Andreas Wolter. The session examined some attack methodologies, showing the flow that an attacker might go through to gain information about your database instance with SQL Injection. It’s a scary and eye-opening talk, and one that I might recommend to all DBAs and developers so that they can understand the dangers involved with poorly coded applications.
One of the most scary attacks was the elevation of privileges from a web user to a sysadmin on an instance, mainly because of the Trustworthy setting being enabled. I had never imagined this as an attack vector, but it was disconcerting to say the least. However it got me wondering about instances I’ve managed.
Would I detect if a new sysadmin were added? Or an existing user added to the role? I’m not sure I would, though that’s certainly something I plan on setting up with some sort of monitoring to detect. I would guess that most DBAs, whether professional or accidental, might not catch this either, at least until some audit was performed. At that time it might be too late to protect your data, and certainly too late to protect your reputation.
Security is a tough topic, and it’s an ongoing process to protect your systems. I hope to see more presentations like this at future events, and I’d encourage you to request them for any events you plan on attending. You can certainly do this for all SQL Saturday events (there’s a suggest a session on the schedule page).
Security requires vigilance and vigilance requires monitoring. Both of those also need knowledge, so be sure that you don’t neglect the security of your SQL Servers and continue to educate yourself over time as well as implementing technical solutions.
Steve Jones
Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and LibSyn. 
The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
This is not how you handle things. When you find security issues, and they don’t get fixed, it’s one thing to attempt to prove a point with a PEN test. It’s quite another to publicly expose information. You might find yourself in trouble, and you should be in trouble. This is a violation of the professional responsibility you undertake when working for someone.
This is the type of frustration that occurs in many IT workers. I’ve seen more than a few people working in technology that are sure they know how to properly configure and manage an application. They know how to set up security, and they become upset with a company that doesn’t do a good job of running internal systems. They know that the architecture chosen for their application will fail when a load is applied.
There are some smart people in IT, but sometimes they think they’re smarter than they are. Bad design, bad decisions, mistakes, even poor security practices will occur. However it’s usually not your company, and it’s not your place to prove that there is a flaw in a system. It’s especially true that it’s not your place to prove things without having been given permission to do so. Proving a point on your own is something children do, not professionals.
When you find problems in your organization, it is your responsibility to report them. I hope you think it’s your job as a professional to do the best job you can, following the best practices as we know them. It’s also your decision to choose to leave a job if you can’t go along with, or abide by, the decisions made by your management.
If your company has chosen poorly in their technology decisions, I understand your frustration. I’ve often shared it, but I’d advise you to do what I’ve done. State your objections and either support the chosen path or find another job.
Steve Jones
Listen to the MP3 Audio ( 2.3MB) podcast or subscribe to the feed at iTunes and LibSyn.
The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
Voice of the DBA 