Third party developers blamed for Windows security woes
Users just don't apply security patches from non-MS applications...
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Failure to apply third-party patches rather than updates from Microsoft is "almost exclusively" responsible for the growing exposure of Windows machines to security threats, according to Secunia.
Stats from users of Secunia's patch management scanning tool report that, on average, less than 2 per cent of Microsoft programs are insecure on a user's Windows PC – while typically between 8 and 12 per cent of the third-party programs on the same box are insecure. A breakdown of all vulnerabilities affecting end-point PCs during 2010 records that 69 per cent stem from flaws in the third-party programs, 13 per cent originate in the Operating System, while a further 18 per cent stem from security bugs in Microsoft program.
Flaws in applications from the likes of Adobe, Apple and others, together with difficult-to-apply and often overlooked security update mechanisms have become the greatest single source of Windows security woes.
"The complexity of patching third-party programs has a measurable effect on the patch level found on typical end-point PCs – based on Secunia PSI measurements," Secunia concludes.
The latest version of Secunia's annual report also found that a patch was available at the time a vulnerability was disclosed in half the cases recorded in 2009 and 2010. Around 22 per cent of the total number of security bugs were patched at a later date while 28 per cent were never patched.
The number of vulnerabilities affecting a typical end-point PC increased by 71 cent between 2009 and 2010, Secunia reports, adding the choice of operating system has only a minor effect on the vulnerability state of Windows PCs. ®
COMMENTS
not surprising
Windows patching is reasonably unobtrusive and doesn't prevent you from working while it's going on. Lots of third-party patchers are run needlessly and/or demand that you don't use the software while the patch is downloading (not installing, that would be reasonable - downloading!).
Add to that the fact that some vendors (*cough*adobe*cough*apple*cough*) don't distinguish between security patches and bloated new versions that somehow manage to increase requirements by 50% while adding no new useful functionality at all and moving all the GUI elements around so that you no longer know how to use the software, and it's no wonder people don't bother patching.
I wondfer
How many people think that Windows Update does ALL the patching required and don't realise more effort is needed for non-MS stuff?
Whilst a certain amount of education would help in that respect, it's amazing that there still isn't a centralised place or mechanism for updating Windows.
Be careful what you wish for...
> it's amazing that there still isn't a centralised place or mechanism for updating Windows.
A central *place* would be a very bad thing - control over everyone's update status would pass through the hands of one small group of people. Ick.
But a standardised updating mechanism would be comparatively easy - you could pick something like apt or yum which, being Free Software, could be ported to Windows without even needing to ask the copyright owners[1]. You could sit that atop a package management database - like rpm or dpkg, which are also available to all comers (including Microsoft) without charge.
The advantage of this is that you can add and remove repositories at will - so if you've had enough of Adobe's updates, you can disable those without affecting the Microsoft ones. You have a standardised mechanism with decentralised data, and control in the hands of the user.
It would take a little while for every software distributor to get round to packaging his code in this way, but package management is *such* a boon, it would become popular in short order.
Will this ever happen? Of course not. But that's not for technological reasons :-(
Vic.
[1] The authors have already granted you all a licence to redistribute rpm[2], dpkg[3], apt[4] and yum[5], because they are all released under the GPL. You *can* take that code. You *can* bundle it with your proprietary code. You can modify it if it doesn't meet your requirements. All you need do is release any derivative work *** of that component *** under the same licence.
[2] http://www.rpm.org
[3] http://packages.debian.org/sid/dpkg
[4] http://packages.debian.org/sid/apt
[5] http://yum.baseurl.org/
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
