Voice of the DBA

Author: way0utwest

  • Secret Software Security

    This might not be the best title, but I like the alliteration for a the problems we have when governments seek to prevent security researchers from releasing information about software vulnerabilities. This is nothing new, as vendors have tried to prevent this for years, arguing that criminals will exploit the information and target users before a patch can be built. The other side of the argument is that many software companies don’t bother building patches if the issues are kept secret.

    What might be different in this case is that we aren’t talking about database software, devices, or banking websites. Certainly those systems may need secure software, but here we have the US Department of Transportation arguing that security details about automobile software shouldn’t be released. There is some leeway in that potentially limiting details might satisfy the government, but apart from that, how do you feel?

    Many of us use vehicles every day. We might use private cars, but we might use public buses, trains, and airplanes, all of which are making more and more use of software over time. I don’t know, but I suspect, that much of this software is being developed with an eye towards ensuring it works as intended much more than with a view towards how malicious users might take advantage of vulnerabilities. Far too often it seems that we have new systems where control data is allowed to transit the same networks and computing structures as less secure data, with minimal security across the entire system.

    I certainly think that some researchers might not appreciate the dangers of random people experimenting with the issues they disclose, but I also truly believe that the pressures of getting software released overwhelm the concerns and dangers that exist overall. There are no shortage of people with time to spare, abundant computing resources, and substantial intelligence devoted to finding flaws in software. They work at “hacking” the system to change behaviors. While it’s a game to many, there are very real consequences to the world if strong security isn’t built into vehicle software.

    I don’t know that I expect much to change, but I suspect that we will see more and more issues over time, more lawsuits and more highly technical and forensic analysis performed when we a system is attacked. I can only hope that we actually disclose poor security practices so that vendors do learn that their embedded systems need better, and more secure, software engineering practices implemented.

    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.

  • Leave Developers Alone

    This editorial was originally published on July 25, 2011. It is being republished as Steve is at the PASS Summit.

    A computer deals with interrupts all the time. They are the mechanism by which it can simulate multi-tasking among many different programs in a modern operating system. However those interruptions have a price, and too many of them can affect performance. As hardware grows larger, we have other issues from interruptions that we try to mitigate with techniques like soft-NUMA affinity or multiple pipelines built into hardware. All of these are designed to prevent a computer from spending any significant time on non-productive tasks because of interruptions.

    In the real world, many of us deal with regular interruptions from work. They might be emails, instant messages, phone calls on a cell phone, or the old fashioned someone-stopping-by-your cube-to-chat. All of these things add up to less productivity, especially for developers. One study finds a 10 point IQ drop from regular email and phone interruptions. I don’t know about you, but I’m not sure I can afford a 10 pt drop in IQ when I’m working.

    Some companies are starting to realize that developer’s brains are a scarce resource, and interrupting them can dramatically impact productivity. I have found some places, like this one, that are setting aside quiet time for developers to work without being bothered. Similar to the technical debt that Steve McConnell has talked about, there seems to be an interruption tax that some development shops are loathe to pay.

    Even if you don’t gain any productivity, or have fewer bugs, or ship more often, I think that your developers will appreciate it. It could be an easy way to increase happiness, improve retention, and even sell your company as a good place to work. And it’s easy to implement: just leave people alone a few hours a day.

    Steve Jones

  • Masking Data

    This editorial was originally published on Mar 7, 2008. It is being re-run as Steve is out of town.

    I saw an interesting thread awhile back where one of our very talented community members was asking about how to go about altering data in an application for a demo. It’s a valid scenario and one that I’m sure many people have run into at some point in their career. You want to show data that’s somewhat real so that it showcases the application and what it can do, but you don’t want to show real names, amounts, or any identifying information.

    A bit of a quandary and it seems that many people solve it in one of three ways. They just use test data, which is a very small set of data and doesn’t show as well. Or they may alter everyone’s name to something like “Steve Jones”, all phone numbers to 555-555-5555, etc., which looks funny.

    Or you just show the production data and wink and say “I don’t usually do this, but since you’re such a valued client…”

    So for the Friday poll: Do You Alter Production Data When It’s Copied?

    Meaning when the data gets moved to a non-production system (demo, test, development, etc.), do you alter the data and obfuscate it to remove any identifying information. Make it “safe” data that can’t be used to somehow compromise your production system.

    It’s a good practice, and one that I used to follow at a couple companies. I didn’t have any tools, but I did write scripts, load a few base tables of names, and then run those scripts as part of the restore job. They would randomly reassign new names to people, companies, addresses, etc. We would also redo phone numbers in sequential orders (555-555-0001, 555-555-0002, etc), and even randomly add products to sales or amounts to financial figures. It wasn’t perfect, and if you worked on the production system a lot you could guess which people were which, but it worked well for testing and client demos.

    I actually ran into a product recently (Camouflage) that does this and it’s a great idea. It’s something that quite a few companies should be implementing to ensure that their non-production systems are that much more secure.

    Steve Jones

  • No Live Blogging

    The PASS Summit opens today with the first keynote. This is one of the few times that I’ve declined the blogging table at PASS. The table has grown, it’s become a bit loud at times, and the pressure to take notes and push them out distracts me from listening and thinking.

    As  a result, I’ll be in trying to think about what’s happening and what it might mean for our industry. Having given keynotes and developed them, I know it’s a marketing show, and a bit of entertainment. However it also can generate some excitement, and certainly the ideas shown can influence managers and executives, which can free up money for us to play with.

    I’m a bit excited to see what’s coming, and what Microsoft might announce. If you’re not at the Summit, jump on the PassTV channel and watch live.