Voice of the DBA

Tag: data privacy

  • CCPA Preparation

    There’s an old Ron White joke about a small airport also being the tire repair center and hair salon. I thought about that when I saw a law firm became a software developer. I don’t know what other enterprise might make a fun trio of businesses, but perhaps a sunglasses shop? Divorces, software, and a new look?

    The CCPA (California Consumer Privacy Act). takes effect in less than a year. This is a law based on the GDPR, and the first strong attempt to regulate data in the United States. I think it’s a good move, though I’m sure large corporations like Google and Facebook will fight it and find exceptions that allow them to play fast and loose with information about many of us humans. I also think, like the GDPR, this will force many smaller companies to better secure, manage, and handle the data they process about companies. I wouldn’t surprise if this also brings about quite a bit of work for consultants and software vendors that help others better classify, protect, and manage their data.

    A new product released by a law firm is designed to help other organizations in a number of ways, based on the knowledge and experiences of the lawyers that have worked in privacy law and compliance for years. They spun off a software development company who built an application that assists with four areas that organizations struggle with: compliance with consumer requests, mapping information flow, generating policy documents, and training employees.

    I’ve worked in a few companies that needed to do most of those things to comply with some standard or regulation. It’s not a difficult task, but it is complex, it’s hard to stay organized, and it’s hard to ensure that everyone understands how the new processes work. While an Excel spreadsheet can track everything you need, once you get beyond a trivial number of employees and systems, the entire system becomes unworkable.

    Instead, some organized system needs to be in place that helps keep all your employees coordinated. I don’t necessarily recommend buying software over building it in many situations, but here I would. There are lots of moving parts when trying to organize your data practices, lots of legal rules that you have to understand, and software is likely much cheaper than legal advice. Your employees will need to learn how to use new software, buy into new processes, and alter workflows, but capturing and documentation is the first step. Once you start to have a handle on what information you store, you can then decide what to do with the data.

    Steve Jones

    Listen to the podcast at Libsyn

  • The Road to Better Data Handling

    Recently I was on an internal communication thread with multiple people at Redgate Software. We have various ways to keep our (semi-) distributed teams in touch with one another and handle issues. While email works, I think many people like Slack better for quick discussions. I appreciate that as a remote worker since I’m not around to hear a conversation around a desk. To be fair, with a busy staff, others often aren’t as well, so a thread in Slack often saves details others can see later.

    In any case, we had some issue. I don’t know if this was a product issue with a customer or a communication item for our marketing group. No matter what it was, we had someone mention they could help if the first poster would provide details. The next message that I saw was great. It said something along the lines of

    “Please do not post email details in Slack.”

    A gentle reminder, but one that was needed. It’s great that we want to help others and work through problems, but in many companies we’ve played far too fast and loose with data. Not necessarily technical people, but often our customers have. Many of them will put sensitive information in “notes” fields in our databases. It’s a hassle when we want to work with data that hasn’t been put in a normalized space and must extract it somehow.

    It’s also a source of data leakage. While we might appreciate saving a quick note, these aren’t secured communications, and more importantly, they provide yet another attack vector for problems if we lost control of the backups, archives, etc. Even worse, we could have gotten a request to remove emails and we now have another security risk with the email email searchable in old Slack messages.

    This is likely a bit of an extreme example, but still a place where data handling should be better. We have secure systems for tickets or issues where we can store data. Or we can reference their information in another way. I’ve started doing this in GitHub, where we often log issues for SQLServerCentral users. Rather than putting in an email, I’ll put a user ID or other identifier. If the user wants to delete their account, I don’t want their email floating around anywhere it isn’t required.

    While it might be a bit more hassle to be careful with personal information, I think it’s much better than treating it as unimportant and potentially having it disclosed in some security incident. Whether it’s my email, tax ID number, or credit card, I’d want my own data handled carefully and am trying to do the same for others.

    Steve Jones

    Listen to the podcast at Libsyn

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

  • Changing Context and Data Reuse

    One of the points of the GDPR that I thought was very interesting was the idea that users needed to give consent for data use for specific purposes. This had many companies trying to reaffirm consent last year while others assumed previous consent was valid. No matter how you viewed the law, any change in the way that a subject’s data was used required new consent.
    We don’t have a law like that in the US, and that allowed IBM to scrape images from Flickr to use in facial recognition software. This isn’t dramatically different from lots of scraping that goes on from other sites, where plenty of data is aggregated, but there is certainly some private data being used for new purposes. When Netflix created a contest to help build a recommendations engine, they shared data, albeit in a way they thought was anonymous. It wasn’t  and Netflix stopped trying to run contests.
    The article from Tim O’Reilly and Mike Loukidesi is an interesting look on privacy, rights, and consent for data use. Many of us click through overly broad rights agreements, many of which I think should be more limited by law and regulation. Unfortunately we seem to allow data to be aggregated, reused, and re-sold, often without any input or redress for the individuals to whom the data refers. The article notes that often the context of how the data is used changes, so it’s not whether the data is public or private, but rather how the data is used.
    I think this is a better way to examine data, and perhaps one that courts and arbitrators ought to be charged with protecting. Too many companies play fast and loose with data usage, and in an area of larger and larger data driven companies, I’m not sure I see a public interest for the rights of companies to trump those of individuals. Especially where privacy and security are concerned. Even when this might impact commerce.
    I rejoice in the tremendous amount of data in the world and the opportunities it brings for many to learn more about their lives. I appreciate the opportunities I have to work with data. I think data helps companies provide better services and build more efficient processes. I also think that many companies take advantage of the data to increase their revenues without understanding that there should be some rights for the people that did not agree to, and do not want to participate in the new uses of data.
    Steve Jones
    Listen to the podcast