Voice of the DBA

Tag: security

  • Hacking the Admin

    Recently Twitter had a security breach, with a silly scam. At least, I’d think it was silly. I saw a tweet from Elon Musk noting that he’d return $2k in bitcoin for every $1k anyone sent to him. He was feeling generous.

    While that might seem silly, a number of other high profile accounts were breached and seemed to lend some level of veracity to the offer. I saw a few news reports that the hackers made off with over US$100,000, so apparently at least a few people were fooled. Twitter locked down verified accounts for a bit while it investigated, removed some tweets, and tried to close the security hole.

    What is disturbing here is that apparently the hack took place through Twitter syadmins, with privileged accounts. As of this writing, it isn’t clear if this was social engineering or a sysadmin worked with hackers, but there were internal tools allowing Twitter employees to post tweets on behalf of users.

    I have no idea how this happened, but I’m assuming this is some sort of data change made to their system. If this were an RDBMS with a “tweets” table, this would be adding a row to the table with links to the verified accounts’ linkage. Not a hard change in the SQL Server world, and certainly the type of change that most admins could make.

    The question might be should they be allowed? Many of us have made ad hoc data changes to systems to correct an issue, and some of us do this regularly.

    This reminds me of some customers whose DBAs aren’t allowed to directly connect from SSMS (or other clients) to production and make changes. All changes, including ad hoc data changes, must be submitted to some sort of pipeline, where the change is logged, and perhaps approved by someone else. A different sort of two factor authentication.

    Should this be a more common pattern of access to production systems? Limiting access by everyone, even admins? I know we need to trust administrators, but what happens when administrators get fooled by social engineering? A thorny attack vector that we ought to be considering in our architectures.

    Steve Jones
    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Jumping Air Gaps

     

    There are all sorts of viruses, worms, and malware out in the world, and some of us have had to deal with them at different points in our career. SQL Slammer was particularly memorable for me, but there were plenty of non data related virus issues I’ve had to work on at various employers.

    To keep sensitive information safe, many high security environments have built air-gapped computers, where these systems aren’t connected to a network, or at least not a general network in an organisation, and certainly can’t access the Internet. At home, you could think of this as an older computer with no network card, or even a spare laptop with a broken network radio. To get information to/from this computer, you’d use some sort of removable media.

    Apparently there are concerns about malware being able to jump this air gap, using the removable media. Nothing terribly new here, as infected USB sticks have been a concern for years, but this appears to be a twist and apparently the malware waits for a chance to send information off to a receiver.

    If your system is truly air gapped, then there might not be a way for this information to be ever be copied, but what if that isn’t the goal. Imagine ransomware uses this technique and infects database backups. If you have an offline place for backups, could a copy of a new backup infect other backups? With separate tapes this isn’t an issue, but if you use some sort of part-time connection to move data, this could be an issue.

    I’m always wary of online backups or even live copies of data. I know many large systems find tape unusable and impractical, but I know that having physical copies of tapes ensured some level of security for my backups.

    The creativity of malicious actors and the threat vectors they devise are scary and incredibly hard to guard against. I don’t know what the best solution is for data and database backups, but I certainly hope that someone smarter than me is working on the problem.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Defending Against Ransomware

    I don’t manage production systems at Redgate, and I’ve not seen us have any disruption in the access to systems across the last few years. At a number of events, however, I’ve spoken to friends that have told me about the problems they’ve had with ransomware. I’ve been quite surprised how often this happens, as I see headlines, but none of the half dozen or so people I spoke with have worked at any company in the headlines. This is likely a bigger problem than I thought.

    I don’t know if you’ve been attacked, but you should be prepared. Denny Cherry has had to deal with this at at least one client, and he wrote a few things down in this article. He doesn’t necessarily recommend you pay, though that’s certainly an option. If you do, you should be prepared for future attacks or other issues. Anyone that wants to hold your data hostage once might be inclined to do it again.

    Apart from backups, air gaps, and other preventative measures you might take, including limited access between some workstations and servers, you ought to be sure you can rebuild systems that work in a similar manner to the current ones. Do you know what the specs and settings are for all your systems now? So many people assume they could just go get that information from the system itself, but what if you VMs and VM host are compromised? What if your monitoring system is encrypted? Do you really know all the settings that have been changed from defaults? If your DR plan somewhere outside the network and can you get to it?

    This is a good reason why DevOps and infrastructure as code (IaC) are important in a modern organizations. In these cases, a VCS can hold the data you need to rebuild systems. This is a good reason by using GitHub or some remote VCS might be better than self-hosting your code. If you routinely rebuild systems for dev/test, you’ll have some idea of how to deploy, and if you think about IaC as a part of your DR process, you should be able to redeploy on new hardware (or existing hardware that’s wiped clean).

    Ransomware is a part of the new world we live in, and we ought to be prepared to defend against it. Ensure you’re ready today, because there will likely be a ransomeware or other types of attack in the future. The more prepared you are with better practice now, the more likely you’ll be ready to adapt to some other security need in the future.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Remote Data Challenges

    With many of us working remotely now, security is going to be a concern for many organizations. While some might have company provided hardware, many of us will use our personal equipment to connect to data and systems. This brings even more challenges to ensuring security than we’ve had in the past. This might be especially true for organizations that have (or are) scrambling to get everyone connected and ensure access.

    There are a number of areas in which this might affect us as data professionals. First, we should ensure our devices are patched. Windows, OSX, Android, iOS, whatever platform you run, you ought to be properly patched. This might be especially disconcerting for some home users that run older versions of host platforms. This might be especially true for networking stacks, which have grown more secure over time. It is important for most of us, especially when using privileged accounts, to have fully patched devices.

    There’s also the issue of viruses, ransomware, and more transiting from home systems to work platforms. I know some companies are doing lots of work through remote access, but that’s not practical for many of us. I do think the idea of separating out traffic to production systems is a good one, and requiring some sort of remote terminal to a jump box might be preferred. Having some sort of PAW is a good idea as well, though not always easy to set up, especially right now.

    There are still the actual access rights and least privilege principles we want to maintain. Even as people struggle to get work done remotely, opening up all resources to users that want them can be a poor choice in many companies. We want to maintain adherence to good practices while working in an unfamiliar environment.

    There is also the idea of good data protection. This piece talks about DR and data protection, something that many of us data professionals think about regularly. I don’t know if organizations want to add home machines as remote backup targets, but we should certainly ensure that documents, code, and other information is protected. Workstations and laptops are going to fail, as we want to minimize data loss. Having version control for developers and default save locations that are remote are good practices for remote work. I know I keep most of my data in remote git repos, Dropbox or OneNote drives, or some other shared location that will persist if my hardware has issues.

    While many of us try to keep moving forward at work, and our management certainly wants us to do so, we should keep in mind the security and data protection are still important parts of our jobs.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.