Voice of the DBA

Tag: security

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

  • Encryption Libraries

    One of the ways we work to implement better security is through the use of encryption. I remember the early days of PGP, VPNs adding end to end encryption, IPSec becoming available, and more. I was excited to see column level encryption come in SQL Server 2005, but it was a bit complex to implement and had issues. The evolution over time with TDE and Always Encrypted were welcome additions, but we can do better.

    Handling encryption in the database can provide some protection, but really, we’d like to see an end to end solution, that ensures data is protected on the wire as well as in the db. Microsoft does a lot of research, and released a Simple Encrypted Arithmetic Library (SEAL) as open source code. This is a C++ library that developers can use to protect their communications. Last year they also released a .NET wrapper to make it easier for a wide variety of developers to use.

    There is a lot more to deal with when handling encrypted at scale. Indexing and search operations are difficult and complex, and can require lots of resources. I think that the Always Encrypted in SQL Server 2019 with Secure Enclaves is a good evolution, but it’s complex to set up, tooling is poor, and maybe more disconcerting, there are potential vulnerabilities with secure enclaves on Intel chips.

    Certainly a combination of developers being able to use something like SEAL and a linkage with a secure enclave on the server for set-based operations might be something we can look forward to in the future. I hope so, as security continues to be a challenge for many of us.

    I’d also like to see more software that is built to ensure users can’t access huge amounts of data, and perhaps easier ways to control the export of large amounts of data. We do need this capability, but we also want very few people, or no people and only a process, with rights to do so.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Don’t Lose Data Without a Hacker

    The GDPR has been law since 2016 and been enforced since mid 2018. California has the CCPA in law, but not being enforced. In any case, it’s 2020 and we have lots of tools and knowledge about securing systems. We aren’t perfect, and certainly Microsoft isn’t, but we should be avoiding simple mistakes.

    For those of us in the US, or outside CA, we might be less worried, but if you’re in the EU, you should be concerned. Here is a mistake by Virgin Media, with data exposed for months. Someone configured a database, likely set it up for access remotely, and didn’t do a good job.

    It does start to feel that we ought to have some sort of security smoke test in every organization that checks for exposed databases in our networks. Perhaps we even ought to have this for all subscriptions with vendors that host services for us in the cloud. That might be good for IT people, but what about shadow IT, or the average person that just wants to share data with co-workers?

    No one ought to be able to configure a file share, an S3 bucket, Azure BLOB Storage, or anything similar by clicking in some sort of control panel. Honestly, I get that vendors want to make things easy, but we need security over data in all organizations. There ought to be a “configured” click to share button that runs a series of scripts to ensure we have secure controls over resources. File shares might be hard, but for databases, there’s no excuse.

    I do know that for some people, it’s a pain when they can’t create databases. I deal with customers regularly that have this restriction on developers, and it’s problematic. However, we need better security, and really, we need less real data being shared so widely. As an industry, we need better dev data sets, and we need better security protocols over any production data.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Secure Enclave Concerns

    We worry about security as data professionals. It’s a constant issue, though it seems that so many of the data breach issues come from simple mistakes. We have lots of automation, configuration as code, and more. These days we should have a protocol and automated process for setting up systems, file shares, and other ways of allowing others to access data.

    Awhile back we had attacks against hardware (Meltdown and Spectre), which required patches to systems to secure them. This was disruptive, but I haven’t seen any widespread security issues as a result of these flaws. Many systems were patched, though it’s entirely possible that there have been exploits.

    In a report this week, researchers have found a way to read data in the secure enclaves of some chipsets. That’s disconcerting because lots of secure software counts on the Intel Software Guard Extensions (SGX) protecting data. This is part of the Always Encrypted enhancements in SQL Server 2019, which I was happy to see added. These are supposed to help ensure you can protect data, even if you don’t have control of the physical machine, which is common in hosted and cloud scenarios.

    A new exploit could be a problem. Intel says it’s not, but they have an interest in saying that. The research looks complicated, and I could certainly see this is hard to do, but attacking a large environment, like a cloud subscription, might be something hackers try. Even if they aren’t successful, there may be performance issues with SGX calculations from a software patch.

    The point of this piece isn’t to alarm you. Likely this is more speculative than reality, but you should be aware there are potential issues. Encryption and security are complex topics, and I’m hoping Intel and Microsoft (and others) come up with better protections and mitigation for the issue. However, ultimately it’s up to us tech professionals to understand what possibilities there are and ensure we are taking every precaution we can.

    Steve Jones