Menu
The process of patching is applying a set of changes to a computer program that is designed to update, fix, or improve it, including the fixing of specific security vulnerabilities and other bugs. Patches are also sometimes called bugfixes, hotfixes, or service packs.
“Out of date software” may seem like a concept that needs little explanation in that it means that software has not been patched or updated for some time. However, there are a few different ways that software can be out of date that are subtly different and have both different causes as well as different risks associated with them.
The first is that software can be an older version that was installed some time ago and has not been updated even though the software vendor or developer has produced an updated version that is available for install. The second case is where updates and patches for a given application are no longer available from the vendor or developer at all.
If applying updates has never been considered or taken on as a proactive and ongoing task, then software updates may simply never be applied. This can often be the case in smaller businesses especially, if there is no dedicated IT department or security team.
If automatic updates are not enabled on a system, then software update is reliant on being a manual process that must be remembered to be performed. This is extremely prone to failure as a setup, in that patching can become a task that is increasingly neglected as other, more short-term highly urgent tasks are placed upon a team.
Even when automatic updates are enabled, its possible that patch installs will simply not work. This can occur if there is not enough temporary space on the device to download new patches and updates, or if the online repository that the system connects to for updates becomes unreachable – if the destination becomes firewalled off from the host for example, or if the update service moves to a new URL and the device patch settings are not updated.
Sometimes software is installed manually and outside of a system’s normal application installation utility. An example of this might be in compiling software locally on a Linux or Unix host and directly installing it. It would not then be registered with the host’s patch management software, and hence would not appear as an outdated piece of software even if the host were under active patch management.
Although some systems such as desktop computers will often have an automatic update feature in which patches are installed on a regular basis automatically, this same system is typically not built into all server software or network devices due to the risk of a failed patch causing an outage. Consequently, these systems can go unpatched if teams consider it too risky to patch.
If an IT team has relatively little experience with a software system, especially one that is mission-critical to the business, then they may simply lack the confidence to apply patches to a system. This can often be the case with systems such as database systems especially, which can require highly specialised knowledge to maintain, something that a smaller team or a team primarily composed of new hires or more junior staff can often lack.
Software updates can often be provisional on a product remaining under an active annual licence or subscription. If this subscription expires without renewal, either because it is forgotten about or because it is not deemed to be worth the ongoing expense, then updates for a system may no longer be available to a given organisation.
Sometimes software is simply not maintained by a vendor or developer any longer, known as “abandonware.” This can be the case for some software developed by individual developers in particular, such as some open-source software. If the software is a “passion project” for the developer, but they move on to other tasks, then the software can sometimes not be maintained any longer.
Sometimes software is not managed at the level of a host’s patch management at all, but is managed at the application layer, either bundled with code or else called dynamically by the code at time of deployment. Since this code is not integrated with a host’s patch management system, it can be “invisible” and never updated after being initially introduced.
Sometimes a vendor will decide to discontinue a product version or product line completely, and cease to make updates available for it, under what is known as an End of life (EOL) or sunsetting programme.
An additional risk is that a vendor or developer of software may simply no longer exist, such as if the company has failed or gone into administration. This can be a particular issue if the application is provided as a binary only since there is no possibility of another developer (or the organisation itself) adopting and maintaining the code. Sometimes companies will agree to a system of code escrow with a vendor to mitigate this risk, where a copy of the (uncompiled) application code is placed in escrow with a third party and released to the organisation if something should happen to the vendor.
Sometimes a system is so old that there is simply no update method for it. Many large organisations such as banks and airlines as well as public institutions have been in the news for suffering from staggeringly old legacy systems such as mainframes. Depending on their age, these systems may simply have no built-in update mechanism whatsoever and rely on in-house code modifications in the rare instance they are updated at all.
Tales about in IT of servers that are found in cupboards or even bricked up behind walls, forgotten but still running many years on. Although these stories may be somewhat stretched or apocryphal, there are definitely certain systems that can be forgotten or left out of patch management systems and yet be silently operational still. This can especially be the case for systems running non-core or distributed services outside of the typical IT environment or server room, such as CCTV monitoring systems or warehouse/production equipment systems.
Over time, as a product is used, more security flaws are typically found in it. When these are reported to the developer of the software by their discoverer, the developer or vendor produces a patch, and the details of the vulnerability are generally disclosed under the “CVE” (Common Vulnerability Enumeration) system. The public disclosure of the vulnerability details is extremely useful to organisations in prioritizing patching However, it is also a risk for any organisation that does not apply patches in a timely manner, since it can act as a “recipe book” for attackers, stating which vulnerabilities a given system may be vulnerable to.
Newly discovered software vulnerabilities are known as “0 days” until a patch is developed to fix them. An attacker therefore has a window between the vulnerability discovery and the time that a patch is applied to a system during which they have the advantage. The longer this “attack window,” the greater the risk to the unpatched system. However, if patches are either never produced by the vendor (if they have gone out of business, for example) or are never applied to a specific system, then essentially the attacker has an infinite window of opportunity to conduct their attack.
Some patches are specifically introduced to fix known vulnerabilities in a product. However other patches are simply functional updates or new product versions. In addition to the risk of not applying security updates as outlined above, not applying other update types and maintaining software at its latest version can be equally risky. One reason for this is that over time the protocols and ciphers used within a product for encryption and other processes can become increasingly weak and obsolescent. In cryptography especially, the older a cipher is then the weaker it is due to the steadily increasing power of computers and their ability to “crack” older ciphers.
The longer that a system is left unpatched, then the harder it can be to ever be able to update it. It is possible to “box yourself in” to a situation in which updating the software at all simply becomes impossible or massively complex. This is because over time, incompatibilities may arise between code usage and product versions or other libraries. For example, code written in PHP3 simply would not be able to run on a newer version such as PHP8. If updates are not performed periodically, then organisations may find themselves forced into a corner where they are “stuck” on a given version. If security vulnerabilities are subsequently found in that software, or any dependent library or system, they may simply present an insurmountable task to apply since the baseline install in operation is so many versions back.
The use of one legacy system may restrict choices elsewhere when procuring or sourcing any new systems or components that are either built on top of, or need to interact with, the unmaintained system. This can mean that new implementations are compromised in terms of security and that an organisation is forced to select weaker and less secure solutions purely to satisfy integration requirements with the legacy system.
A robust patch management programme can be difficult to get off the ground, but measures such as automatic update systems and patch management tools can help reduce the burden on teams significantly. Getting visibility of the entire technical estate and building an asset register is also critical so that an organisation can gain visibility of which systems are under patch management and what their current state is, as well as which systems are yet to be brought under effective patch management.
Regardless of whether patch management is performed proactively across all systems or reactively in response to new threats and security advisories, then a vulnerability scan can be critical in highlighting areas of greatest risk, such as key systems that have high risk vulnerabilities on them that are unaddressed.
AppCheck can help you with providing assurance in your entire organisation’s security footprint, by detecting vulnerabilities and enabling organizations to remediate them before hackers are able to exploit them. AppCheck performs comprehensive checks for a massive range of web application and infrastructure vulnerabilities – including missing security patches, exposed network services and default or insecure authentication in place in infrastructure devices.
External vulnerability scanning secures the perimeter of your network from external threats, such as cyber criminals seeking to exploit or disrupt your internet facing infrastructure. Our state-of-the-art external vulnerability scanner can assist in strengthening and bolstering your external networks, which are most-prone to attack due to their ease of access.
The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA)
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please contact us: info@localhost
No software to download or install.
Contact us or call us 0113 887 8380
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network and cloud infrastructure. AppCheck are authorized by te Common Vulnerabilities and Exposures (CVE) Program aas a CVE Numbering Authority (CNA)
