Automating Software Updates - the why
Automating Software updates is incredibly important, you may wonder why but the simplest way to express this is a figure from Gartner: the believe that 99% of security breaches are as a result of KNOWN vulnerabilities.
This in turn means that 99% of your risk is already established and can typically be mitigated through a workaround or permanently. Patching, sometimes referred to as Patch Management, is ultimately about maintaining what you already have and is a critical function of any IT department. Please test it first in a lab-environment.
All automation starts with pencil and paper, you must be certain to document what you currently do manually – or intend to – and identify the easy-wins on where you can automate. Not everything can be automated. Automation is powerful, but not a panacea.
End User Devices
End-User devices are typically the focus of most organisations when it comes to automating software. This is because your users will often have multiple devices used throughout the day and this increases your ‘attack surface’.
Being able to effectively manage end-user devices can greatly reduce the chances of your suffering an expensive and embarrassing cyber-attack.
For Mobile Devices an MDM is typically sufficient, this can be provided through specialised software designed for the platform you are using. Many firms settle for Microsoft’s InTune but often fail to realize that it has significant limitations, we prefer Flyve because it is GDPR compliant and very useful.
For laptops, desktops and virtual server sessions our choice platform is Ninja RMM but you can also use antivirus add-ons such as with Panda Security Endpoint Protection Plus, and Systems Management.
The above tools enable you to build workflows and standards which your IT estate can be compared against, if your staff use personal devices it is very important to ensure that you can control exactly what they can access with them – Opswat’s MetaAccess is the industry leader in this.
Network Infrastructure
Typically for smaller firms with perhaps only one or two offices an investment in automating network infrastructure patching has a much-reduces ROI. This is because your teams will likely use the Graphical interface in order to administer just one or two devices, and the exchange of saving an administrator’s time against an effective automation tool may not offer significant value.
With the above caveat, the ability to consistently and quickly automate patching enables you to patch often, early and successfully. The tool of choice for this across industry is the Red Hat Ansible Automation Platform, it depended upon by large organisations such as Cisco and Microsoft, as well as more technically-able SMEs.
If you do not have the ability to automate patching (for example you lack a lab environment to test patches against) automated alerting and vulnerability scanning is nonetheless worthwhile.
Cloud Workloads
It is often the case that datarooms are left ‘exposed’ to the internet, left alone after their initial use and eventually with degraded security updates because of a lack of maintenance.
Do not become the firm which has to explain to the ICO that you couldn’t be bothered to have an inexpensive patching tool to maintain a cloud-hosted server, which has been access by cyber-criminals. It isn’t a good look.
Aside from Red Hat Ansible Automation Platform which is noted above, it is worth evaluating the type of workloads you are running in a cloud and then translating that into a documented patch process which is adhered to.
Automating software updates in the cloud can be more difficult, you will likely have a sprawling system with multiple dashboards layered upon each other even for just one server. This could be more pronounced if you are running Kubernetes-based workloads and you may have no control over the version of Kubernetes depending on your deployment.
To be general in our advice, whether you are running a Private cloud or a Public cloud you must first document your existing processes for software updates and build matrices which explore risks out of your control. You are renting that space, things can change at short notice if the vendor decides it is in their interests.
Once you have documented what the manual process is and evaluated if it efficient, you can explore the automation tools available for a part or whole of the process.
Firmware
Firmware patching is altogether more difficult, partially because firmware is the bridge between physical hardware and the software which runs off it. By way of this, when firmware patching goes wrong it can go seriously wrong.
We would refer you to this excellent NCSC article on the problems with patching. Patching firmware takes deliberation.
End user devices can often be patched remotely, but you may wish to be mindful of VIPs and the integrity of their systems.
Most network infrastructure patching is already sensitive enough, and if you lack a resilient setup problems can quickly balloon. Start with risk, and dedicated sufficient resources (in-person if possible) just in case issues arise.
