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

Security Is Your Responsibility

My primary responsibility at my organization is no longer to be the security architect and incident response team lead. I went back to my love of databases and do SQL Server work day-to-day. However, once you're in the security world, it's hard to step completely out of it, even if you want to. I don't, as security has been an integral part of my life for as far back as I can remember. And thus while my primary responsibility is as a DBA, I still keep an eye on things related to what I used to do. So should you, even if you don't have a security background. You might be the one who will spot something others will miss.

On Friday, I saw something get proposed that immediately drew my concern. I figured that the folks involved probably didn't get the right security people involved and didn't understand the risks of what they were proposing. As a result, I made the decision to reach out to the right folks to begin a discussion of what was proposed. A couple of emails back and forth and I realized that I needed to give a technical explanation as to why I flagged it and what it could mean. I did that, complete with the executive summary and the more detailed technical analysis including threat vectors. The issue had to do with a web browser configuration, not with SQL Server. So why did I jump in? This isn't a DBA's role, after all.

No, it's not, but it's security. And the way I've been trained is that security is everyone's responsibility. The watchers can't see everything. They may not be included on everything. And even if they are, they may have so much on their plates that it helps when someone flags an issue for further investigation. In your organization, you are responsible for security. It may not be part of your job description. It may not be even talked about. But if the culture around security is going to change, it's going to take everyone. It must be everyone. Let me explain.

When I was in Iwakuni, Japan, back in the 1980s because my father was stationed there as a US Marine, as a dependent, all of 10 years old, I remember when they would talk to us about security, about the need to be ever watchful, to report anything suspicious, to know your surroundings, etc. This was Japan, where the crime rate is almost non-existent. However, there was known threat at that time, called the Japanese Red Army (or simply Red Army, as we called it), that could potentially go after US military bases, US military personnel, and their dependents. Case in point: shortly before I left Japan the US embassy in Tokyo was hit by that homemade rocket. They never proved who did it, but suspected was the Red Army. The reason the military was training us kids, too, was there were places we were the most familiar with: school playground, the Little League field, the soccer field on wingside, etc. We knew what was supposed to be there and who was supposed to be there better than the military police (MPs) who might patrol because those were our hangouts. And so if something was amiss, chances are we'd be the first to notice it. But what then? And so they were teaching us how to alert the right folks.

There are things in your organization you are more familiar with than the security personnel. It stands to reason if something is out of place, you're going to be the one to notice it. That's why everyone being involved in security is so important. You will flag what that security person will miss. The only way they will know it's an issue is if you raise it up as one. Even if it's not directly your area, you may have had prior knowledge and experience that allows you to see something that they will miss. My security architect and incident response background allowed me to flag the issue immediately, without thought. The problem I saw I knew could be exploited and fast. So I flagged it and got it in front of the right folks. Now it's up to them to handle it. That's our responsibility if we're not primarily security folks: we note the issue, we flag the issue, we explain a bit why we think it's an issue (so they can make a judgment call on what we've flagged), and then we let the security personnel handle it. In this way we contribute to the overall security posture of our organization.


K. Brian Kelley - Databases, Infrastructure, and Security

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


No comments.

Leave a Comment

Please register or log in to leave a comment.