Voice of the DBA

Category: Editorial

  • Code of Conduct for Software Maintenance

    I ran across this article about a recent symposium for CIOs where a code of conduct for IT maintenance that was developed as a guideline for how companies want their software vendors to behave.  This is strictly a customer driven initiative, organized by the Gartner Group, to try and ensure that software companies treat their customers fairly.

    I was surprised to hear that the CIO of Lowes say that software maintenance costs are the largest growing line item in his budget. If that continues, then the price of maintaining software could be a real issue for companies. If it is, then will they slow down they software upgrade cycles? What happens to the innovation of software if companies expect versions to be in production use for 5-7 years? Will that impact the 18-24 month cycle of SQL Server?

    It’s hard to say what might happen, but I do think that sometimes the cost of software maintenance is out of line with the true maintenance costs. Is a 20% margin fair? Especially when it seems every software package out there needs regular maintenance in order to work well. Is that because software just needs repair and enhancement once it gets used by the public? Or is it because software vendors are not testing enough and expecting clients to just live with their level of quality?

    The code is a good idea, and if enough large companies agree that adherence is necessary for them to purchase upgrades, I can see software companies starting to abide by its provisions. I have to say that Microsoft already follows some of the guidelines, like regular patches for its products. I think Microsoft has fair licensing practices for test and development machines, though it might be nice to see different support levels for different levels of criticality.

    Steve Jones

  • Should You Write Down Your Passwords?

    Today’s editorial was originally published on June 27, 2005 and is being reprinted today as Steve is out of town.

    According to Jesper Johansson, senior security program manager at Microsoft, the security industry is giving out the wrong advice by forbidding people to write down their passwords. Strong passwords are impossible to remember and lead to people picking easy passwords or using the same password across all the systems that they access.

    And using the same password across all systems us poor security. I tend to agree with that in most cases because if one system is compromised then all of them are. However, for the administrators, it’s problematic if all systems have different passwords. Then the cost (in time) of administering these systems goes up. I admit that in most of my jobs I’ve used the same sa password on all servers and the same administrator password on all systems. The caveat is that we change those passwords often, usually every 30 days and always when an administrator leaves. While a security breach would leave all systems vulnerable, the window of opportunity is fairly small.

    Bruce Schneier says that it’s impossible to remember strong passwords. And now password cracking programs are hip to the 3 for e and 0 for o replacements (and others). Plus with distributed cracking programs and cheap hardware, it takes less and less time to crack passwords for anyone that truly wants to get at your systems.

    It’s quite a quandary for people. To me there are two problems we are trying to solve. One is protecting systems for the administrators. These are more technically competent people and should be required to build stronger passwords. The system that I liked the best over the years was the central storage of all our administrator passwords (Windows Admin, SQL, Exchange, service accounts, etc.) in a central storage file. We used Password Safe for this on a network share accessible to administrators only. We changed the file password periodically and scripted changes of the various passwords every 30 days. Usually we’d solicit some theme and assign an administrator to change the passwords.

    The other problem is how to get users to create and deal with complex passwords. Of all the suggestions that I’ve seen, I think writing them down is a good idea. Make stringent requirements, 12 characters, mixed case, numbers, etc., require changes often, but allow them to write them down. Not on sticky notes, not posted, but maybe a card that they keep in their wallet or purse. Or these days, maybe their cell phone.

    Now if we could just somehow secure your cell phones. Maybe outlaw Bluetooth?

    Steve Jones

  • Enterprise Management

    One of the things that I’ve had to do in my career is manage large numbers of servers. There was a time when two of us managed several hundred instances of SQL Server, and managed to do it very well with a lot of automation. Recently I saw someone post a note about having 400+ servers to manage, and they were wondering how to perform enterprise management. In Oracle environments, they mentioned using OEM, RMAN and other tools to manage backups centrally and wanted to know what SQL Server solutions were out there.

    I know things have changed quite a bit from the SQL Server 2000 days when we had to build all our own tools, so I wanted to ask the question as a poll this Friday:

    What do you do for central management of lots of instances?

    If you have more than 50 instances, what tools do you use to try and ensure you have a well managed environment. With the addition of the Central Management Server and Policy Based Management  to SQL Server, it definitely is easier to handle a larger load of instances

    This Friday I’m wondering what tips and techniques you think work well for managing lots of instances. Any tricks you’ve used? Any third party products that are very handy? Share you knowledge this Friday.

    Steve Jones

  • One Time Passwords

    Facebook seems to be constantly under fire for one privacy issue or another. I think it’s likely something that they will deal with forever, since their fundamental purpose is to find ways to share data with others and many people don’t understand the tools that Facebook has built for them. As I follow the growth of Facebook and see the new features that they add, I think they do have some commitment to making it easier for people to better secure their information and only share it in the way they want.

    Recently I saw on the Facebook blog two neat features that I really liked, and I think might be nice additions to SQL Server. One was the ability to remotely log your account off from other locations. This could be handy for people that might access Facebook from a public terminal and forget to log off. We can easily have an administrator do this in SQL Server by killing off a session.

    The other feature was the addition of a one-time password for someone that might want to access their account from an unsecured terminal. At first I thought I’d never need to use this, but then I thought about all the times that I had accessed a server from a friend’s computer. Or how often I had a request for some data that required a new account. What if I could setup a one-time password for an account in Reporting Services that would allow someone to view a report, or download some data without permanent access?

    It would be an interesting way to handle ad-hoc access to systems. In the past I’ve usually enabled a specific  account for a short period of time, but then I’d have to set a reminder or remember to do disable it. That wasn’t something I always remembered to do.

    However allowing someone a one-time password might be a good way to allow them access to data they need on a limited basis. I could see the need for a one-time execution of a report being a feature that would allow me to distribute data easily for a single use. It could be very useful in ensuring that accounts that were granted rights did not have them forever.

    Steve Jones

    This was also published at SQLServerCentral, which includes a discussion of this piece.