Voice of the DBA

Category: Editorial

  • The Death of the GDPR

    When I first heard of the Sarbanes-Oxley Act, I was disheartened. It sounds like another over reaction by politicians to a crisis that would create lots of work for companies. At the time I was working for a software vendor and while we weren’t bound by many regulations, we did value our ISO certification. As we went through the SOX audit, it felt a lot like our ISO audit the previous year. In fact, we re-used most of our work, and re-did some, making it compliant with both items.

    A few years ago, we started GDPR preparations at Redgate, as well as talking and working with customers. We built some products, like SQL Provision and our Data Catalog, with the hope that they would be useful to organizations looking to ensure compliance. We have seen many companies trying to comply, and I’m glad that we can help. I think the GDPR is a step in the right direction for the future of how we manage and deal with data.

    I’m also glad that companies are taking the idea of data rights and data privacy more seriously. I think those of us in technology have been lax, and management of many companies even worse. I think I may some some evidence in this piece about possible lack of enforcement of the GDPR by Ireland. Not to discuss politics, but I completely understand when a very large company brings a lot of revenue to a country, there will be hesitation in disturbing that relationship.

    Regardless of the politics, I did find this quote interesting. A report in 2011 on Facebook’s data handling practices had this quote: “We do not consider that reliance on developer adherence to best practice or stated policy in certain cases is sufficient to ensure security of user data…” This didn’t prompt Facebook to make changes to process, and Ireland has not pressured them to do so, even with the GDPR taking effect last year. I’m hoping this isn’t the death of the GDPR as a set of regulations.

    I completely agree with the sentiment of that quote. We can’t trust that developers will adhere to best practices, or that companies will protect data. Sometimes this is ignorance, sometimes human error, and other times willful disregard for rules and regulations. We do need some sort of enforcement of the data handling practices that we as a society want to see in place. We certainly have to decide what practices to codify in our framework and we need some enforcement.

    I don’t know that very large tech companies will get fined or forced to better handle data, but for many of us that work in smaller organizations, we don’t have the clout or impact of a multi-billion dollar revenue organization. We might see fines that can very much hurt our businesses. We ought to be ensuring we not only follow best practices, but we build data security in by design and default. It’s cheaper and easier to do so, and it ensures we don’t fail to go back and fix things later.

    It’s also something each of us, as data professionals, ought to take pride in doing.

    Steve Jones

    Listen to the podcast at Libsyn.

  • Default Backups and Feature Awareness

    Have you ever been asked a question about your software and thought that the person was asking about an obvious feature? Perhaps someone has suggested a feature to you and you answered that this was already in the product. Did any of you think your users were stupid or not very observant, or something else?

    I’ve had that situation appear a few times, with me on different sides of the discussion. I watched someone ask a question that I knew the answer to, and thought, huh, why didn’t they know that? I asked a question about something in the Microsoft Azure world and got a quick answer, wondering why I hadn’t been able to find the solution myself, and that I shouldn’t have been cursing the Microsoft developers so much. I’ve had a few people do strange things at SQLServerCentral after the migration and wondered, why in the world…….? Then I remember that lots of people use the site differently than I do and I should expect that.

    I thought about this while reading Joey D’Antoni’s piece on backups. It’s not hard to make backups. It’s not hard to set up a maintenance plan to run backups. It’s not hard to set up a history task to trim old ones. Heck, it’s not hard to implement Ola’s scripts.

    The problem is all of these solutions require some knowledge.

    I think plenty of people assume either the system backs itself up or their nightly file sweep by a central backup system will grab the database. Hint: it won’t. I think plenty of people think backups are someone else’s job, or they are in a hurry with an installation and assume they, or someone, else will return and set up backups later. Plenty of third party software may create a database, but never set up a backup process. We often don’t realize no backups are running.

    That’s not good. While I like Joey’s suggestion, I’d go further. I’d have instance defaults set on install and an automatic, nightly full backup process set for all new databases with a week’s retention. I’d embed this in the DDL so the default is backups will be set on CREATE DATABASE, and you can use a switch to turn this off if you want to use some other backup process. I bet backup software, like SQL Backup, would even do this for you, turning off native backups when you turn on their scheduler.

    I think backup is the most critical thing a DBA does, or an accidental DBA, or the accountant that installed Dynamics, or anyone working with a database. Next would be verifying things with a restore. Then comes security and the list goes on from that point. If you don’t have the data, because of ransomware, virus, bad hardware, or anything else, you are in a bad situation.

    Please. Set up backups. If you find a server without them, inform someone in writing of the dangers and give them resources for creating backups. If you create databases as part of your software deployment process, set up backups somehow. Use a maintenance plan. Those aren’t great, but they’re better than nothing. There’s a reason why SQL Monitor has an alert for databases with no backup. It’s a critical one to have running.

    Steve Jones

    Listen to the podcast at Libsyn.

  • A Double Failure

    Update: Perhaps not, as Evisort dispute any customer data was exposed and they’ve updated security.

    Every server ought to have a password. Every one.

    It’s 2019, and apparently that advice hasn’t sunken in. I still can’t believe there are people without passwords/codes on their mobile devices or home PCs, but there are. It’s crazy, and while I can forgive some individuals for doing this, no IT infrastructure staff or developer ought to do this. And yet, a double fail recently from Evisort.

    This is a startup doing some AI work, but apparently they set up an Elasticsearch server without a password. I’ve written about this before, and you set a password, but don’t have to. That’s both an Elasticsearch failure for not requiring one, but also a monumental failure on the part of whoever set this up inside a company.

    Use. A. Password.

    The second fail is with this server being claimed to be a “testing and development” server. If that’s the case, why was production, live data on it? I know many people do this, but if you use that data in non production environments, the data needs to be secured. I’m sure it’s especially hard for AI/ML systems to work without real data, unlike other database driven applications, but if you need live data, you need real security here.

    If you don’t want to do this, then you need masked, obfuscated, pseudonymized, generated, or other data that can be used. I’ve realized the problems and scope of this across the last few years in my work with Redgate customers, while looking at the challenges and problems brought about by using this data. We’ve also see there is a lot of potential liability with new regulations like the GDPR and the CCPA for poor data security.

    I used to worry about the state of our industry with the poor quality of so many applications written in the 80s and 90s. Now I worry even more about the problems of poor data security. I don’t have good answers, but I know we need to do better.

    Steve Jones

    Listen to the podcast at Libsyn.

  • Really Important Software

    I remember reading about the Boeing 787 (the Dreamliner) being designed. I was fascinated by the process and excited to fly one. I finally did and enjoyed it. Since then, I try to fly on those when I can as the spacious ceiling and other changes seem to make for a better flight. I impressed with the work they did and the scale of the changes, both in manufacturing and software. There’s a short timeline here and if you ever get the chance to take a tour of the factory, do it. It’s very cool.

    I fly a lot. Last year I took around 50 flights on airplanes, some of them Boeing, some Airbus, some 737s, 777s, 787s, A350s, and a few others. I haven’t flown on a Boeing 737-Max 8, though I did just recently fly a 737-800. When a few of those planes crashed, I somewhat chalked this up to pilot training and a lack of options on the planes. I’m not exonerating Boeing or the airlines, but I wasn’t personally concerned. I saw an interesting piece at Vox, but was still curious about the issues. After all, I’m in software, and I fly a lot.

    There’s an analysis of the crash from a software developer at the IEEE site that’s worth reading. It’s a look at the issues, the potential ways things could have been addressed and, perhaps most importantly, the idea that our software is not necessarily going to fix problems. Software is a way of reading data and then affecting changes in the hardware, but software isn’t perfect. One of the quotes in the article puts this in perspective for me: ” Every time a software update gets pushed to my Tesla, to the Garmin flight computers in my Cessna, to my Nest thermostat, and to the TVs in my house, I’m reminded that none of those things were complete when they left the factory—because their builders realized they didn’t have to be complete.”

    Data matters, but as we all know, data is sometimes incorrect, jumbled, or otherwise problematic. In this case, not only does it appear the data could be incorrect, but the plane software isn’t looking at all the data, and it certainly doesn’t take all the inputs from the pilots. While humans make plenty of mistakes, they need to have inputs and overrides in software systems.

    I don’t want to get caught up in the issue with these planes, but rather look more generally at our systems. DevOps looks at the idea that we don’t know everything about how to build our software when we start. We definitely know it is not complete and will need more work when it leaves our factory, but we also know that this is the case. We know it’s not complete. We take feedback, learn, and adjust what we do. We constantly drive quality up, or at least, that’s the goal. Money and politics can get in the way, but the more they do, the less you’re doing DevOps.

    Steve Jones

    Listen to the podcast.