Voice of the DBA

Tag: security

  • Protecting Data

    Is it really true that we can’t anonymize data? If that’s true, then are we wasting time in looking at any type of obfuscation process or scripting for data that we restore to non-production environments? If that is true, then we then need secure development environments and treat them like production servers as far as security and access controls go.

    It’s somewhat amusing that the reason we can’t likely anonymize data anymore is because we have too much of it. All the different data sets that can be cross referenced, suing public data, make the success rate of anonymizing techniques low. I don’t know how practical it is for someone to actually combine data sets from public sources and using the information to determine the identities of people from other data sets. I do know, however, that there are lots of smart people out there with access to cheap computing resources and lots of spare time on their hands. This might be 21st century vandalism, and we, as data professionals, will be the people that have to deal with it.

    Does this mean that we should not bother to obfuscate or change production data that is copied to development systems? I don’t think that’s the case. In many environments there might not be enough information for someone to identify the original rows. Especially if you protect all of your data systems, ensuring that web logs and other potentially related source of information are not readily available. Even a rogue developer might not be able to unravel the anonymization if you keep separate data sets secure and limit the number of people that could combine them.

    Steve Jones

    The Voice of the DBA Podcasts

  • Password Help

    Ensure you keep shared passwords safe when people leave.

    Today we have an editorial that was originally published on Oct 9, 2006. 

    Yesterday I wrote about compliance tips and one of the things I mentioned was using encryption and passwords for your backups. It’s a good idea that you should use even with disk backups. You never know when someone might get socially-engineered and hand over one of your .bak files to the wrong folks.

    But using encryption isn’t enough; you need strong key management that changes the passwords on a regular basis to prevent data losses from the passwords getting released over time. I’ve worked in a dozen companies and there are many cases where a password has been used for some shared function, some application, some particular feature, whatever. If this password has remained the same for over a year, it’s been almost common knowledge throughout the company what the password is. I’ve seen business people, executives, even secretaries that knew the password to the point where it was useless.

    Shared passwords will be a fact of life in many cases. Administrative teams grow, help desk people may need access, consultants help out and learn them, and others overhear them. It’s going to happen, so you need to mitigate this risk.

    I used to manage a nightclub and we had similar risks with the alcohol. Since turnover was a fact of life, we had a simple policy. When a manager left, for any reason, all alarm codes were changed. On the third occurrence of a manager leaving, we had all locks re-keyed. It was a simple policy to reduce risk.

    The same thing needs to happen with your backups. Use one or even a few passwords to protect the various database backups. But then change those passwords every month or two and escrow or archive the old ones. You may not be able to prevent losses of the backup files, but by ensuring they are protected and the passwords changed regularly, you may just protect the data.

    And your job.

  • A Nice Refund

    Why don't these kinds of mistakes happen to me?

    This editorial was originally published on Sept 12, 2006.

    How’d you like to be the DBA for a system thatmistakenly gives out $318 million? It probably wasn’t the database, but more likely the code for some application that caused this to occur in the IRS system, but it’s something that becomes more likely in SQL Server all the time.

    SQL Server 2005 is the first time that SQL Server can be easily used as a complete application development platform. With the addition of the CLR, the Service Broker, Database Mail, web services, and more, SQL Server 2005 could be your database server, application server, and only server, with no other software running.

    While application developers will likely write most of the code, including lots of the CLR functions, procedures, and other constructs, who do you think will be responsible for the system? That’s right, the DBA. You’ll be the first and last line of defense and the one that will likely shoulder a lot of the blame for issues. Fair or not, I expect that DBAs will become more likely the scapegoats for issues.

    This means that as a DBA, you really want to beef up your skills as well as clearly delineate lines of responsibility. You should be able to read the code behind assemblies you add to your server, as well as understand how the SQL Server subsystems fit into an application. But you also need to be sure that you let management know when you are overloaded, when you can’t review code, or when you are concerned about possible issues with code.

    I’ve felt for years that it was a matter of time before some computer professionals will need to become bonded because of their responsibilities. I’m not sure when or where this will start happening, but I wouldn’t be surprised if it starts with DBAs.

  • SQL Authentication – Forcing Password Changes

    When you create a SQL Server login (with SQL authentication), you have the option of enforcing password policies from Windows (in SQL Server 2005 and above).

    chagepwd3

    The recommendation is that you check all three and force strong passwords. You also force a password change so the person has a private password not known by the administrator.

    If you go back into this account later, and look at the boxes, only 2 are available to be checked. The “User must change password at next login” is grated out.

    chagepwd1

    In order to access this box and force a password change, you need to change the password. The reason is that if the account is compromised, the hacker should not be the one to set a new password. The security model assumes the administrator can contact the legitimate owner offline and give them the new password.

    Start typing in the password box, and you can check the box:

    chagepwd2

    Of course you need to set a password that conforms to the policies, and it needs to match the confirm edit box Winking smile