Voice of the DBA

Author: way0utwest

  • Taking Shortcuts

    Many of us work in situations where we feel pressure to get work done at a pace that’s faster than we might like to move. In some sense, this is the nature of life, where customers and clients always want something done immediately. Whether they’re ordering food or building a house, it seems that quite often the customer expects the creator to just work harder and faster, without making mistakes, and deliver the goods quickly.

    That may or may not work, but if does often result in issues in software. While we can fix them, there can sometimes be larger issues, especially where sensitive data is involved. There was an incident recently that reminded me of this, though fortunately, it appears the data loss was minimal in scope and sensitivity.

    The mobile app at a recent security conference leaked data. The builders of the app embedded security keys and passwords that allowed anyone that registered to download a database of attendees. Fortunately this was a limited set and it appears only names were exposed. However, it could have been much worse, especially if this were a typical non-normalized database that might contain all data about an attendee in one row.

    I don’t know the timeline here for development, and I certainly don’t know the requirements. I do know that embedding keys and passwords into application is a bad idea, and even worse when those applications are going to be installed on customer devices. These are fundamental rules, and I certainly hope that whoever worked on this application, and anyone reading about this story, knows not to do this again.

    No matter how rushed we are, it’s important that we follow some practices and include some seucrity in our systems. I’d argue that data security ought to be number one and built into the system from the start. As the GDPR asks, we should be ensuring this is included by design and default. As much as it might seem that new legislation is overreaching and burdensome, I’d argue that mistakes like this one are all too common when we feel pressure to get work done. We shouldn’t be making these mistakes, nor should be be pressured to ignore security for the sake of expediency.

    Steve Jones

  • The CDO

    One of the cornerstones of GDPR compliance is appointing someone as a data protection officer for your organization. This person is responsible for ensuring that your systems and data are safe and protected, and presumably, complying with the various articles in the GDPR. Article 37 notes that both a data controller and data processor shall designate a DPO in certain cases.

    That makes sense for companies working under GDPR jurisdiction, but for those of us outside the EU, do we need a senior level data executive? I wonder. As I’ve been researching the work by others and working with various clients and customers, it seems that some companies do have an executive, not necessarily in charge of protection, but in charge of data.

    This week, I’m wondering if any of you have a Chief Data Officer in your organization. I’ve heard a few people say that if you do, it’s a sign of maturity in your organization, where data is treated as a truly strategic and important asset. You likely have some sort of data quality metric, you many have master data management systems in place, and the organization constantly looks to extract more value from the data they store.

    I don’t know if this is a sign of a more mature organization, but I do know that having some resources in place to ensure data quality, mapping your data estate, trying to ensure some level of consistency are signs of more data maturity. I know many of us realize data is important, and certainly our employers want our systems to run smoothly, but do they really make an effort to use data wisely? If so, then I think the company is mature. If not, maybe they’re letting opportunity pass by.

    Lots of us data professionals do look for opportunities to better use data, to build useful reports, and find new patterns in data. Whether there’s a Chief Data Officer or not, many of want to explore data and make use of information we find. I think if our organization supports that, we’ll enjoy our jobs more. If not, then maybe the job is just a job for many of us.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Securing Test and Dev Environments at the SQL Privacy Summit

    Redgate Software is putting on a one day SQL Privacy  Summit on May 18 in London at the Grange Tower Bridge. This is a chance to see how you can ensure compliance with the GDPR while keeping up the modern pace of DevOps software development. Our goal is to educate you one the ways of protecting data and minimizing impact to business processes.

    Use the code “Steve” when you register to save 25% off the standard rate tickets. I’ll be there, along with some of the sharp minds from Redgate and some local consultancies to talk about the topics of data privacy and protection.

    We’ve designed the Summit to be for both technical and managerial staff that are working to ensure compliance with the GDPR. Our schedule is designed to help ensure that you lean from our research and experience to implement three key principles:

    • Map and maintain a living data catalogue of your data estate
    • Reduce your surface attack area by protecting data in dev and test environments
    • Implement ongoing monitoring to ensure your data is protected.

    It’s a great schedule of sessions delivered by some experienced speakers and a panel that will cover these topics and more. We even have a couple workshops to help you discuss concepts and best practices with peers.

    Register today (use the code “Steve”) and I’ll see you in London next month.

  • Cloud Snake Oil

    I’m sure that those of you reading this have a variety of opinions about the “cloud”. Actually, I’d guess that many of us have different definitions of what the cloud actually means. That’s fine, since it’s really an amorphous, marketing term that encompasses quite a bit of different technologies, services, and products from many different companies. Some of you might use the cloud, and if you do, then perhaps this will ring true to you.

    I was reading Dr. Greg Low’s blog, and he asked the question in a post about what a managed service was. In this case, Dr. Low was looking to host his blog on some service, and apparently the definition of a managed service varied from provider to provider. His first provider didn’t tell him that backups were being run, with each file being counted against the space that he’d contracted for. When he asked for them to be deleted, he was told it would take a day or two as there wasn’t anyone to provide the service.

    He continues looking at how other providers define service, which does vary, but the interesting thing to me is that many of these companies aren’t really providing management of systems. They’re selling you a product, which has some capabilities, but they aren’t really managing anything. At least, that is my impression. I know if someone asked me to manage a system, I’d expect to deliver some level of service that would be useful for the client.

    In the cloud, it’s really a wild west version of computing, where companies want to sell you some service, often touting various management aspects, but they may not necessarily provide the level of service you expect. Cloud vendors, even worse than other computing vendors I’ve dealt with, want to work at scale, and they want to standardize how things work as much as possible. They don’t want to engage in person to person communications if possible. I learned this lesson with Google and their products, few of which had any way for a user to contact a help desk.

    Apart from that, what I’ve seen too often in the cloud is that a company wants to offer some service or capability, but they don’t often have the tooling available for end users. This is especially true for new services, where it seems the purchase process works flawlessly, but the configuration or cancellation process doesn’t work, or might not even exist.

    The one piece of advice I’d pass on from my cloud experiences is that anyone using services needs to reconcile their bills regularly. We can add resources easily, but removing them is hard, and often a customer service person promising removal doesn’t follow through. I’ve had people in the support centers not even be sure of what resource I was referring to when requesting removal or credit. It’s a frustratrating experience that has led me to adopt another habit. I grow resources very slowly, ensuring that I know what the billing is and that I really need the service. That seems like the opposite of what the “cloud” is supposed to offer.

    Steve Jones

    The Voice of the DBA Podcast

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