The following transcript of my conversation with Terry Cutler has been edited for clarity. To hear the whole discussion play the podcast.)
Howard: Let’s start with the decision by the Zero Day Initiative to pressure companies to issue better security updates. For those who don’t know, the ZDI is a program run by security company Trend Micro to buy vulnerabilities discovered by anyone in application code. The idea is better if a legitimate company buys the bugs than crooks. Trend Micro alerts companies that their software has a hole. The companies benefit by fixing the vulnerability and issuing a security patch. Trend Micro benefits by adding filters to its antivirus products that protect against the newly-discovered bugs. Trend Micro usually gives companies about 120 days to fix and quietly distribute a bug patch before it publicizes that there was a hole and that it’s been fixed. And that period also gives time to IT departments and end users to install the patch. Sounds great. However, Trend Micro is seeing a disturbing trend: An increasing number of vulnerabilities that researchers find are in previously-released software updates. In other words, because of sloppy work companies aren’t fixing everything in their fixes. So last week Trend Micro said the 120-day notice period is going to be shortened. Public notice is going to be released as soon as 30 days for critical bug reports that result from previously issued faulty or incomplete patches. If companies don’t want to be embarrassed they’d better do better work. Is this a valid tactic?
Terry Cutler: Let me give you my perspective from the days I used to work for a software vendor. Some of your listeners might know I used to work for Novell for ten years as a primary premium support engineer. Whenever we released software, a lot of times, it got rushed out to keep up with the competition. But when code is not being done properly it really upsets customers, and they start pissing on the vendor. Excuse my language. I’ll give an example.
Novell had what’s called a single user interface which means you couldn’t have multiple users logging into its console at the same time. But malicious hackers were able to find a way to bypass that functionality, which stunned the Novell developers. That was going to be revealed at a Black Hat conference, so we had about a day to try and reproduce this problem and find a fix or we’d look really bad. So they came out with a band-aid fix. But what could happen is that when patches get rushed out it breaks functionality at the customer site, and if you’re dealing with large environments it’s going to cause a lot of problems. For example, printer functions that were working before might not work anymore. Band-aid fixes could lead to a code rewrite, which means a large patch will be released at some point which could break other stuff. You never know what you never know what.
Howard: Trend Micro says that the problem is bad patches mean IT departments are losing their ability to accurately estimate the risk to their systems because IT and security teams have to choose a priority for installing patches. Bad patches also cost organizations money and resources as patches get re-released and re-applied.
Terry: I experienced that about five years ago with a Microsoft patch that was rushed out. One of the issues that really burned me was an intermittent problem where the Exchange Server would stop all email services at exactly every 12 hours. We could actually time it to the second it was going to happen. It took weeks of troubleshooting to fix. We had to bring in other tech support guys from other IT vendors to try and help us. Later on, we found out that it was a [bad] Microsoft patch. Microsoft released another patch days later which corrected the problem, but we had to go and find this issue for them.
