Voice of the DBA

Tag: security

  • The Best Way to Protect Sensitive Data

    I was listening to someone talk about data privacy recently, and the ways that you can protect the sensitive information in your databases. They had a great quote about something you might consider. They said, “The best way to protect data is not hang onto the raw data at all.”

    If we don’t have sensitive data, then a loss of data can’t occur. Hacks won’t cause issues, we can’t accidentally send out data or leave it lying around. There’s a good case to be made that keeping less sensitive data around is a good idea.

    For some applications, we can’t avoid keeping sensitive data. Medical databases keep private health information. E-commerce systems likely need financial information. Many of us will definitely have to deal with some sensitive data, and protect it, but we can minimize our struggles.

    We often don’t have a good reason for keeping lots of data around. Lots of queries run by users end up looking at only a small portion of data. Often recent data is needed, and some aggregates for older data, but we don’t actually look at the details of old data often. We may even have older data around that we’ve forgotten about, and our users don’t even know is available.

    We certainly don’t often need sensitive data in non-production environments. Plenty of people use scripts or tooling to obfuscate, anonymize, generate, or otherwise ensure sensitive data isn’t in unprotected environments. We can archive, or even change, old data to ensure it isn’t a liability. We can even do this in production, preserving metrics, but delinking data from any individual.

    I’ve always been someone that kept more data than necessary, just in case I needed it. However, over time, I find that the costs, and the potential risks, just aren’t worth it. Moving forward, archival, anonymization, and other strategies need to be a part of any system I manage.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • A Need for Monitoring without Administration

    There was a report recently that a number of US government agencies were hacked through a network management system. Apparently Solarwinds had their code hacked, and this resulted in a backdoor being distributed to customers via software updates.

    There is a lot that went wrong here, and this ought to make many system management software vendors very nervous. Attacks on your software developers, designed to allow a hacker to put backdoors into source code repositories is a wild second (or third) order attack. I would certainly be nervous to be a software developer right now, and be extra cautious about any sort of potential phishing email sent to me. Yes, that’s a thing.

    The bigger issue, to me, is that monitoring most systems ought to be possible without requiring escalated privileges. While there are some ways to get metrics without requiring administrative rights, most OSes and most administrative and monitoring software expects to have complete rights to all resources.

    That’s a hole in design. There are plenty of cases where we want monitoring data (and alerts/notifications) distributed to other automated systems or to interested individuals, but we don’t want to expand the number of administrators. Every additional individual or system that can potentially change something as an administrator is another potential attack vector.

    We have built our core operating systems with the idea that someone needs complete control of the system to work with it. For some things, that’s true, but for resource usage, especially in the way that many of us need to watch at scale, I’m not sure that this needs to be the case. My view is that Windows, MacOS, and Linux ought to undertake fundamental design reviews to determine if they can further shrink the scope of privileges for monitoring systems.

    In the meantime, granting privileged access to an automated system for monitoring ought to be done very carefully, even more carefully than for human sysadmins. This account will run by itself, and someone might not notice if it is compromised. Set strong, very long passwords, change them periodically, and audit the account to be sure it is only accessing what you think it should access.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Prized PII

    If I asked you what specific type of information criminals would like to capture about you, what would be your response? Take a minute and think of something and then leave it in a comment after reading the rest of this.

    I know that usually more than one piece of data about me is needed, and while most of this data is probably somewhere in a database, and perhaps leaked in a breach, it’s not necessarily organized. I still think it’s good to protect information where I can. Every year my wife laughs as people wish me Happy Birthday in Facebook, on a day that’s not my birthday. I think any day is as good as any other to wish me well, and so I disclose April 1 to my friends. In fact, I often disclose a slightly incorrect birthday when sites and organizations ask me, unless I have some legal obligation to type in my real date.

    There was an article that caught my eye about the data that thieves most often want. It opens with a story about pharmacists using personal data to bill insurance for non-existent medications, which is criminal activity for sure, but there’s not much you can do about these people using your data. The piece then goes on to talk about the value of healthcare fraud and how data related to this is even more valuable than credit card numbers.

    That isn’t something I’d have expected, though, I do live in the US. With the high cost of healthcare, I shouldn’t be surprised. Fraud is big business, and there is a large volume of claims, providers, and statements that people have to review. If you’ve tried to go through your statements, they often don’t seem to be easily relate-able to the treatment you may have received. I think this creates opportunity for fraud, as it might not be something an individual can catch.

    I haven’t worked with healthcare data, but I suspect anyone that does will need extra protection on their systems, and certainly encryption along with the prevention of PII in non-production environments is important. I also think this is the type of data that you may want to be more careful about in your own life. Though how you can be more careful escapes me.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Completely Encrypted Data

    I remember reading about, and doing some message exchange, with PGP, in the 90s. At the time I worked in a utility company and my boss and I were interested in whether encryption might be something we should implement. At the time, the integration with mail clients, and the relatively unsophisticated users limited our options, and we never moved forward, but I’ve always been interested in encryption and how it fits into our digital world.

    The technical bits have gotten easier, with https encryption automatically enabling for most of us, though perhaps only preventing limited attacks. We’ve gotten more options in the data platform, some that work well, some that require a decent coding effort, but they do work to some extent. At least, they make auditors happy and prevent silly leakage from something like a lost disk drive.

    One of the main areas where encryption has been controversial is in real time communications. Governments and law enforcement want to be able to eavesdrop on criminal activity, or maybe other activity, and individuals want privacy. This seems to be an ongoing battle between technical companies and lawmakers as to how to implement features and what limitations should be enabled. I noticed a story recently where Google is rolling out end to end encryption in its messaging apps.

    That got me to thinking. We capture and store data, and we may have some sort of communications in our system. If users demanded, or application developers built, end to end encryption, do we care as data professionals? Certainly we would need to allow for binary storage, and we’d lack insight or indexing into the actual data, but certainly could work with metadata like user, time, etc.

    There are also other considerations for us. If we store encrypted data, is this more of a hassle in dealing with legal requirements? Do we want to have another sort of PII in a key or have to constantly explain to management or legal staff that we can’t read the data because we don’t store the key? There are non-technical burdens that we might not want to shoulder.

    I do think that more systems ought to allow end-to-end encryption for communications, and user-managed keys are a capability that plenty of us might want in a world where no one physically sees the database server or disks. While I do like the idea of secure enclaves, which are catching on in computing, I also think that key management, especially for users, needs to improve. Perhaps we need a password manager for certificates, with backup included, to ensure our end users can properly manage their certificates across devices and in the event of any personal disasters.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.