Voice of the DBA

Category: Editorial

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

  • Abstraction

    One of the core tenets of good software design is to abstract away details in any particular part of an application. We want to use well defined and constructed interfaces so that the implementation of any particular method or section can change without affecting the way the system works. This allows for improvement and upgrade over time. The same thing occurs in hardware, where we can replace a hard drive, a graphics card, or other components and the system should still function in the same manner. There might be a bit of work, such as updating a device driver, but the core system should still work.

    This is also present in the real world. I can replace the wheels and tires on my car, since as long as I have the same pattern for the bolts to attach to the axle, things still work. Electrical systems work this way, allowing any device that has the correct plugs and uses the expected voltage to interface with an outlet. The examples of abstraction are numerous, and the more we use abstraction, the more flexible our systems can be. Where we haven’t abstracted away details, it becomes complex and expensive to change part of a system.

    In a database setting, we want to use abstraction where possible. The use of views or stored procedures (or functions) allow the underlying table implementations to change without an application being too tightly coupled to the structure. This isn’t always well adhered to, despite the well known practice of building a data access layer into an application. Too often developers want to tightly couple their application to the underlying table structure.

    But, how abstracted should you be? Certainly I’d hope that your application had the ability to easily change connection settings, and these days I’d hope you actually had two: a read/write connection and a read-only connection. What about the database name? Should that be abstracted away? Again, I’d hope so, even in a multi-database application. If for no other reason than to simplify development by allowing the database name to change on a development server. Certainly security objects, especially encryption mechanisms, need some abstraction to prevent the requirement that they exist in non-secure environments.

    Are there other abstractions you’d want to see widely implemented? I wonder what other examples might be important to developers or DBAs out there. I know that allowing abstractions also brings complexity, and the ability to change those values between environments is critical. This could be performed with injection of different parameters as software changes are deployed, but the mechanisms for doing this are still immature and not standardized.

    There are plenty of other places we can abstract away implementations, but without mentioning too many, I want to know what you’d like to see. What abstractions would you want, or do you implement in your systems?

    Steve Jones

    The Voice of the DBA Podcast

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