Voice of the DBA

Tag: security

  • We Do Need To Upgrade

    I advocate that we should get a long life from our database platforms. In fact, I like to think about a 7-10 year lifetime for many of my database instances. That means I’ll get beyond the 5 year lifetime that Microsoft provides and move into the extended support. Actually, for most of my career, I’ve run instances without support and haven’t had issues. We invest a lot in databases, and I want companies to invest a lot because they are important. That means I need a good payback.

    Microsoft should provide security patches for products throughout the Extended Support period, which means that I should be able to run SQL Server and Windows securely for 10 years. that probably stretches the lifetime, but certainly that gives me time after five years to begin planning and prepping for an upgrade.

    The problems for many customers come when other vendors don’t bother to keep supporting older software and providing patches. Even if Microsoft releases a security fix for your OS, the vendor that makes software you run on top of Windows or SQL Server might not. That’s an issue, and it’s one that will become more of an issue as companies become reluctant to change software that works well.

    This article shows that older ATM machines running XP and Windows 7 are having issues. Some of this is physical access, but some is related to issues in the OS. While Windows 7 should be getting patches, Windows XP is not and needs to be upgraded. In fact, I’d argue that any losses here should be born by ATM owners and not covered by insurance for not having upgraded their systems.

    While I like to get as much time as I can from a system, it’s irresponsible to expect software to run without security patches being actively applied, which includes any upgrades from vendors. In some cases, this might be negligent by the companies doing so, especially for embedded systems. I don’t know that I want governments to force vendors to provide patches, but I’d like companies to write contracts that ensure that patches will exist for come lifetime of the products. In the event the company can’t provide patches (or certification), then they’d need to release their code as open source so that someone can provide a patch.

    The world becomes more intertwined and dependent on computing, from things like convenience services or core systems. We can’t have those systems becoming more vulnerable because companies are unwilling to upgrade and vendors abandon older software. Some sort of compromise is needed to ensure that computer systems are protected from known vulnerabilities.

    Steve Jones

  • Are You Patched?

    It’s been a few weeks since the Spectre/Meltdown bugs were announced for most CPUs. Microsoft has been working hard to build patches, and they’ve provided fixes for Windows and SQL Server. Other manufacturers have released fixes for other platforms, though I wouldn’t be surprised if more patches are coming. We put together a page at SQLServerCentral with information and links, and if you haven’t checked it out, you should.

    If you haven’t patched systems, patch them ASAP.

    This is a bad bug, affecting many CPUs, across multiple architectures, and includes potential issues with virtual machines. The guidance and conversations I’ve heard from various vendors is that many of them aren’t completely sure of all the potential risks or attack vectors, but they are worried that customers will leave this vulnerabilities open in the future. Since this affects hardware, it’s entirely possible that an exploit could read memory from other applications and processes.

    Again, if you haven’t patched systems, patch them.

    There are reports of potential issues, so everyone certainly needs to test systems. Perform a P->V (Physical to virtual conversion) and patch a VM. Make sure the server still runs. If you’re on VMs, snap a copy and patch it as a test. Older processors might see a performance penalty with the patch, but worse performance is better than having a security hole in your CPU available to operating systems.

    This is the type of fundamental architectural bug that’s is very worrisome. The race to be efficient, to copy what works from others, this leads to less innovation not more. I hope that this is a bit of a lesson that we do need separate architectures and approaches to computing problems, both in hardware and software. I love relational databases, but I’m glad that there are other types of systems being used for data storage. I think Windows works really well, but I like competition and think it’s good that we have MacOS, Linux, and more.

    It’s good to have standards and interoperability, but I do think that a heterogeneous environment is good for security, and I hope the world continues to try new architectures as we advance computing ever further.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.1MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • The GDPR Sky is Falling

    David Poole wrote a nice summary of the GDPR regulations that come into force this spring in Europe. He covers a number of the sections, trying to provide a simple explanation of the potential issues from the perspective of a data engineer. That’s likely the role most of us fill , and I think David does a good job of trying to note the items that he (and maybe you) need to be concerned about.

    If you want to read the full text, and you should, it’s here. To me, this is a more sensible, easier to understand type of regulation. It’s way better than SOX and most other regulations I’ve had to deal with, with a better view of balancing the idea that companies won’t have all the answers, and might not choose the best technology but do need to make an effort. I don’t think this will excuse just continuing to do business as you have, but it does read as though courts and authorities will have flexibility in their interpretation.

    One of the main things that should be pointed out is that the 10 million Euro fine is a max, not a minimum. The same things goes for the potential 2% of global turnover (revenue for the US folks). These are the highest potential penalties, though if you have made some effort to protect data and comply, I doubt you’d see fines at this level unless you’re negligent.

    The keys parts of this regulation are that companies should be paying more than lip service to data privacy and protection. They should be designing and building software and infrastructure that protects data, and also considers the point of view of the individual or organization that is the subject of the data. That’s a good move, in my opinion, having us actually think about the data and the ramifications of its use, sale, transfer, and release, rather than just focusing on our own goals. Most data professionals I know keep this in mind, so GDPR is a step in the right direction to push management to care.

    We’ve got information at the Redgate site, which will help guide you. We are building features into existing and new products, and we’d love to sell you software if you can use it, but we’re also learning and trying to share what we know. This goes along with the core values at Redgate of being a part of the community and giving back, through SQLServerCentral, Simple Talk, blogs, and more.

    Ultimately no one knows what GDPR will bring, and its application can present a risk to any of us that gather data from EU residents. I know Brent Ozar as already decided to stop EU business for the time being to avoid taking on this risk, and I’m sure other small companies may do the same thing. In one way that’s a shame, though a reasonable decision for a company. In another way, this opens opportunities for other businesses. People in Europe still need goods and services, and there are plenty of ways to comply with GDPR that I don’t think will be too hard, especially for those businesses based in Europe that won’t have a choice. There will be other companies that can fill any void left by companies that cease working in the EU.

    GDPR isn’t the end of the world. I think it’s a good move in the right direction to balancing data value and protections. I’d like to see a better framework in the US that also ensures individuals have rights to exercise some control over all the data being gathered about them, as well as something that forces companies to actually consider data protection in their systems. There may be some bad results from GDPR, but most of us will adapt and continue to do business as we have in the past, albeit with better data controls.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5.4MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Fixing logins

    I ran into an issue recently where I couldn’t get a Windows login to work with some application software. This software had been configured with a user account, which appeared to be in SQL Server, but it couldn’t connect.

    It turned out that the local name of the workstation had changed. In this case, I’d renamed a Windows host in a VM, and my login was automatically renamed in Windows, but not in SQL Server.

    A quick fix. In this case, I needed to just alter the computername in the login with this code:

    ALTER LOGIN [WIN2016\fileshareuser]
WITH NAME=[SJ-DEMOSITC1\fileshareuser]

    Once I did this, everything started working again.

    It’s rare that we rename items, but it does happen, especially in lab environments. It’s good to know how to remap any of those principals that might be affected if it happens to you.