Voice of the DBA

Category: Editorial

  • Hiding Data Isn’t Always Easy

    There is an article about redacting data in a report done poorly. A consulting firm hired by Frontier Communications wrote a report and redacted lots of information. However, they apparently didn’t do a good job as all the information they blacked out could be read if the data were copy and pasted elsewhere. Something that’s much easier in digital reports than analog ones.

    This was a PDF document, and I checked it. On page 25, there is this sentence: ” Annual capital expenditures for Frontier’s West Virginia local exchange carrier companies have averaged over XXXXXXXX for the past nine years.” The XXX is blacked out, but pasting it into a document shows this is a $70mm amount. It pays to know your tools.

    This certainly isn’t a good technique for hiding information, but it’s not far off from what some people do when trying to mask or obfuscate sensitive production data in development environments. There are lots of cases where people use scripts that change data in one table, but not related data. Or that the changes are incomplete and don’t do a good job of ensuring there isn’t sensitive data leakage.

    To be fair, this is a hard problem, and there are no perfect solutions. Anyone masking data likely needs to take a few passes at the problem, making adjustments over time to try and ensure that the data is protected from unauthorized disclosure. There also isn’t a perfect solution, as many researchers have found ways to reconstruct the original data after it’s been anonymized.

    This is an area that I think is still somewhat immature, with relatively few best practices available for anyone to look at. While I have seen some guidance, I don’t see much on how one could verify they had done a good job. I hope we find ways to do better in the future, with more knowledge that helps data professionals ensure they are doing a good job. Otherwise, we won’t be able to protect data the way we want to protect it.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • BYOD Fingerprint Concerns

    Many modern devices, whether mobile phones, tablets, or laptops, contain fingerprint readers. We’ve had readers for a long time, but they were very expensive and not widely deployed. That changed with mobile phones and now many devices include fingerprint readers as standard equipment. So much so that this seems to be a very common way of authenticating access on lots of devices.

    This isn’t necessarily a very secure way of protecting data. An ArsTechnica article notes that fake fingerprints were able to access these devices 80% of the time. That’s a success rate that might worry a lot of security personnel. Most organizations allow some sort of BYOD device, including many financial, medical, and other organizations that deal with sensitive data. Since control of a device often includes saved credentials and the ability to approve 2FA implementations, this could be an issue.

    Certainly nation states might try to take advantage of this to gain control of a device and access data from other governments, but I’m sure corporate espionage is in play here as well. I wouldn’t be surprised if this also becomes a technique for pranksters and jokers. Imagine you can bypass the fingerprint on a colleague’s phone. Maybe you want to change their wallpaper. Maybe you want to send an embarrassing email to friends. Maybe you want to add a backdoor to some code using their GitHub credentials. You could do anything from an innocuous joke to a malicious career threatening action. Imagine you choose to do this while your colleague is at lunch, with their phone forgotten on their desk.

    No security is perfect. Many of us that work with someone often might be able to guess a PIN or pattern on a device if we see it often enough. We certainly could easily put a keylogger on a wired keyboard at someone’s desk. There are plenty of vulnerabilities, and in this age of being highly connected through our devices, there are potential issues with all access. There’s no perfect solution, but we should be diligent with physical control of our devices and react swiftly if we think one might be stolen. Remote disable and a good backup might be top of my list.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Teams That Ship

    These days there is pressure on many software development teams to ship software more often. With the growth of DevOps and the numerous stories about companies that update their applications regularly, more managers are putting pressure on their development teams to perform. This can be a challenge as the culture changes needed to alter the way we work and achieve frequent updates are difficult to achieve.

    I saw a post from an entrepenuer, Naval Ravikant, on building a team that will ship software. This is advice for a startup, which often has different goals, challenges, and structure than more mature teams. Certainly I’ve seen the way we’ve built software at a few employers change. Even at Redgate Software, what we do to build software wouldn’t the same as what we did as a small company with 10 people.

    As I read the list, I can imagine why some of this advice is there. The need to push forward and get software working and in front of customers is strong. Sales, marketing, and certainly the users of the application want to see things move forward, features added, bugs fixed, and a reason that someone will pay money for the software. This rapid pace requires some decentralization, some lack of control, and trust in your developers.

    However, at some point this isn’t the model that a more mature organization needs. While we do want people that get work done in small teams at Redgate, we’re also more mature. Allowing developers to work on whatever they want isn’t in our best interest, and it could mean some products wouldn’t get any attention. We also have somewhat large codebases, so a person per project isn’t ideal. In fact, we often get code done in groups.

    I think I might be more inclined to adapt some of these goals with a startup, and certainly in a PoC or early access/beta product. However, once clients are invested and paying, I think a little more coordination and collaboration is likely needed. Not a lot, but a little.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • 1000 SQL Saturdays

    One thousand is just a number, but it’s also more than a number in this instance. One thousand is a milestone that I couldn’t have imagined a decade ago when thinking of SQL Saturdays. PASS has announced that SQL Saturday #1000 will be on October 24, 2020, in Portland, Oregon. Congrats to the team there, they’ve were one of the first to hold an event, have had many over the years, and I hope I have the opportunity to attend.

    I wrote a few thoughts for the PASS blog, as did my fellow SQLServerCentral founders, Andy Warren and Brian Knight. The three of us have spent a large portion of our careers trying to educate and help others become better data professionals, and we’re all proud of the way all the organizers have worked to plan and run SQL Saturday events. We’ve amazed that so many community members have stepped forward to share their knowledge and speak at the more than 100 SQL Saturdays that occur each year.

    Reza Rad produced a PowerBI report that shows we had 4 people speak at a 100 or more events. Kevin Boles (134), Kevin Feasel (115), Janis Griffin (107), and Rob Volk (100), all of whom deserve a virtual round of applause for all the time and resources they’ve donated to the community. Many others are on the list with dozens of events and hundreds more have spoken at a few events. If you scroll down the speaker section of the report, it’s an amazing and impressive number of people that have spoken at more than one event. An amazing way to support this community.

    We’re data people, and numbers often have an impact on us. While we’ve had 20 PASS Summits, we’re about to have 1000 SQL Saturdays in a fraction of the time it took for those 20. I hope that more of you get the chance to experience one in your area sometime in the next decade. I also hope more of you decide to step forward and help organize or speak at one of the next thousand.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.