When it comes to Linux patching, you probably aren’t as safe as you think. In the past, Linux users felt a certain immunity when it came to vulnerabilities. According to Net Marketshare, 88% of computer users today still use Windows operating systems, compared to fewer than 3% who use a range of Linux flavors. This means that most attacks are still aimed at Windows. But hackers know there’s some tempting fruit dangling from that Linux bush if only they could get at it.
As a result, attacks on Linux systems are happening all the time, like 2017’s Dirty COW Linux kernel exploit, 2019’s Dirty Sock exploit on Ubuntu, and 2019’s Stack Clash exploit, which incidentally preyed on a decade-old vulnerability in a range of Unix OSes, including Linux, FreeBSD, and Solaris.
According to Threatpost, 2019’s wave of ruthless ransomware exploits also targeted Linux systems. Ransomware can be particularly nasty, with Forbes estimating recovery costs to companies averaging around $84,000. You don’t want to find yourself at the short end of that stick.
Linux Patching Is Better, but Not Perfect
Sure, in a few important ways, Linux patching is better and more intuitive than Windows patching. But it generally takes more knowledge and experience.
And if you’re looking for “one ring to rule them all,” Linux patching isn’t it. Some features that simplify patching, like hot patching, aren’t consistently available across Linux flavors. What works on Red Hat doesn’t necessarily work on Ubuntu, OEL, CentOS, Debian, or any other distro.
Today, it’s more important than ever to be familiar with exactly which varieties you’re working with and what their unique needs are. That can be tougher than most Linux admins will admit.
Are You Patching Right?
Most organizations handle their Linux patching in one of two ways.
First is patching at the package level. This is simple enough but offers little insight into what you’re doing. With package-level patching, you’re essentially applying changes in the dark, without much awareness of what they solve or what impact they could have.
The other popular option is patching by category (e.g., security, updates, bug fixes, enhancements). This seems logical, but as with package-level patching, you may get highly unpredictable results. And because you may not know which patches you’ve applied when, it’ll be brutally hard to troubleshoot, let alone roll back if you run into problems.
So what’s the right way? Patching at the advisory level, which offers a more holistic approach to vulnerability remediation:
- Each advisory provides a stable, logical bundle of several packages.
- Advisories include additional information, such as common vulnerabilities and exposures (CVE) addressed, risk scores, and other security measures.
- Advisories represent a proactive, intelligent approach to patching, as opposed to a reactive approach.
Advisory-level patching also offers more predictability. In category-based patching, for example, you never know exactly what’s being updated. New fixes are being added in all categories all the time and are never “closed.” So even if you implemented every single security-related patch on one machine yesterday, doing the same on another machine today could have a completely different result.
Given that the entire patch cycle can take up to three or four months, different machines will inevitably have different patch levels across the entire network. Here’s a snapshot of those patch levels:
The Trouble with Advisory-Level Patching
So why doesn’t every organization just patch at the advisory level? To be honest, advisories can be more complex to work with for the following reasons:
- There are too many of them. In the first four months of 2020, Red Hat Enterprise Linux (RHEL) alone released 21 critical-level advisories.
- They take extra resources and orchestration, along with time to plan and implement.
- They’re incompatible across Linux distros.
For all of these reasons, IT teams often prefer to work at the package level. Packages are guaranteed to address only the detected issue without any unwanted side effects. But given the massive downsides of patching at the package or category level, advisories are far better in the long run. And there are ways to simplify patching at the advisory level.
How JetPatch Simplifies Advisories
JetPatch is designed to simplify advisory-level patching. It takes care of most of the grunt work for you, so you can roll out patches in the most comprehensive way possible, without all the complexity.
Here’s how JetPatch makes advisories as simple as possible:
- Pulls the exact advisories you need, based on your systems and setup, saving your team the trouble of hunting down the right advisory for each system
- Aligns all patches across your organization, keeping systems as consistent as possible, regardless of platform
- Gives you the information you need to prioritize implementation, so you can get to the most urgent patches first
- Consolidates all resources you need in a single-window view so that you don’t waste time tracking them down
- Automates patch deployment based on company policies
JetPatch also helps you minimize downtime on your Linux systems by intelligently predicting the impact of any packages included in advisories. This lets you keep things running across all levels of your organization.
Linux patching Without the Hassle
Patching itself can be a huge hassle: hunting down patches for multiple OSes, determining prioritization and importance levels for each OS, plus testing and predictive analysis of updates before actual deployment.
If you’re a typical Linux administrator, you’re probably looking after an ongoing patch cycle for a whole range of apps, databases, backends, frontends, and server types. You don’t have time to babysit multiple Linux distros–locating patches, packages, errata, advisories–for a variety of platforms and from a whole range of sources (Red Hat, OpenVAS, GitHub, etc.)
With the JetPatch dashboard, you get a clear view of all of your systems, providing total insight across multiple and even legacy OSes. JetPatch helps you juggle complex environments with minimum staff and downtime.
The risks of not patching in the smartest way possible are real, no matter what system you’re running. And getting it done the right way–at the advisory level–is much easier than you think.
