Wiping the flaws: Why it's time to get smarter about patch management
Wiping the flaws: Why it's time to get smarter about patch management
The humdrum world of vulnerability disclosure got off to a spectacular start this year after Google and Microsoft locked horns from the first days of January. The stage seemed set for a major showdown: the web giant and its Project Zero team of impatient young security researchers versus the lumbering mass of ‘old IT' – Microsoft. It was almost a shame when the whole thing petered out after Google offered made some concessions.

Yet the questions it raised over vulnerability disclosure have yet to be answered. And more importantly, what about the poor sysadmins so often caught up in the middle? How can they keep their heads when all about them are losing theirs?

To disclose or not to disclose?

I'm torn between whether what Google did in the end was right or not. On the one hand I'm glad it saw sense and moderated its inflexible 90-day disclosure policy. Publicly revealing the Windows 8 flaw just two days before it was due to be fixed in a scheduled update did no-one any favours. Adding an extra fortnight grace period for vendors who can prove they've a patch on the way was sensible and fair.

At Trend Micro we have a 90-day disclosure policy but, as happened with several Android flaws we notified Google about privately last year, if the vendor needs more time, we'll work with them to disclose only when they're ready. It's all about being flexible and collaborative – after all, with a mutual enemy as determined and agile as ours it's the only way we're going to keep our customers safe.

Yet on the other hand part of me believes public disclosure of the most dangerous vulnerabilities is necessary as soon as possible. If Google found a major flaw in a vendor's software and informed only that vendor, the chances are it would not be the only party aware of the issue. From financially motivated cyber-gangs to taxpayer funded government spooks – there are plenty of well-resourced, technically able third parties capable of exploiting such flaws for an advantage before a patch is available.

Who's the loser in this instance? The consumers and organisations that use the affected software. 

If sysadmins know about a flaw as soon as possible they can follow best practice risk management steps. The longer that disclosure window lasts, the more chance potentially the bad guys have to exploit it.

Diversity is good

But should we feel sorry for the vendors who seem to be drowning under the weight of vulnerability disclosures? Microsoft released just 28 critical bulletins last year, a big drop off from the 42 of 2013, but is cramming far more CVEs in per bulletin these days. No, I don't think we should go easy on the multi-billion dollar software industry. They need to learn the value of proper QA and if public disclosure of flaws helps focus minds on the task then so be it. In fact, Microsoft is one of the better performers when it comes to coding – hitting around 20 errors per 1,000 lines of code, as opposed to an average of 15 to 50.

The bigger picture IT managers should understand is that monolithic operating systems will always attract more attention. It's simple economics. A malware researcher looking for vulnerabilities to exploit will focus on the most popular platforms – the ones which will help generate the maximum RoI.  Invest in Linux systems and your risk exposure will be far smaller. Even the infamous Shellshock bug turned out to have less impact on end users than at first thought because of the multiplicity of Linux systems. You could even go one further with a custom built system.

Reducing risk

Unfortunately manageability and ease of use will always trump security, so monolithic systems like Microsoft will remain favoured by most. But if your CIO has made that choice, there are still some important steps you can take to reduce risk. File integrity monitoring, vulnerability shielding and whitelisting can all help to protect systems from buggy software and even broken patches. These systems may require some time and effort configuring up front, but they'll give you back even more time. Time to run your QA processes to ensure the patches you apply aren't going to break mission-critical systems, for example.

The truth is that, given the choice, no-one will ever prioritise cleaner, safer code. They'd rather have it now, even if it is flawed. So it's time we used the tools and techniques at our disposal to be a little more intelligent about how we manage vulnerabilities. If the past couple of months have taught us anything, they're certainly not going away anytime soon.

Contributed by Raimund Genes, CTO, Trend Micro