Voice of the DBA

Tag: security

  • The DBA Disconnect

    We all know that security is an issue that we have to pay attention to. At least, those technical people that feel responsible for the security of their systems feel this way. However a short article referencing a DBA survey shows that the rest of the business might not be in sync with the technical people.

    I think most DBAs don’t know what a data breach would cost their company. I’m sure that’s not a number that most places I have worked would even bother calculating. Of course, most places probably would have no clue if there were a data breach in the first place.

    This puts many technical people in a bad position. They want to do a good job, but management often wants to just give lip service to security. When it comes down to it, the performance, availability and convenience of database servers is much more important than good security to many companies. From allowing access for developers or applications with privileged accounts to preventing password changes because of hard coded entries, it seems that companies aren’t that concerned about security in many cases.

    Ultimately some external  force is needed for us to make security a priority. It could be through regulation, insurance from lawsuits, or something else, but I don’t have any confidence that companies are going to take security seriously. However you can do some little things yourself, like making sure there are no default passwords open on your systems.

    Steve Jones

  • Proving Your Identity

    I caught this article on Dark Reading that talks about the problems of multi-factor authentication. It’s interesting to me as I had written an editorial on passwords and mentioned that I used the fingerprint reader on my laptop. Someone pointed out that my fingerprints are likely all over the machine and could easily be lifted and used to gain access to the machine. That’s true, and it’s something I hadn’t thought of. To me a fingerprint reader is a convenience, but I might need to disable it for travel.

    As database professionals, we often rely on some other system to prove a person’s identity. For SQL Server, we typically rely on two common choices: a simple name and password, or some security token from the operating system. Those two have worked well, and since SQL Server 2005, we have also had additional encryption options that can be used to protect data, including the ability to use certificates to protect the keys that encrypt data. SQL Server 2008 also allowed Extensible Key Management, so that third party products could be used to secure data.

    As we store more and more data, and this data becomes valuable, it is more and more likely that individuals will try to steal data. While we can’t protect the data from insiders that need legitimate access, we do need to ensure that rights are properly granted and that our security systems have some way to verify the identity of the person or application that connects to SQL Server.

    It still feels like that the security mechanisms for SQL Server as a little immature, and the costs of implementing things like EKM are too high. I am hoping that it becomes more practical to implement better security over time, and we get more tools in SQL Server that help administrators manage permissions.

    Steve Jones

  • Automated Driving

    In the book Red Thunder (highly recommended), the highways are under the control of some computer system. You approach a highway, get into some merge lane, and then a freeway computer takes control of your car, disconnecting the steering and foot controls and drives you along. When you want to get off, you signal, the computer moves you to an off ramp, and then releases control. It’s efficient, with the computer putting cars bumper to bumper, with a few inches between them since everything is under control.

    It sounds great to me, but I’m not sure we’ll ever want to completely put our transport under so much computer control. However people are trying, with automated subways and trains, but many of these still have an operator. There are quite a few projects looking at bringing this type of control to cars, though I’m not sure if we’ll ever get approval for something like this without some type of closed track that only allows automated cars.

    Think about all the issues you see in computer software, even supposedly well-written software. There are always bugs and unexpected code paths or even demands being made of the software. There’s also not enough testing to convince many people that we can really write extremely high quality, complex software that can handle something like traffic maneuvers.

    Then there’s the security. Whether it’s a central system that controls flow on a road or a distributed system in each vehicle, can you imagine the possible consequences if there were some security breach? What if someone finds a way to do some sort of SQL-Injection like attack, such as the one I show above?

    As much as I’d like to be able to ride in my own car, but have it handle the driving chores sometimes, I’m not sure our technology is anywhere close to the level it would need to be for me to trust it.

  • 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