Voice of the DBA

Category: Editorial

  • Fines for Data Access

    Most of us know about the principle of least privilege. After I wrote about network segmentation recently, I’d hope that most of us know that limiting access to production data from all workstations might also be a good idea. Many of us also know that unusual patterns of access might indicate an issue. I wonder how many of us have a system in place to look for unusual access, especially this is something that might help us prevent, or at least detect, potential hacking activities.

    I wonder if we’ll get to the point where we need to do more and not only implement better auditing of system, but also data access. Will we need to actually monitor what data is accessed and ensure there is a valid need to do so? That was probably needed in this case, where various employees accessed a woman’s DMV data for who knows what purposes. This is a creepy story, and I’d hope that it’s the rare man that actually does this in any company, for any kind of data.

    As a general recommendation: please don’t spy on someone that you want to date. It’s very much an invasion of privacy and no way to develop a relationship with anyone.

    There were logs of access in this case, which isn’t the case in some states, but there should be more logging of access. The default “black box” trace in SQL Server doesn’t give us much information, though if you have a monitoring system in place, you likely do get more data. The logs of who and what are important, and they are something I’d like to see built into SQL Server by default, an easy way to log activity, with some archival/management of the data.

    Too many of us don’t log anything, and maybe it’s not important for some applications, but in the cases where sensitive data is stored, I think logging ought to be required, and I’m hoping GDPR 2.0 or other laws mandate this, perhaps with some retention of a year. I know I’d certainly like to see this built into more applications.

    The way we handle personal information has been poor for most of the digital age, and I would like to see that changed in a number of ways. I think requiring compliance against a standard might be the best way, though without specifying an implementation. This way we accept the responsibility of safeguarding data that we already should feel.

    Steve Jones

    Listen to the podcast at Libsyn

  • Balancing Hard and Soft Skills

    Many of us would prefer that the technology industry were a strict meritocracy. One where we get opportunities and are compensated according to our skills. We learn to code better, or manage more systems, and we’re seen as more valuable (and rewarded appropriately). Or maybe many of us would prefer that things stay the same, since we might worry that we’d be paid less because our skills aren’t as sharp as our co-workers or our competition for that next job.

    In any case, we don’t work in a strict meritocracy, but if we did, we might recognize that it’s not just your programming skills that are being measured. In this piece on hard and soft skills, the author notes that the importance of soft skills is both more and less serious than we might imagine. If that sounds contradictory, it is, but read the article and you’ll see that this is a complex issue.

    The main point from the author is one that we’ve realized at Redgate for some time, and it’s why we’re constantly refocusing our efforts on teamwork. Most modern systems are too complex to be built by one person, which means a group of people need to work together. DevOps asks us to build a culture of collaboration and communication, which are critical soft skills. It matters less and less if you’re an amazing developer that can’t work with others for some reason.

    I do think that the more you advance in your career, the more important these skills become as your job is not just code. It’s also helping shape the direction of software, teaching others, and sharing what you know. If you don’t have the skills to interact well with others, then I suspect your ceiling may be lower than you like. Or worse, your tenure shorter than you’d prefer.

    At Redgate, we do embed a lot of customer research, discussions, and more inside development teams.  At times, I think we do too much, but then I stop and think about the teams I’ve worked with that didn’t do this. They didn’t necessarily code quicker, certainly lacked understanding and empathy, and certainly didn’t make more customers happy. We’re trying to adopt more soft skills inside the company, while learning to build better software. We still value technical programming skills, but not necessarily above teamwork. More alongside teamwork.

    To build a team, we need to value those in the team, and work with them, not against them. Those are skills that can certainly help us in our career, as well as skills that help any organization learn to operate more smoothly, with more retention. At least, more retention of those that have strong soft skills.

    Steve Jones

    Listen to the podcast at Libsyn

  • 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