Voice of the DBA

Tag: security

  • Security by Obscurity

    This is an editorial reprint from Aug 23, 2005

    I wrote awhile back about security through chaos, and that piece provoked some interesting responses. While I’m not sure I’d recommend it for every company, in some places it makes sense. I saw this Info World article on Security by Obscurity and it reminded me of what I’d written.

    The article talks about some basic things you can do to that don’t seem like much, but the suggestions obscure things and ensure that not much on your system is as it would be expected. One simple thing they talk about is not installing to the default locations. That doesn’t sound like it would help much as there are always ways to read the registry or use environmental variables to find installations.

    However it does work. How many pieces of software, including some SQL Server Service Packs, expect things to be installed on c:? How often have you been bitten by a “bug” in some software because you’d renamed or moved something?

    Computer software depends on patterns in many cases to work. And we all use patterns to shorten development time. We reuse code, we cut and past way too much, and we often forget to make simple checks for things being moved around.

    The same goes for virus and worm writers. The people who develop the technology might not be fooled, but so many script kiddies that use kits of modify some piece of code aren’t as savvy and don’t necessarily make these checks. I know that the administrator account has a particular SID that you can scan for, but I’d be willing to bet that most people would write a worm looking for “administrator”. Just think how much less of a problem SQL Slammer would have been if most people had moved SQL Server to some non-default port.

    Simple obfuscating changes aren’t the answer to security issues, but they provide another layer of protection.

  • 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.