Privia Security was chosen as one of Türkiye's fastest growing companies!
Privia Security was chosen as one of Türkiye's fastest growing companies!
As operating system vendors become aware of flaws, they refresh their code and send us users corrections known as updates. Regardless of which operating system you use, applying these patches on a routine basis has become essential. While some of these flaws are for bug fixes, others also give rise to security vulnerabilities.
In fact, every new vulnerability that emerges is like a door opening out from your operating system. Every open door then becomes an entry point for cyber attackers. No matter how many security measures you take, you must not forget that as long as these doors remain open, you are exposed to threats — and that you may actually face threats through these doors more than through the applications on your system.
Windows patches are probably the most well-known updates. However, in today’s world we can see that patching is required at almost every point, from Mac devices and IoT devices to smartphones. When a critical patch is released, you must update your system regardless of your system or manufacturer. Some organisations set policy requiring updates every quarter or monthly, while in some sectors we see that updates are carried out far too late.
Applying patches means that the operating system, database management systems, development tools, internet browsers and many other areas are protected. Ensuring that all patches are up to date is a very basic security principle. In the Microsoft corporate environment, this has been made straightforward.
When evaluating a system, patching should be one of our first tasks. Regardless of the operating system or application vendor, you should be able to go to the website and find information on how to download and install the latest patches. However, remember that everything needs to be patched — the operating system, applications, drivers, network hardware (switches, routers, etc.): literally every product or application must be patched.
After ensuring that all patches are up to date, the next step is to establish a system to keep them that way. A simple method is to initiate periodic patch reviews at a specific time, during which all machines are checked for patches — this is very, very important. Of course, you can also use automated solutions that will patch all systems in your organisation.
Manual patching is quite cumbersome and impractical for larger networks. However, you can find automated solutions that will patch all systems in your network. These solutions scan your systems at predetermined times and automatically apply the necessary patches to your system.
On systems running Microsoft Windows, you can set your system to patch automatically. In recent versions of Windows, this feature is turned on automatically by default.
This approach has some drawbacks: the first is that it only updates Windows, not the other applications on your machine. The second disadvantage is that if you do not test it before deploying it to the entire network, it may bring some problems with it. Its main advantages are that it is free and integrated with the Windows operating system. Of course, when updating your operating system, you can also optionally receive patches for driver updates or other office applications.
On the corporate side, Windows Server Update Services (WSUS), System Center Configuration Manager (SCCM) and other third-party applications are also used as systems that can keep endpoints up to date with the latest security fixes. These not only handle normal Windows system patches, but can also manage updates for commonly used software such as Java, Firefox and other applications currently in use.
Unlike Microsoft environments, Unix-based environments typically use a package management system to install most third-party applications.
Package management and update tools vary not only by the Unix variant you are running, but also by the distribution you use. For example, Debian Linux and SUSE Linux use two different package management systems, while FreeBSD uses an entirely different system.
Despite the differences, there are common themes surrounding package management systems. Typically there is a package repository that can be installed to the system via local tools on each host. The system administrator issues commands to the package management system to specify that they want to install, update or remove packages. Depending on the configuration, the package management system downloads, compiles or updates and installs a binary of the desired package and its dependencies (libraries and other applications required to run the desired application) onto the system.
When the repository of available packages is updated, newer versions of previously installed packages appear in the package database. These new version numbers can be compared with installed version numbers and a list of applications to upgrade to a new version can generally be determined automatically through a single command-line action.
This ease of upgrading using package management means that, unless there is a strong change control and enforcement system in place for installed applications, the package management system should be used to provide an easy and automated way to update all packages on UNIX application servers. This not only eliminates the need to manually track each application installed on application servers along with all its associated dependencies, but also means that it has been tested and approved to work on that distribution. Of course, individual problems between systems mean that you cannot be certain that everything will always run smoothly.
Most, if not all, UNIX systems have a distinction between the operating system and installed applications. For this reason, the method of keeping the operating system itself up to date will differ from other applications. The upgrade method varies from operating system to operating system, but upgrade methods fall into two main categories.
Commercial operating systems in particular support the binary update application method. In other words, they distribute pre-compiled binary executables and libraries copied to disk, replacing the previous versions. Binary updates cannot use special compiler options or make assumptions about dependencies, but generally require less work and are faster to install.
Many open-source operating systems are updated from source, meaning that a copy of the source code is compiled locally and the resulting binaries replace the previous versions on disk. Source-based updates take more time and are more complex, but can include OS-specific compiler optimisations and patches.
There is much debate about which system is better, and each has its pros and cons. However, since most of the arguments focus on non-security-related topics, you can continue down your path by sticking to your operating system’s default.
Updates to the operating system generally occur less frequently than third-party software updates. In addition, they tend to cause larger problems since they typically require a restart — because, unlike application updates that can be realised with an appropriate update restart, they contain an update to the kernel or other subsystems that are only loaded at startup. Core operating system updates are recommended, but security vulnerabilities generally require us to update both the operating systems and the applications simultaneously.
As with other patches, it is always advisable to have a rollback plan in place before any major update.
When virtualised infrastructure is in question, you can take a snapshot of the file system before the upgrade and then perform the update. This way, after a failed upgrade, you can easily roll back by reverting to the snapshot. With physical infrastructure, this can become a bigger problem. However, most operating systems have mechanisms to deal with this situation — usually by keeping a copy of the old binaries and replacing them if necessary.
You May Be Interested In These
