Monday, 04 February 2019 12:07

When updates go wrong, horribly wrong Featured

Written by

Reading time is around minutes.

When you think about operating system updates you probably do not think about the security team. Sure, there are security patches and such, but those are on the operations team and not really pushed out by the security team. Well, that is when they are done properly by the OS vendor.

The challenge comes when parts of the core operating system are either not properly coded or, as in the case of Microsoft on more than one occasion, properly signed and packaged. In more than one instance over the last few years Microsoft has forgotten to sign a couple of critical dlls in the OS. One of these relates to the DNS subsystem and the other relates to the DCOM subsystem. Both (when not signed) appear to be members of various malware families and can be quarantined by multiple anti-malware applications. Now, here is the scary part; if either of these does get quarantined the OS can have a bit of an issue.

So how does this involve the security team? Well they have to be ready to safelist files, restore files from the quarantine folder or (in extreme cases) identify a version of the files that do not get flagged so that they can be restored to the affected systems. Events like this can become a massive fire-drill if there is no update testing or planning and a nightmare when it is a forced update that you have no chance to test. Having gone through this type of event more than once, I can personally say you do not want to have this happen.

Which brings me to the second part of how this impacts, and involves, the security team. Because this is such a known issue, it can (and has) delayed patches for vulnerabilities to prevent massive outages in the past when the operations team had more control over when updates happened. This means that the security teams have to be more observant in looking for those indications of compromise in the environment. Not having better quality controls around packaged updates leaves environments vulnerable. Windows 10 was supposed to correct that by forcing certain updates without much chance to stop them, this is great until you push out bad updates.

In short, the potential for bad updates creates an excuse to not update to newer operating systems where a bad update might be forced and to not push out all security updates when they should be. I mean as it is. Most corporations do not update just to avoid the downtime associated with them, now add in the potential for massive impact (nothing like all of your servers not booting) and it is a healthy recipe for leaving systems open. I have said it before, and I will probably say it until I die, the security ball is being dropped on the OS and application vendor side in a HUGE way. There is no reason that unsigned code should be used anymore, much less unsigned updates pushed out for critical part of an OS or application. These are mistakes that generate issues and keep things stagnant from a security perspective. It needs to change or we will continue to be an “when, not if” industry.

Read 5238 times

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.