Voice of the DBA

Tag: security

  • PVPs

    I had it happen to me. We had an SSL certificate for a website that one of my employers ran. I actually purchased the certificate, and it secured our communications for a couple years until one day it didn’t. The certificate expired and the website stopped accepting connections. If I had noticed, it might not have been a big deal. However when the owner of the company gets a call from one of his large customers, it’s an much bigger issue.

    If you worked at Microsoft last year when their security certificate expired, it was an even bigger deal. It’s not that an affected customer that sends a note; it’s affected, unaffected, and potential customers that hear about the issue from the media. It seems like tracking private virtual properties (PVPs) ought to be easy, but it’s not. As pointed out in this piece, there are a number of issues at an organizational level, and while there are fixes, it takes some effort.

    In many businesses that have periodic activities required for physical assets, there are often people dedicated to tracking, or performing the activity. Mechanics know about maintenance on vehicles, accountants renew leases, workers replace equipment nearing the end of service. Often the time lines and activities involved are understood, and individuals understand their responsibilities.

    This showcases another area in which technology is woefully immature. Need a certificate? It takes a person with specialized knowledge to understand what’s needed, purchase it, and install it. This person either then moves on to a new role without leaving instructions behind, or isn’t well equipped to understand the need to track the expiration and replacement of the technical item. There often isn’t even a system set up to handle replacements of these items, which might be superseded or replaced by some entirely new type of technical wizardry.

    Managing and tracking PVPs is hard, and I suspect, going to get harder. Security requirements increase, technical requirements grow, and specifications change. I’d like to say I’m confident Azure (or AWS or another large service) will never have another outage because of this, but I wouldn’t be surprised if they do.

    Steve Jones

    Video and Audio versions

    Today’s 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.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 20.5MB) feed

    MP4 iPod Video ( 23.9MB) feed

    MP3 Audio ( 4.9MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • The Future of Auditing

    I was reading Captain’s Share the other day and enjoying a quiet afternoon at home. It’s a science fiction book about one man’s journey in the future as a captain of a space freighter. It’s an interesting series from Nathan Lowell that I’ve enjoyed and recommended to other science fiction fans. In the book, there’s a scene where the main character is leaving his old ship as first mate and moving to a new ship as the captain. However he notes that the formal process is to deactivate his records on the old ship and ensuring they will be read only forever. The book notes they can’t be deleted because they are a part of the ship’s records, log entries, etc.

    That seems to be a far cry from the way auditing takes place in current computer systems. Auditing of systems is under the control of the sysadmins (who are sometimes hackers) and can be altered, changed, etc. We, as software designers, haven’t done a good job of ensuring the integrity and longevity of log records. In some sense, it seems to be a fundamental flaw in OS and software design to not have separated out the auditing and recording of actions from the administration and rights of the rest of the system.

    I’d hope that we would recognize that auditing actions and preserving this data is something that ought to be tightly linked to, but separate from, the rest of system operation. I’d like to think that fundamental changes and actions taken on the system should be written separately to an area that is easily marked as readable by non-sysadmins that are designated to review the information. I know we have the challenges of managing the space and the problems of spurious actions being generated to fill (or rollover) logs, but I’d think after 50+ years of computing we would have considered some sort of event log that isn’t under the control of the people whose actions it is recording.

    SQL Server has improved its auditing features and capabilities, but far too much is still linked invariably to the sysadmin, often the same person the auditing should be watching. This is certainly one area that I hope matures in future versions as the need grows to track and review actions taken by privileged accounts.

    Steve Jones

    Video and Audio versions

    Today’s 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.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 19.5MB) feed

    MP4 iPod Video ( 23.7MB) feed

    MP3 Audio ( 4.6MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Cyberwar

    There are no shortage of books about cyberattacks and hackers. Some of these fictional stories even postulate that countries will build armies and engage in digital war with other countries. Some of this has come true, with the US and Israel attacking Iranian targets, suspected Chinese hackers targeting the US, and the announcement that Britain is building their own cyber army.

    While there are certainly no shortage of attacks made on corporations every day, how long before countries make determined efforts to disrupt their enemies’ economies with digital war? It’s a scary thought, and given the poor security habits of so many developers, it’s possible that many companies might find themselves struggling to conduct businesses while under attack. It might not be any different than if conventional weapons were being used near our facilities.

    The state of coding by so many “developers” today is somewhat scary. It’s not even old applications that are vulnerable to SQL Injection, but even new systems that have poor security practices being used that are vulnerable.

    I think that secure coding practices like these should be implemented by anyone writing software. I think examples, frameworks, and presentations about coding shouldn’t use simple passwords and bypass checks. Yes, it’s a pain for those that teach, but it also means that shoddy coding practices aren’t proliferated as people borrow your code and alter your examples.

    Security is a problem, but I think a lot of the issues would be minimized if we, as an industry and professionals, learned to write more secure code as a matter of habit, not as an additional feature to be added later.

    Steve Jones

    Video and Audio versions

    Today’s 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.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 17.0MB) feed

    MP4 iPod Video ( 19.9MB) feed

    MP3 Audio ( 4.1MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Encrypting T-SQL Code

    This editorial was originally published on April 10, 2009. It is being re-run as Steve is on vacation.

    I recently engaged in a discussion with someone that was building an application on SQL Server. This person had a bunch of SQL code that was being put in stored procedures and then being sent to client sites. The developers were worried about clients modifying their code and wanted to send “secure updates” to the client by encrypting the stored procedures and giving the clients the encrypted text.

    Apart from the hassles of getting this to work, I asked by would they bother. There are decryption routines available and this isn’t meant to be a secure way to hide your code. Heck, even application code can be decompiled, and if they’re likely to mess with the code, they likely have the skills to get the source.

    So for this Friday’s poll, I’m wondering about how you feel about encrypting code in SQL Server. I want to know what you think.

    Is there a point?

    Is there a reason to encrypt stored procedure code? After all, there are many, many vendors that sell applications built on SQL Server, with stored procedures.  Most of that code isn’t encrypted and it’s usually not a problem. Most customers don’t mess with the code and there are usually prohibitions written into support agreements.

    Personally I don’t think there are many great ideas, and likely very, very few in the database space, that are worth securing. Someone doesn’t buy a software package so the can learn how you wrote it. Most of them buy software because it solves a problem and saves them time. If you can deliver a well performing, and good looking application, no one cares about the code.

    But I’m curious what the rest of you think, both end users and software developers. Is there really a good reason to worry about encrypting your code?

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s 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.