Voice of the DBA

Author: way0utwest

  • Correct Old Mistakes

    I ran across this piece on the VTech hack that recently occurred. It’s almost a classic example of what not to do in data storage. You can read the piece, and also look at Troy Hunt’s analysis, but clearly we can see that poor encryption, unencrypted communications, plain text storage of passwords, and more. What’s especially disconcerting is that we have kids’ information disclosed, plenty of which could be problematic years down the road as these kids grow up.

    Apart from all of the technology issues, there are certainly responsibility issues. I expect that VTech will deny knowledge of issues, and certainly limit the amount of time they admit to knowing about the security issues. After all, they’re a corporation and if they can deny liability it could certainly limit the number of actions taken against them. However I’m hoping that the developers and operational people that manage this technology realize they made mistakes while building these systems.

    There’s a certain immaturity that’s prevalent in the analysis of this system. I’m guessing that developers were under pressure to get websites up and running, in concert with product launches, and that plenty of code was shared among their various sites and web domains. However I would hope that the current developers at VTech would have learned more about building robust applications, and would be looking to rewrite and rebuild their systems to be more secure with more current technologies. I hope that any of you running Flash based systems, or using MD5, or any other well known, poor security practices, would be pressing your management to correct those deficiencies and giving them more secure solutions. You might also give them a copy of the article linked above.

    Likely most companies out there, I’m guessing VTech’s management don’t want to spend money to rebuild systems that work, regardless of security flaws. Likely developers that have learned how to better code public facing sites don’t have the time to spend rewriting old code when they have new systems to develop. However I think that the old code that lives out there, that poorly built code that most of us have written in our past, would get updated over time, as part of the cost of doing business. This is especially true for anyone using encryption, where upgrades should be regular and mandated as Moore’s law and better mathematics consistently eliminate the security provided by older algorithms.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Getting all Yesterday’s Sales, or Finding Midnight Yesterday

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as#SQLNewBloggers.

    I see questions like this regularly. How do I get all the sales from yesterday? I tried using DATEADD(day, –1, getdate()), but I only get some of the sales.

    Many people working with T-SQL know this is an issue. They know that getdate() returns the date and time of this instant (roughly). At the time of this writing, that’s 3:11 pm.

    2015-11-25 15_11_29-Photos

    However if I want sales from yesterday, I really want all timestamps from midnight on. So I probably want code that looks like this:

    SELECT SUM(ordertotal)
 FROM sales
 WHERE SalesDate > '20151124 00:00:00'
 AND SalesDate < '20151125 00:00:00'

    How do I get the time to be midnight?

    The easy answer is one I’ve been using quite a bit lately to answer questions, and I’ve refreshed my knowledge of the datetime trick. I use a combination of DATEADD and DATEDIFF to get to a 0 based datetime.

    SELECT DateAdd(Day, Datediff(Day,0, GetDate()), 0)

    In this case, I’ll get midnight yesterday, or 2015-11-24 00:00:00. This is because I’m using 0 as my base date and looking for the days (in DATEDIFF) since that 0 based date. When I add those days with DATEADD to the same zero based date, I get the correct date, but with a 0 based time.

    This same technique works to find the first of this month.

    SELECT DateAdd(Month, Datediff(Month,0, GetDate()), 0)

    You can also use other datetime values to normalize those times.

    SQLNewBlogger

    This was a quick post. I had answered the question and spent less than ten minutes putting this together.

  • The Database is the Cornerstone

    I saw a case study video the other day from Redgate Software. It was a look at one of the upper management on Fitness First, a fitness/gym company that has facilities in dozens of countries. It’s a good, short summary of the benefits they’ve seen from implementing DLM and ALM, with the DevOps Guys.

    It’s worth a watch, and I especially like that this manager understands and gets that the database is the cornerstone of better software deployment. That’s his quote. Without being able to be flexible and agile with the database, it hampers your flexibility.

    Fitness First at SQL in the City

    I also appreciate that they do regression testing in an automated fashion. It helps them reduce the number of bugs and speeds their ability to deploy. They also have moved to curated sets of test data to allow them to test known cases and bugs they’ve seen.

    They also “run at speed”. They meet the business needs, they can work quicker to meet client demands. That’s important.

    Fitness First also did a presentation at SQL in the City. I sat in and was impressed, especially with some of the work from the DevOps Guys. It’s long, 40min, but interesting.

    Fitness First Case Study

    I wasn’t sure what to think when it started, but by the end, I think that this is a good view of how DevOps can help. It probably is more valuable to you if you have a backlog of work, but even if you want to develop and deploy at a pedestrian pace, having a DLM/ALM setup can build your confidence and reduce bugs.

    There are a few other short videos that showcase what some of our clients think of DLM and automated database deployment:

  • Hacking Data

    This editorial was originally published on Mar 23, 2011. It is being re-run as Steve is away on vacation.

    I saw a note recently that researchers had successfully hacked a car using only an MP3 file on a CD. They were able to lock the doors and kill the engine in a car. That doesn’t necessarily sound too scary until you consider that the ability to kill any percentage of car engines during rush hour traffic could have catastrophic results.

    How much of an issue is this? I don’t know, but as long as there is some interpreter that has to decode digital data and render it as audio, video, or even text, there is the chance that additional code could be added to hack the system and allow someone to take control. When I think about all the ways that we get digital data these days, it is truly a scary thought that we could have these security holes.

    Think about it, MP3s could be sourced at a retailer like Amazon. Adding code to a popular MP3 song could infect millions of people that burn the MP3 to a CD, or connect their iPod to the stereo. The advent of HD radio could invite hackers to target broadcast centers and alter those files. Navigation systems and traffic data streams could potentially be carrying digital viruses that infect our systems.

    However that same idea could be extended in other ways. The more knowledge someone has about your internal systems, and the more they are connected, the more likely that just the addition of data to streams could have unexpected events. Suppose someone understood the complex relationships between various ordering and supply chain systems. Is there a chance that they could send in a sequence of orders that would disrupt your systems? Could someone inject data that somehow starts a chain reaction of workflows across your enterprise?

    It seems unlikely to me, but then again, 5 years ago I would never have considered an MP3 file might allow someone to gain control of a modern car. Security is a tough business, and there will always be new, creative, unbelievably exploits that are discovered. The best defense I can think of is to share information and never assume your systems are invulnerable to a new attack.

    Steve Jones