Voice of the DBA

Category: Editorial

  • Encryption Works

    If you have better encryption than this, it will work.

    I don’t know that the government hires the best people or they have the best tools to work with, but they have some expertise. There’s a short note from Bruce Schneier that full disk encryption (FDE) does appear to by preventing unauthorized access to computer systems by police in many cases.

    If you read the comments, there are all sorts of flaws and potential holes with encryption, which are valid arguments. However that doesn’t mean that you shouldn’t implement any encryption on your removable or portable drives, especially those in laptops. Those devices are like the locks on your home or car. They can be defeated by determined professionals, but all too often the casual criminal doesn’t bother if they are in place.

    Keep in mind many laptops are lost, stolen, or sold without wiping the drives. Most people that received the drive wouldn’t bother to try and decrypt it unless they were sure it had something valuable on the drive. Since it’s no guarantee that a laptop grabbed at Starbucks or from a car has valuable data, most likely the target is the hardware, not the disk contents.

    I think disk encryption is a good layer of defense in your security strategy and worth implementing. My laptops are encrypted, mostly because it’s an easy security mechanism, and I’m not always sure if something I have on there is sensitive enough to worry about. My recommendation is that you implement FDE if you can.

    You should also make sure you are backing up your data. Losing the laptop might not result in the release of sensitive data, but losing the data itself could be a major problem.

    Steve Jones

    The Voice of the DBA Podcasts

  • The Employment Contract

    I ran across this piece on how we should pay people from Business Week. It’s a look at the issues of specifying the exact work that someone will do once you hire them. I suspect this is a problem in many industries, but it can be especially tricky in technology, where the job requirements can change as the technology rapidly changes.

    Most of the time I’ve taken a job in the US, it’s been an “at will” employment, with a verbal contract between me and the hiring manager or HR representative. Nothing was signed, and I essentially did whatever my manager wanted, regardless of my job title. That was fine with me. Currently I have a written contract, but the requirements for my position are a little vague and my duties aren’t explicitly spelled out.

    However I wonder how most of you feel. Does it make sense to more explicitly list the requirements for your job? As a DBA, developer or other professional, would you want any limits on what you were required to do?  This Friday, answer this poll question:

    Would you like to have your duties spelled out explicitly in a contract?

    I know we don’t typically sign contracts, but would you like that? What if the duties were modified every quarter, with an agreement by both you and the management of the company? What if you could just list the things you were not required to do?

    Let me know this week what you think.

    Steve Jones

    The Voice of the DBA Podcasts

  • Not So Unbreakable

    Nothing is unbreakable

    There’s a report on Dark Reading that says some researchers think Oracle is not working on security as hard as they should. The proportion of security fixes has diminished, which some people think implies that they are not taking security as seriously as they should. The window of time between the disclosure and the patch has grown wider, which is troubling, especially when newer software displays vulnerabilities.

    I’ve been proud to work on SQL Server over the last 6 years from a security perspective as there have been very few security patches issued, and correspondingly, few vulnerabilities disclosed. It’s possible Microsoft has muzzled some researchers, but I doubt it. I would guess that if any serious security issues existed in SLQ Server 2005, 2008, or R2, we’d have heard about them. I think the security engineering process that is used for SQL Server has truly resulted in more secure software.

    It’s possible that Oracle faces a resource issue with all their acquisitions, but for a billion dollar company that employs over 100,000 people, they shouldn’t be having resource issues with their development process. It’s a question of accepting greater development costs in order to ensure their software is secure.

    This is one area where we ought to have independent security researchers that can discuss, debate, and disclose vulnerabilities, after a limited amount of time. That would help us at least understand the security risks we face, and perhaps pressure companies to build better software.

    Steve Jones

    The Voice of the DBA Podcasts

  • Sharing Your Database Server

    Is it time for a little more sharing in the database world?

    Some of the details for SQL Server 2012 are out now, and as expected, we have feature limitations in various editions. I was hoping for a change, and maybe it will come at some point in the future. I did expect there to be scale limitations and there are. As noted here, the Standard edition is limited to 64GB of RAM. It wasn’t too long ago that I would have considered that high a RAM limit to mean I’d never need Enterprise Edition, but these days I am finding more and more database servers with 32GB, 64GB, and more RAM inside them.

    The post notes that the buffer pool will not grow beyond 64GB, though it doesn’t mention limits in any of the other memory spaces that SQL Server uses. However assuming that the memory outside of the buffer pools scales, it might be time to think about installing extra instances of SQL Server on a single host if you are licensing by the core. With a commodity server costing under $10k with 6 cores and 96GB of RAM (no HDDs), one could easily consider placing 2-3 SQL Server instances on this hardware with each getting 24+GB of RAM.

    I think that virtualization is the best way to share physical resources, but the changing licenses for SQL Server 2012 might have a few of us rethinking that, especially as we consolidate legacy systems that might happily co-exist on a larger physical server, with smaller data sets, lower hardware requirements, and a cheaper edition of SQL Server.

    Steve Jones

    The Voice of the DBA Podcasts