Voice of the DBA

Tag: security

  • Elections

    In the last few elections in the US, there has been concern over the validity of votes. As more and more electronic machines are being used to record votes, and often being built with very little security, how can we be sure that the data is being collected, tabulated, and securely stored for our elections? It’s an issue that most countries face, and will continue to face as they deal with larger and larger elections.

    Developing a secure way to collect, store, and verify data is hard. We struggle with that on a regular basis, and I think we often tend to ping across both ends of the spectrum on how to handle this. We tightly control all access and storage of data,  keeping access as limited as possible, and we still have regular problems with data loss and breaches. Or we may open up our systems to large groups of users, essentially ignoring security. Is there any hope for voting data?

    I came across this idea from David Bismark that explains a fairly simple, and reliable method of both allowing access to data, while also keeping the secrecy necessary for each person’s vote.  It’s in a TED Talk that discusses the idea in a few minutes, and it’s rather amazing.

    I don’t know if there’s something we can learn here to apply to other data issues, but I would guess that any area that needs to distribute data while protecting privacy could use something similar.

    Steve Jones

  • 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