Cyber Hygiene Fundamentals: Operating System Patching
he foundation of the fundamentals of cyber hygiene is also the most straightforward, right? Patch your operating systems, turn on automatic updates, keep track of the next patch release cycle, check critical applications for compatibility issues, provide end-users with a predictable patch window…
However, the truth is that operating system updates can be a constant tug-of-war between supporting critical business operations and staying secure. Without the right tools to automate and manage cyber hygiene, you can easily spend days planning for a patch, only to find out that it brings down core infrastructure.
To manage this core fundamental of cyber hygiene, you need to understand the unique characteristics of your devices and know what to expect each time a patch goes live. With a plan in place, you can reduce the stress of OS updates and finally get some sleep.
Let’s break it down by operating system to help you get started.
Windows OS updates come straight from the source – Microsoft. This means that the patches you apply against your systems have a trusted, predictable source, even if timing and scope can be unpredictable. Patches are well tested, but have been known to break more custom or exotic deployments.
Much of what you can patch with Windows comes down to two variables: your exact operating system version and applications and how early your particular subscription is set to receive updates. If you carry Windows versions older than 10 though, be careful – extended support is limited, and likely to be costly for your organization.
Devices: Primarily laptops and desktops, as well as server and even container infrastructure. Windows truly does it all.
Update Frequency: Most patches are released the first week of the month, on the well-known Patch Tuesday. There are exceptions – larger version updates release once or twice per year, while major security patches or revisions can go live anytime. Beware: if you do not set the rules, vanilla Windows automatic update functionality will try to install updates as frequently as possible, even if the update is unapproved (*cough* Cortana).
Sources: Direct downloads from Microsoft, automatic updates or Windows Update Service, or your local Windows Server Update Services (WSUS) box.
End-User Awareness: Limited. Because Windows is so common, end-users may not be the savviest and are more likely to experience issues with patching, reboots, or actually updating their OS. For Windows, automation and clear patch windows are best because pushy Windows updates mean low adoption and slower reaction when a critical patch launches.
Likelihood to Fail: Either low or very high. For most users, a Windows patch just works. Some apps may fail to load or behave normally, or more reboots happen than expected. However, a small percentage of version and configuration pairs will always experience issues, including those that break apps or skew configurations. If you have custom, legacy, or far from vanilla images, testing patches in a safe environment is best practice.
End of Life: Microsoft plans to deprecate its operating systems every 5 years, although many enterprise users drag it out much longer. If you are still running Windows 7, Server 2008, or similarly aged operating system versions, you may already be beyond an end of life cycle and need to upgrade to stay secure. Chances are, you’re already exposed to several serious security issues.
Like Windows, MacOS updates come from one source: Apple. This offers the same benefits of trust and verification, but with a more tightly managed and isolated ecosystem. Less information about MacOS packages is available, leading to potential issues with testing and predictability.
Apple’s embrace of closed ecosystems means fewer versions of supported ecosystems and better management of critical updates. If your organization uses older Apple hardware, you may struggle to find updates or even know when your machines have hit the end of their supported life. Without tools like Automox, MacOS also tends to be harder to manage at scale, making it difficult to apply a single patch schedule or adoption rate across your organization.
Devices: Laptops and limited desktops.
Update Frequency: Predictable, but sometimes random. Major patches are bundled into minor version updates or major version releases, such as High Sierra and Mojave. Most are published in advance or as part of beta builds.
Sources: Just one – Apple. Apple famously guards its releases and tends to react quickly to bugs and security issues. Because MacOS is not very fragmented, the variety of patches available are limited. Apple ships many of its improvements as part of major versions.
End-User Awareness: Moderate. Mac users tend to know more about their device than the average Windows user. Smugness aside, the shift from Windows to Mac usually means that users have to gain more mastery over their machine. However, just because your end-users on Mac know more does not mean that they actually patch, or do it on schedule.
Likelihood to Fail: Low to medium. MacOS patches are well tested before launch, but unique situations can always arise. MacOS patches tend to be larger and more time consuming, and user error, lost power, or just poor luck can mean a failed patch and troubleshooting. Generally, MacOS patches are safe to deploy as soon as they are available.
End of Life: Apple does not publish an official end of life plan, but generally, tends to stop releasing patches for systems more than two major versions out of date. Mojave-era (10.14) security updates, for example, are not likely applied to versions as old as El Capitan (10.11)
With many different distributions, flavors, and use cases, Linux release schedules can vary, but the method for patching is well known for each given distribution. Versions vary from enterprise-class, professionally maintained distributions like RedHat to purely open-source, community managed distributions. Each comes with pros and cons that probably determined which distributions your organization uses.
Patching Linux depends heavily on your particular distributions. While certain components cross-cut every distribution, the frequency, delivery path, and even release notes are generally unpredictable.
Devices: Most frequently servers, containers, and other infrastructure. Linux desktops and laptops are less common, but are typically used in engineering and IT teams.
Update Frequency: Can be the wild west. With so many different Linux distributions, your specific version or publisher will be the best source of patch schedules. Major Linux components, like libc and the Linux kernel itself, impact all distributions and will offer predictable and well-documented patch and release schedules. Similarly, more enterprise-oriented solutions like RedHat require more regular patch schedules and documentation in advance. Updates to more exotic distributions tend to be far more unpredictable. With these distributions, even major security patches can be delayed.
Sources: Open and closed source providers. Core components like the Linux kernel come from well-tested, easily viewed public repositories. Specific distributions like RedHat add builds on these releases, with patches specific to their applications and functions. With many Linux distributions, particularly less known options, it is your job to review and trust the source.
End-User Awareness: High. Linux demands technical end-users, and, as a result, they tend to stay on top of updates and patches. When you can just run `yum update` and pull down patches already configured for your system, it makes life a lot easier.
Likelihood to Fail: Relatively low…enough. The more unique your environment, the higher the chances for failure. Vanilla builds should patch easily each time, as well as enterprise products.
End of Life: Consult your vendor – the more unique the Linux distribution, the more likely it is to stop issuing patches one day. Major distributions like RedHat and Ubuntu will clearly share end-of-life plans.
Tying it Together
Chances are, your organization uses a mix of two or more of these operating systems, and plenty of time is wasted creating custom rules and managing each system separately. To truly manage operating system patching at scale, and do so without the need to manage each OS separately, you need the right tools. Automox’s powerful operating system patching automates this fundamental part of cyber hygiene, with policies that work for any OS to regularly patch.
Facing growing threats and a rapidly expanding attack surface, understaffed and alert-fatigued organizations need more efficient ways to eliminate their exposure to vulnerabilities. Automox is a modern cyber hygiene platform that closes the aperture of attack by more than 80% with just half the effort of traditional solutions.
Cloud-native and globally available, Automox enforces OS & third-party patch management, security configurations, and custom scripting across Windows, Mac, and Linux from a single intuitive console. IT and SecOps can quickly gain control and share visibility of on-prem, remote and virtual endpoints without the need to deploy costly infrastructure.
Experience modern, cloud-native patch management today with a 15-day free trial of Automox and start recapturing more than half the time you're currently spending on managing your attack surface. Automox dramatically reduces corporate risk while raising operational efficiency to deliver best-in-class security outcomes, faster and with fewer resources.