Voice of the DBA

Tag: Database Weekly

  • 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

  • Install Cumulative Updates

    For years I haven’t recommended installing Cumulative Updates (CU) as they are released. The main reason is that Microsoft has had language associated with their CUs that say customers should not install a particular CU unless they are experiencing the specific issues the CU corrects. Each CU has (in the past) also noted that you should stick with the latest Service Pack otherwise. That disclaimer has been enough for me to be concerned about CUs in a general sense, despite the insistence that the CUs were tested as well as SPs. My thought was that if the testing was the same, that disclaimer wouldn’t exist.
    Well, things have changed. The latest CUs have this language in the section where a KB says that Microsoft recommends CUs as they are release:
    • SQL Server CUs are certified to the same levels as Service Packs, and should be installed at the same level of confidence.
    • Historical data shows that a significant number of support cases involve an issue that has already been addressed in a released CU.
    • CUs may contain added value over and above hotfixes. This includes supportability, manageability, and reliability updates.
    That’s good news, though as Kendra Little notes, you still need to test. Bugs will still exist in patches, and really all software, so it’s important that you test in your own environment. That means you need a test plan that can easily run, preferably an automated test plan. If nothing else, this is a good reason to use tSQLt and have tests written for your system. At least you can verify important queries and systems are working. Kendra has a good list, so read her post.
    While I think the quality of CUs is up and they are probably as safe as most of the Windows patches we get every month (and are often installed no matter our individual feelings), I’d still be wary. If you can’t test, if you’re busy, if this is a month you can’t afford for things to fail, then don’t install the CU. This is like throwing your own developers’ code into production without any testing. Make sure you know what is being changed, and you look for obvious problems. No one will be too upset of an obscure issue, but if your scheduled jobs start failing, you’ll dramatically reduce the confidence people have in you.
    I am still wary of all patches. They’re disruptions, to both your routine, and potentially to availability as well. Make sure you test, but if you have the time, I’d say keeping up with patches is worth doing. Microsoft is constantly fixing issues, and you want to take advantage of their hard work, if you can verify the patches don’t degrade your system.
    Steve Jones

  • Power BI Week

    This past week was T-SQL Tuesday #75, with the topic of Power BI. There were some interesting posts, and we’ve included a few in this week’s newsletter. This was also the week where the winners of the Power BI report contest were announced, and it was a good entry. This was the one I actually thought was the best one. If you haven’t seen it, take a few minutes and go look at the entry and play with the data. It’s interactive, so be sure to see how well the Denver Nuggets have competed against Mr. Curry.

    I first looked at Power BI last summer, watching a presentation and being intrigued at the ability of the tool to easily get data from web pages. I then talked with a friend that works with Power BI regularly, and they showed me how to loop and gather information from many pages, easily assembling the data into a dashboard that was interactive. I was very impressed, and I’m looking forward to doing a bit more work on the platform myself.

    Quite a few people have been concerned that the development of tools like Power BI mean that there is less of a need for IT staff. I find myself thinking quite the opposite. There will always be data quality issues with something like Power BI, and there is a certain level of programming to build more complex reports. Not to mention the refresh and update process is slow, which can make the tool feel cumbersome.

    However users will find some reports are more useful, or more important, and need some help from technology professionals. Whether that’s developing more DAX formulas and measures to enrich displays or just providing stable, clean data sources that consolidate data from various places, there will be plenty of work for IT staff that support companies using Power BI.

    To me, Power BI is the type of tool that empowers users and lets them experiment a bit on their own. Once they determine what they really want, then they can engage me to build a more robust, reliable, and useful tool that helps the business.

    Steve Jones

  • Adios, IE

    The first browser I used on the Internet to find information was the text based lynx browser. This was quite an improvement (at the time) over Archive and Gopher. When Netscape released their Navigator browser for Windows, I abandoned those old tools, moving on to a new way to access information across the world.

    However I primarily worked in a Microsoft world as my career grew and that meant using Internet Explorer, or IE. In fact, I remember thinking all the ActiveX extensions and the bundling on installations of Windows meant that the browser was convenient. It was even nice to program on, since it dealt with poorly formed HTML fairly well. However it had plenty of issues and was a never ending source of calls from customers that had stability and security issues.

    In fact, sometime around Windows XP, I moved to Firefox and never looked back. I only had IE installed on my systems because Microsoft included it with the OS. The last 5 or 6 years, I’ve run Chrome and Firefox together, only using IE when a few specific sites required it. Even then, I’d give an inward groan each time I clicked on the familiar “e” icon.

    However times have changed. This month, on January 12, Microsoft ends support for all versions of IE prior to 11. While IE will still be run for many years by some people, just as Windows ME and NT 4.0 still exist in places, Microsoft won’t provide support or patches, and we can only hope that people switch to another browser quickly.

    I haven’t been thrilled with the Edge browser in Windows 10, as it hasn’t worked in some sites I use regularly. That seems strange to me, but alas, the idea of a Microsoft browser not working the same as other browsers is nothing new. I can only hope that Microsoft fixes the issues in Edge rather than having web developers include code to handle the finicky nature of Microsoft’s browser technology.

    The death of IE shouldn’t matter much to us, as data professionals, but I wonder how many of us still have applications using web browser controls based on IE technology. I suspect quite a few, and it’s entirely possible moving forward that we’ll continue to deal with issues of poor rendering of data from our databases through web controls for many years to come.

    Steve Jones