Voice of the DBA

Category: Editorial

  • The Penalty for a Data Breach

    Many of us that work with data are somewhat insulated from the effects of a data breach. Each of us is responsible for writing software, managing the database platform, perhaps even in charge of configuring security. However, in the event of an attack or loss of data, many of us would likely be responsible for the technical aspects of analyzing the weakness or cause of the incident, determining what data might be lost, or perhaps helping to change systems to prevent future incidents.

    Would many of us deal with the penalties or financial liabilities of data loss? Perhaps indirectly, but not much. However our employers (or more likely, their insurance companies) will deal with penalties. Right now there isn’t a lot of liability for companies that lose data. Minor penalties and credit monitoring, but many people are getting upset, which might result in changes.

    What does a company owe you if your information is lost? It’s debatable, and this is likely to become a bigger issue over time as more and more people are affected by this issue. I expect that penalties will increase over time, this will also mean that the requirements and work each of us as data professionals need to do will grow.

    While encryption and other measures can help, they don’t completely protect data. Good security comes about from a number of layers, each of which is designed to thwart, or limit the success of, certain attacks. Those of us that work with data, whether in development or administrative roles, need to educate ourselves and continue to improve our ability to implement secure applications.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Paying for Data

    Would you recommend your organization pay a ransom to get the key to decrypt data that’s become encrypted on your database systems? What if the data were encrypted in backups going back two weeks?

    It’s an interesting question, and one I might expect we will have to deal with at some point. This week I saw an announcement that another organization, this time a university, paid a ransom to recover data. Before you react with “of course, not,” think about this quote from the University Vice-President:

    “We are a research institution,” she was quoted as saying. “We are conducting world class research daily and we don’t know what we don’t know in terms of who’s been impacted and the last thing we want to do is lose someone’s life’s work.”

    That’s a powerful statement, and certainly one that I could see salespeople, accountants, and more making as an appeal to upper management. What’s interesting in the piece is that the university acknowledges that using the decryption keys is a complex endeavor, requiring IT to get systems operational again. I hope that at the least they also made new backups of the encrypted data before using the keys. Who knows what sort of results come about from criminals that have encrypted, and the offered to provide reversal instructions and keys.

    I expect the ransomware efforts to become more prevalent across the next few years, especially as people have success. Even if fewer people pay ransoms, I bet plenty of people will look to disrupt organizations with these actions. Perhaps even a competitor will look to introduce ransomware into your company? Maybe by offering a job to an individual that leaves such a surprise behind as they get ready to move to a new employer.

    There are all sorts of issues here, and potential attack vectors. The fact that ransomware (or other malicious software) could be introduced to remain idle, or even transparently encrypt and decrypt systems until a date passes and the keys delete themselves, is horrifying. At the very least, I think this brings to mind the idea that we need multiple versions of backups, so mirroring a file system to another location, or some cloud service like Azure, Dropbox, etc., isn’t enough. Perhaps we should also have checks in place that look for changes. After all, can you imagine a rouge process implementing TDE and letting it run for a month before deleting the certificates from your system and truncating all the tables a week later?

    Steve Jones

  • Good Stories

    The IT horror stories. Many of us have them. The mistakes, the trials, and frustrations, these seem to be the stories we collect. Many of us have a story of deleting data, forgetting a backup, making a security mistake or some other item that perhaps should have terminated our employment. Or maybe it did. In any case, I’m sure most of you have a tale about some mistake.

    However, I think we don’t talk enough about the wins we have. The good things we do that actually help people, they appreciate, that get us kudos or even rewards. Maybe there’s something that garnered some unsolicited praise for your efforts. I’m wondering this week, what are your good stories in IT. ?

    I hear about good stories all the time from my wife. Her horse training efforts produce immediate effects, some of which are very powerful and moving for her clients. I hear about great things my brother does in medicine. Certainly I also get many very kind words from plenty of you about the help SQLServerCentral provides. But I haven’t had a lot of stories as a developer or DBA. Many of substantial upgrades or improvements I’ve made to applications were tempered with complaints about us “changing something.” At times, it’s felt like a no win situation.

    Perhaps my best story is from my time with a large sales organization. We had a demo system that provisioned a set of virtual machines to showcase our products. The complexity came from the fact that each demo environment was 6-8 machines, networked together in a VLAN that allowed them to be identical for each salesperson, yet isolated to prevent network issues. This was in 2001, when tools for managing virtual machines were rudimentary, and things like runbooks didn’t exist.

    I helped our administration team go from an Excel spreadsheet, with incredibly complex (and unreliable) macros to an web application. The application allowed them to easily track which environments were provisioned for which salesman, making the entire process much simpler, and more importantly, a multi-user system any administrator could access to provision or teardown demo environments. This wasn’t a large piece of software, and not widely used, but it made work much easier for a few people that were struggling with the constant and ever changing demands of busy salespeople.

    What’s your best story? Let us know today.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.2MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • More and More Data Growth

    I wrote an editorial a few years ago about a Zettabyte (ZB) of data being created in a year in the world. This was 2012, and those seemed like crazy predictions. At the time I was doing some work with full text search, Filestream and Filetable, and wanted to do a presentation on those topics. I did some research and found some neat facts, which I incorporated into the presentation. At that time, there was an estimate that we’d have 50x that data by 2020. I also wrote I was carrying 3.5GB in my pocket.

    Those values seem crazy now. Crazy small, that is. At a recent event, I was carrying 1.6TB in my pockets. My pockets, not my laptop bag. With 64GB in my phone, an mSata 512GB drive and a 1TB mSata drive. I was carrying a smaller physical amount of electronics than was in my first 10MB hard drive on my person, both in size and mass. What’s funny is that there was only another 1.5TB in my bag, between my laptop and another external 2.5″ drive.

    Between the growth of storage and the Internet of Things (IoT), data growth estimates are rising. At the recent SQL Nexus conference, part of the keynote was given by Dr. Troels Peterson, a physicist with the Neils Bohr Institute, working with the Large HADRON Collider. The work there means big data has a new meaning. Dr. Peterson noted that during his work with the Atlas detector, they can generate 1 PB/s of data.

    Per second.

    That makes the few TB I carry around seem puny. There were two other really interesting items from the keynote. One is that computers cannot process that level of data so hardware sensors must make decisions on what data to capture and store for analysis. The other item is that much of the data will not really be analyzed, and can’t easily be analyzed directly. Instead, algorithms and patterns are used to determine which data is good and should be used. They know there are errors in the data, so the trick is to actually use computers to find the good data.

    The world is a little different for those of us that deal with customers and orders instead or particles and uncertainties, but we are still seeing lots of data growth. Our challenge is to find ways to better manage this growth, while still making data available and useful for our users.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.4MB) podcast or subscribe to the feed at iTunes and LibSyn.