Voice of the DBA

Tag: security

  • Spend More on Security

    In technology, quite a few companies are doing well. In fact, it’s a regular race among Apple and Microsoft to see who’s the world’s more valuable company. However, quite a few other companies in other industries are also doing very well. Many have reported strong earnings in the last couple years. Many of those same companies have had data breaches.

    I saw this tweet from Buck Woody, which says ” Another day, another breach. C’mon companies, get your act together. Spend a bit of that record profit on security. We’re tired of this.”

    I agree. As someone who’s stayed at an SPG hotel, I’d guess my data has been leaked. I’m also guessing that my credit card has been changed since then, since I think I end up changing them once a year because of some data breach. Still, I think that shouldn’t be a habit I have.

    Companies need to spend more than “a bit” on security. They need to better train their IT staff on secure coding and configuration as well as on tools to support those habits and processes. They also need to devote some time and money to fixing past security issues. No system should be immune from patching because of fears that an application stops working. Either internal developers need to test better, or vendor contracts need to specify that software purchased will support platform security patches, which often means the vendors need to ensure that service packs and patches don’t break their products.

    We need to demand more as consumers and technical people, including demanding more of ourselves. Building secure systems is hard. Writing secure code requires we change habits and sometimes do a bit more work. It’s something we all need to learn to do better.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Trust But Verify

    Npm is the default package manager for the Node.js runtime. Most of us have heard of of Javascript, which is used extensively in writing applications. When developers write code using this framework, they often include code from other packages and developers, just referring to the functions they need. This allows applications to build on the work of others, without having to re-implement functionality that is commonly used.

    Many languages have libraries that are available for use, but most require that a developer download them, include them in their software and then publish the resulting software. In many node.js applications, the developer does some of this, but when they publish the application, the users pull down the versions of the packages that they need at that time. This allows developers to avoid including a lot of code in their applications, reducing file sizes, bandwidth, etc.

    Recently an issue arose with a popular package that is included in many applications. I first noticed this on Twitter, then saw it called out in a Visual Studio User Group meeting and then even more online. A programmer made some helpful changes to the package and was given rights to make more by the maintainer. This user when altered the package to include some malware that would attempt to steal bitcoins from users that ran an application using the package.

    This is much different than how our T-SQL code is structured, with all the code contained inside the database. There are some exceptions, but for the most part we can look at all the code that will be executed as a part of our batch. That doesn’t mean that we aren’t responsible for reviewing and checking out code.

    This might not be easy in the Javascript world, but it should be easy(ier) for us. I know the warnings about testing code exist, but I’m always somewhat surprised when users ask questions on the SQLServerCentral forums, and then can’t understand why simple code (select count(total) from mytable) doesn’t work on their system because they don’t have a mytable. That causes me to think that too few people actually look at code before they run it. If they don’t check a 10-30 line set of code, do they ever check something as complex as Ola’s script? Likely not.

    Part of our duty as professionals is to be careful with code that we get from others, run it in a sandbox, test it, make sure this is code that will work well for us. Not many of us can download code from the web and have it run on our SQL Server without modification, but if we’re asking questions on a forum, we might just do that. If the problem is complex and the code is large, we might not pay enough attention. As SQL Server expands to get code in R, Python, Java, and more, we may need to be more diligent in scanning code to look for problems such as data leakage.

    Can you imagine getting some Python code from the web that should break strings apart into works and find out that somewhere in the complex class structures this code also sends a copy of your data to some malicious website? I can, and it’s why I’d be very careful vetting code on the data platform.

    Steve Jones

    The Voice of the DBA Podcast

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

  • SQL Census–From the Redgate Foundry

    The Foundry at Redgate Software is our version of Microsoft Research. Kind of. We tackle some projects that are interesting and might make good products at some point, but we’re looking at the in the investigative phase. You can read about the Foundry here.

    Some interesting work is taking place in the Foundry and there’s one project that I think is interesting and solves a problem that many of us have had, but I’m not sure how commercially viable this is in the real world.

    Maybe you can help us learn more.

    SQL Census

    SQL Census started as investigation into the area of security, something that is both very simple in SQL Server, but can also become a cumbersome, complex, nightmare.

    The work has progressed well, and there’s a product available. Sort of. It’s in the stage where we are trying to decide how to move forward with both future development and starting to sell this. For now, you can get a look at the tool and give us some feedback. We’re really looking for more information about

    • Do you need this for compliance purposes?
    • Will this help you better secure your environment
    • Does this meet permission management needs?
    • Something else?

    We’re like to get more users, especially those that have larger environments where there isn’t a single user or role that everyone has.

    If you’re interested, read a little about the product and give it a try.

  • The Worst Data Breech

    I noticed this week that Australia passed a law that requires companies to hand over user information, even if encrypted. Quite a few articles that point out this might require backdoors to be created in communication systems to comply with the law. Companies are required to provide plain text user communication if they can, or build tools to allow this if they do not have the capability. The proponents of the bill argue this is necessary for criminal prosecution.

    Perhaps they are right, but if this capability is required, this means that either companies will have backdoors built into their products that allow them to decrypt things you might have expected to remain encrypted. That’s disconcerting to me, not because Apple, Google, or someone else might read my communications, but because no company has really proven they can protect all the data they store.

    Can you imagine how many malicious actors might spent their efforts trying to find those backdoor encryption keys? What if there aren’t backdoor keys, but companies decide to build some sort of key logger into software that copies data before it’s encrypted. Can you imagine how problematic it might be to secure that data?

    I’m also concerned because this would mean that there could be a few keys that can be used to get access to encrypted data, something like “master keys” in door locks. In this case, the loss of a key might mean problems for huge numbers of people. The other option would be lots of backdoor keys, potentially a different one for each customer/device, in which case we have a large data set that I’m sure will get leaked. At that time, how likely will it be that we’ll be able to implement new keys for large numbers of people?

    I sympathize with law enforcement. In some ways, their jobs are much harder. In others, however, I think they have many more tools, and the need to weaken encryption doesn’t seem to be necessary. Many of us have a need to secure data, to protect it from unauthorized access. At a time when security is proving to be a challenge and record numbers of data breeches are occurring, do we really want tech companies to start building products with less security? I don’t.

    Steve Jones