Voice of the DBA

Category: Editorial

  • Audio Attacks

    There are running jokes about how Amazon Alexa and Google Home are susceptible to visitors in your home. It’s become a bit of test from some geeks who will walk in your house and call “Hey, Alexa” out loud to see if you have a device that’s available. I even had an accidental Siri activation while recording some content recently. I said something that started Siri listening on my phone and then a few people nearby kept trying to duplicate the effort. Fortunately Siri wouldn’t come on, so no one was able to cause too much trouble. I suspect that the speakers in the recording room weren’t positioned well enough to allow the control room based hacking.

    I know that will change. In fact, even if Apple and other companies manage to get digital assistants to recognize specific people’s voices (as rumored), technology marches on. People are already starting to fake audio data. The fidelity of digital recording and capabilities of speakers improve constantly. This is going to be a greater and greater issue over time, and I have no idea what security technique will prevent things. Maybe we need two factor authentication for audio commands? Won’t that defeat the purpose?

    As data professionals, we are going to be dealing with more and more types of data, and trying to process, analyze, and act on information. This is one reason that I think understanding data lakes and being able to import and combine many types and formats of data will be a valuable skill for all data professionals. Whether you use something like Azure Data Lake or another platform, I expect to be combining data in all sorts of ways and providing information to users.

    While speech recognition might not be something many of us worry about, will we want to extract information from audio or video and use it? Do we expect that audio files have more integrity than other sources? I worry that we give some types of data more veracity than others, when all types are subject to hacking. Some of us may get audio files as data, and it’s only a matter of time before we get hacked, perhaps with fake audio.

    One of the issues we have with some data is determining the source of record. If I record my voice as a sample, and you compare all future audio of me to that sample, you can verify my identity, right? What if someone can fake my voice with simple software? It sounds crazy, but those days are coming, especially if our systems are susceptible to a person stitching together words from different captures, such as some of Baracksdubs. What might be worse is when we find someone hacking a database and replacing the samples. What’s the source of record then?

    As I spend more time in this business, I become more convinced that auditing and monitoring are more important that security. We want them all, but I’d rather know I have an issue than assume my systems are protected because the security doesn’t appear to be broken.

    Steve Jones

     

  • Naming Conventions for the Cloud

    There are plenty of controversial topics in technology to write about. Today I want to combine two of them into one piece: the cloud and naming standards. I’ll leave tabs v spaces and language choices for another day.

    I like the cloud, and I especially like Azure. I’m not sure that it fits with most applications and organizations and at times I question the value for some parts of the platform, but overall, the ideas are great. I tend to work more in Azure because I’m an MS stack person, but I suspect AWS and the Google Cloud Platform are similar. Many of the cloud platforms, or even the various services from vendors like Rackspace offer lots of opportunity and an amazing set of platform services.

    However, as there are more and more options, tracking the various items and services that you are using becomes an issue. This isn’t a new problem, and I’ve faced the same issue in large Fortune companies. Inventory and management of any technology at scale is hard. This brings me to naming standards. Many of you have probably dealt with naming standards in development and perhaps argued about the choices that your team uses.

    There are also issues for infrastructure, which can be more complex and problematic in the cloud. Because we don’t have complete control over devices, we are limited to managing our objects through interfaces. At least in my data center I can fall back on labeling or connecting to a physical box to determine what services are running. Or even turning a system off to see who complains, something I’ve had to do in the past.

    In the cloud, the world gets confusing quickly because we have many more types of services. Not only items like VMs and databases, but we can have network interfaces, disks, storage accounts, load balancers, and more. In fact, the list in Azure has gotten extremely long. The addition of things like Azure Functions and Azure Logic Apps have me worried that we’ll start to lose control of our infrastructure. The one thing that I appreciate is Resource Groups, which allow me to put groups of items together.

    However, even with these tools, I sometimes find myself confused over what’s running. When I ran across John Paul Cook’s post on naming standards, I realized that I needed to get better organized with my resources. Having some sort of naming standard might help me quickly identify items and keep my portal organized. Even with the various icons, sometimes I get them confused because there are so many different possible icons and services. With a prefix and a resource group, maybe I’ll be better able to track which items I need to keep and which I don’t.

    As you grow the number of anything, the overhead for organization and management grows. It becomes more important to track what you have and use, especially when you’re being charged by the resource. I expect that many of us will be answering questions and reporting on not only usage and performance, but also cost for some part of our jobs as more applications move to the cloud.

    Steve Jones

    The Voice of the DBA Podcast

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

     

  • Listening and Taking Action

    One way most of us would like to work is to have others listen to our concerns, our requests, our requirements, and then take action to help us. One of the principles of DevOps is just this. We work together and optimize the entire system, increasing the flow of work, and not just trying to ensure our particular task or part is improved. I would hope that most of us would actually take time to listen, evaluate what we hear, and then move forward in a way that is a good decision for both parties. We certainly might debate about what action makes sense, but I would hope we could some to some consensus and decision.

    Microsoft is listening and responding as well. They aren’t building SQL Server based on everything we file on Connect or complain about, but certainly they are listening to some of our concerns and requests. There is a good post that look sat some of the community driven enhancements, which are being included into SQL Server 2017. These are different customer and community requests that were given some attention and added to SQL Server 2017.

    These don’t seem like big changes to me, but as I read through them, a few seem to go quite deep into the engine, and I’m sure there was quite a bit of testing to get these completed. You can test them in SQL Server 2017 today, helping to ensure they work correctly in the final product. Some of these will change the way you run backups or diagnose issues, perhaps even enough to consider an upgrade.

    I especially like that performance of smaller databases is addressed with backup improvements. I would still guess that most of the SQL Server databases out there are smaller than 100GB, maybe substantially smaller, and while we may consolidate and change hardware, we need these systems to perform well. The large, 100TB database changes are nice, and I know some customers need these improvements, but most of us don’t. Even though the percentage of people with 1TB systems grows regularly, it’s still a minority, so kudos to Microsoft for doing some work here.

    Not every highly rated Connect item is addressed. The string or binary data truncated message isn’t changed, and that’s been highly rated for years. However, the top JSON request made it into SQL Server 2016, and there are other items in the most voted on list that haven’t been addressed. I understand, though I don’t always like the way Microsoft looks at the product. I can relate their decisions to my own when building software, realizing that the customer doesn’t always have the best view of what makes sense for commercial viability. However, I’d also like to see the platform continue to evolve and make development and administration easier for all of us.

    I’ll keep voting on, and creating Connect requests as I see a need, and I’d encourage you to do the same. Think about what you are really asking for and decide if it makes sense for large numbers of people, but continue to participate and let Microsoft know what changes are needed. Your voice can make a difference, so please use it in a constructive and positive way.

    Steve Jones

     

  • Security and Patching Struggles

    A couple weeks ago we had a huge security issue with the WannaCry ransomware racing across the world. I was out of the office, and mostly offline, so I was a bit out of touch. However, many organizations were affected, and I’m sure many infrastructure people were scrambling to patch and protect vulnerable systems, possibly even restore affected systems. I certainly hope that most (or all) organizations didn’t pay any ransoms. For the future, my view is it’s better to lose a little data and restore systems than pay ransoms.
    I can remember when we got patches at random times, as vendors wanted to provide more functionality or finally had enough bugs fixed to release a patch. Sysadmins struggled to deploy these patches, being out of practice from the infrequency and struggling with non-standardized ways of applying updates. There was also the concern about the quality of patches, many of which introduced more bugs and issues. In the Windows world, I found many companies wanting to wait until an SP2 was released before applying, or even upgrading, many systems.
    That changed, with many companies moving to regular patches, and standard ways of applying, or even slipstreaming, patches easily onto machines. I welcomed the Microsoft Patch Tuesdays, as this provided a regular release, an expectation, and both admins and users became comfortable with the idea of regular patches. I haven’t loved the auto patches in Windows 10, but I find myself agreeing with Troy Hunt that we should just be patching. In an organization you may want someone to be responsible, but for home users, just patch.
    And, by the way, vendors, you need to do more work, and be more responsive to any issues that come up from patches. Your quality issues lead to greater security issues.
    If you want to ready about the WannaCry issue, there’s a good general post, as well as some guidance from the SQL Server perspective. If you haven’t patched, that’s something you should do ASAP, and while you’re at it, be sure you have the latest security patches for SQL Server applied. I’ve got a series of Build Lists at SQLServerCentral, one for each version. I’m still nervous about applying Cumulative Updates too quickly, but I certainly would download and have them ready, perhaps applying each a month late once once the early adopters have had a chance to report any major problems.
    Patching is a reality for the modern software world. We get regular patches for applications, but our core infrastructure (including servers, desktops, and various devices) also need patches to the OS and platforms. There’s a balance between ensuring stability with known softwre versions and keeping up with patches to prevent problems. We need to find a balance, which is probably different for each organization, and re-evaluate periodically if we are updating an an appropriate level. I lean towards fewer patches when I can, but I always want to keep up with security patches. We never know when someone will take advantage of those.
    Steve Jones