Voice of the DBA

Category: Editorial

  • A Matter of Life or Death

    In this book a data breach, identity theft, causes a death

    It sounds like something out of a fictional story, but could there be a data breach that might result in a person’s death? I read a book recently called Medical error in which a patient dies because of an allergy. The physician checked their records and noted the patient had been prescribed the drug earlier that year at the hospital, administered it, and the patient reacted and died. It turns out the patient was a victim of identity theft and the thief was the one that was seen at the hospital. The thief  didn’t have an allergy, but the victim did and died.

    According to this story, there hasn’t been a case of a data breach resulting in someone’s death, but the recent attacks against law enforcement agencies could change that. Informants and undercover detectives depend on their anonymity. A release of details from active cases could result in a death since the people that would be most interested in the information might be willing to kill those named.

    We seem to have no shortage of people that hack and attack systems for fun, often without much forethought about the potential effects of their exploits. As criminals get more sophisticated, I would expect more attacks to occur against law enforcement agencies. We’ve already had attacks that cross national borders, potentially sponsored by governments and I suspect we will see even more in the future.

    The data professionals working in the industries where life and death are dependent on technology should be worried. In law enforcement and medical fields, data professionals should be constantly educating themselves about security and working to regularly ensure their systems are protected, and audited . Auditing may even be more important in order to respond to breaches quickly.  It is asking a lot, but the potential results from a security lapse could haunt you for a long time if you haven’t done your best.

    Steve Jones

    The Voice of the DBA Podcasts

  • The Apprentice

    Vader's Apprentice: Hope tech work isn't this hard.

    It used to be that most serious developers went to college and studied CS. Those people that wanted to make a living programming computers became grounded in theory, struggled through assembler class, and understood the classic waterfall development technique. They could write bubble sorts and quick sorts, and could create and destroy pointers in thin air. At least in theory.

    As computer science curriculums evolved, they became more practical. Students no longer had to learn C or emacs (a shame, IMHO), but learned Java and .NET, working in nicely crafted IDEs like the ones they would use in the corporate world. Practical programming classes allowed students to build more rich and interesting applications, instead of just building virtual linked lists that  weren’t visualized outside of one’s imagination.

    At the same time, I’ve found that a larger and larger percentage of developers haven’t gone to college for a CS degree. Some have gotten other degrees, some just learned to program outside of school, and in both cases, they aren’t necessarily any better or worse than those developers with CS degrees. That leads me to this week’s question:

    Should we move to vocational developer training?

    We’ve asked the question before about whether a degree is required for a technology career, and I think most people agree it’s nice, but not necessary. However I’m wondering today if you think we ought to build better training for those people who are interested in computers, but don’t want to go to college (or can’t afford to). Should there be vocational schools that teach programming, maybe including apprenticeships with experienced professionals in the field.

    I think there is a place for some formal training in development, preferably including some C programming, but I’m not sure that I think a four year college degree is needed. I’d like to see a more practical, more affordable way for people to get bootstrapped into technology and begin a career, preferably with some apprenticeships that might build practical experience and good habits among younger coders and DBAs.

    Steve Jones

    The Voice of the DBA Podcasts

  • The Robot DBA

    Manna, a fun, and scary, sci-fi story.

    This is the story of Manna, the manager of a fast food restaurant. It’s a great read, and perhaps a little shocking. Manna is a piece of software, reading sensors, reacting, and letting employees know what to do with a synthesized voice through a set of headphones that the everyone wears in a fast good restaurant. In this tale, Manna evolves into a software system that is spread throughout many industries, essentially displacing managers and many workers at all levels in all industries. With the ability of these different “Manna” variants to communicate and negotiate contracts among themselves, the US devolves into an Orwellian nightmare place to live.

    It’s a science fiction story, but the fears that it evokes are similar to those I’ve heard expressed from many people in the IT field across my two decades in this industry. A friend of mine left IT a decade ago, while working as an Exchange admin for a company with 50,000 mailboxes. He was sure in 5 years his job would be automated and eliminated. I knew a few people that moved out of DBA work in the early 2000s, after Microsoft released SQL Server 7 and 2000, with some marketing messages that the products didn’t require a DBA. A few years ago I heard a few people arguing that PowerPivot would kill most BI development jobs because it was so easy for end users to build their own analysis applications.

    The one constant in all of those stories is that they never came true. I hope that Manna never comes true either, but I’m not worried. I’m very confident that if there’s one truth to all the computer development we do, it’s that we make constant mistakes and there is very little chance that we will be able to automate any significant percentage of IT jobs away.

    We do build better software, and we do allow an administrator to manage many more systems than in the past, but we also seem to constantly eliminate most of the efficiencies in two ways. One is by adding many more systems and applications, and the other is by introducing more complex systems that create new problems that need to be solved.

    The bar for IT knowledge needed is always being raised, but I just can’t see us getting to the point of having automated or robot DBAs running SQL Server in my lifetime.

    Steve Jones

    The Voice of the DBA Podcasts

  • From Vandalism to Serious Crime

    It seems that there are relatively few very talented hackers that can break into your systems. The vast majority of data breaches and issues are from one of two attack vectors: social engineering or script kiddies. Social engineering is hard to fight, especially in large companies where everyone doesn’t know everyone. Script kiddies are more numerous since they don’t need any talent and merely deploy scripts written by others to attack your systems.

    Recently it seems that there have been quite a few hacker attacks on systems, often using fairly simple SQL Injection techniques, that aren’t vandalism, and aren’t for profit. These attacks are motivated by hackers who are offended by the companies or organizations and are standing up for customers. That might be worrisome to DBAs and data professionals since you can’t hide data breaches if the attackers publicly post the data they’ve copied and you will certainly receive some of the blame for any breach of security.

    In the past it seemed most attacks were DDOS attacks, which were embarrassing for IT folks, but not overly damaging in the long term. The last year or two, however, the attacks have turned to the copying of data and its release. Embarrassing for the company and potentially costing it business, but also worrisome for the system administrators who might be held accountable and possibly lose their jobs.

    These days when there is never enough time to test and resources for security are sparse, what is a technical professional to do? One would hope that we would not be held responsible when we cannot perform adequate testing of applications, or we cannot implement strong security, but that is not what happens. We are blamed for being too slow to deploy applications, blamed if security impedes access in any way, and assuredly blamed if there is any successful hack of our systems.

    In my mind each technology worker should educate themselves on recommended security techniques and request those techniques be implemented. They might not be, but the documentation that you attempted to do so might save your job.

    Steve Jones

    The Voice of the DBA Podcasts