2

I recently got into a discussion regarding automatic installation of security updates. The system is used and managed by a small nonprofit organization—essentially one or two admins managing the system in their free time. They typically touch the box only if there are feature updates to be done, or if something is not working (which they typically discover by people complaining about it, as there is no monitoring).

Since there is a high risk of admins neglecting security updates, I suggested automating security updates (specifically installing only security updates, not other updates). Now somebody else claimed that no serious admin would ever configure automatic installation of software updates.

The possible reasons against automation that I can think of do not seem major issues to me:

  • Spoofed update repository—updating manually makes this no less likely to happen, and with proper signature verification, this should be fairly hard to exploit.
  • Updates breaking the system—security updates should for the most part maintain interface compatibility and would thus be drop-in replacements, hence this risk is adequately mitigated by limiting automatic installation to security updates.
  • Data corruption because of updates on a running system: with proper packaging and installation routines, I would expect packages to take proper measures (e.g. shutting down a service before upgrading it and restarting it afterwards).
  • Downtime: can be controlled by scheduling automated upgrades to take place during a designated maintenance window; apart from that, I consider it less of an issue in this particular case as usage of the system is low.

What is the general recommendation regarding automatic installation of security updates (considering the scenario of a system that gets admin attention on a sporadic basis only)? What are the risks caused by automatic installation of security updates?

user149408
  • 347
  • 2
  • 9
  • Automatic updating is a backdoor in its own right. A rogue manufacturer (or one compelled by law enforcement) can intentionally ship malicious software. See the [FBI-Apple encryption dispute](https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_dispute) for an example. – Rainer P. Apr 07 '18 at 23:18
  • @RainerP. The rogue manufacturer is indeed an interesting consideration I had missed. However, the admin may not be aware that the manufacturer has started to roll out rogue updates (he may have missed it or the information may not even be public at all). Therefore, of all admins who rely on manual patch installation and periodically checking for new patches, there may still be plenty who end up installing the rogue patch. – user149408 Apr 08 '18 at 20:41

2 Answers2

4

If you look at CIS Controls (formerly known as TOP20 Critical Security Controls), and particularly the number #3, you will find: Deploy automated software update tools in order to ensure that the operating systems are running the most recent security updates provided by the software vendor.

So I would recommend it, especially in the case of "low admin attention".

You have well identified the risks, the biggest one being operational issues (update requiring a reboot, update stopping some services, etc.).

Regarding the risk of spoofed update repository, today most update systems rely on TLS authentication and/or package signature, limiting this risk. This risk is usually lower anyway than running a system with an unpatched critical vulnerability.

At the end of the day, you should also consider the risk exposure of the system (internet exposure, etc.) in your decision matrix.

fraga
  • 41
  • 3
  • I recently came across the German BSI’s IT-Grundschutz. They require automatic patch installation for workstations, unless other software distribution mechanisms are in place. I didn’t find a similar recommendation for servers, but since the general operations guidelines state that admins must always have up-to-date information on vulnerabilities and patches, the low admin attention I am assuming is already not up to standards. BTW, other requirements are verification of all patches and updates prior to installation, and ensuring such updates are only installed from trustworthy sources. – user149408 Sep 07 '18 at 21:21
3

Fraga gives a great answer. I'd just like to add a DevOps spin to it.

If you have serious concerns about updates causing failures in existing systems, you could mitigate that by running system updates through a CI pipeline.

This is made relatively trivial with the use of Docker. You'd "simply" trigger a new image to be built when a security update is detected for your base image or any of your dependencies, run the new image through automated tests, and automatically push that image to production.

There are ways to do similar things without going to containers, but Docker has the benefit of providing tools that make this relatively trivial compared to bare-metal deployments, or stateful VMs.

nbering
  • 3,988
  • 1
  • 21
  • 22