Meeting Patching-Related Compliance Requirements with TuxCare

Cybersecurity teams have many demands competing for limited
resources. Restricted budgets are a problem, and restricted staff
resources are also a bottleneck. There is also the need to maintain
business continuity at all times. It’s a frustrating mix of
challenges – with resources behind tasks such as patching rarely
sufficient to meet security prerogatives or compliance
deadlines.

The multitude of different security-related standards have ever
stringent deadlines, and it is often the case that business needs
don’t necessarily align with those requirements. At the core of
what TuxCare does is automated live patching – a way to
consistently keep critical services safe from security threats,
without the need to expend significant resources in doing so, or
the need to live with business disruption.

In this article, we’ll outline how TuxCare^[1] helps organizations such
as yours deal better with security challenges including patching,
and the support of end-of-life operating systems.

The patching conundrum

Enterprise Linux users know that they need to patch – patching
is highly effective in closing security loopholes, while it’s also
a common compliance requirement. Yet in practice, patching doesn’t
occur as frequently, or as tightly as it should. Limited resources
are a constraint, but patching has business implications too which
can lead to patching delays.

Take patching the kernel of a Linux OS, for example. Typically,
that involves restarting the OS, which means the services running
on the OS go offline, with predictable business disruption. No
matter what you’re trying to patch, the problem remains – it’s
impossible to take databases, virtualized workloads, and so forth
offline without anyone noticing. The alternatives are complex
workarounds or delaying patching.

Risks of not patching in time

But as we all know, delaying patching carries significant risks,
of which there are two big ones. First, there are compliance
requirements that state a maximum window between patch release and
applying that patch.

Organizations that struggle to overcome the business disruption
of patching risk delaying patching to the extent that they run
workloads in breach of compliance regulations such as the recent CISA mandate^[2]. That means a risk of
fines or even loss of business.

However, even fully compliant workloads leave a window of
exposure – the time between the moment criminal actors develop the
ability to exploit a vulnerability and the moment it gets
patched.

It leaves an opportunity for intruders to enter your systems and
cause damage. Delayed patching leaves an extended window, but even
patching within compliance regulations can still lead to a very
long risk window. It is generally accepted that, today, 30 days is
the common denominator of the most common cybersecurity standards
for the “accepted” delay between vulnerability disclosure and
patching, but that is still a very large risk window – you’ll meet
the compliance requirements, but are your systems really safe? Only
if organizations patch as soon as a patch is released is this
window truly minimized.

While it’s impossible to completely avoid a window where
vulnerabilities are exploitable – after all, the recent Log4j vulnerability was actively
being exploited at least a week before it was disclosed^[3] – it’s still nonetheless
imperative to minimize this window.

Bridging the patching gap with TuxCare

TuxCare identified an urgent need to remove the business
disruption element of patching. Our live kernel patching solution^[4], first rolled out under
the brand KernelCare, enables companies such as yours to patch even
the most critical workloads without disruption.

Instead of the patch, reboot, and hope that everything works
routine, organizations that use the KernelCare service can rest
assured that patching happens automatically and almost as soon as a
patch is released.

KernelCare addresses both compliance concerns and threat windows
by providing live patching for the Linux Kernel within hours of a
fix being available, thus reducing the exposure window and meeting
or exceeding requirements in compliance standards.

Timeframes around patching have consistently been shrinking in
the past couple of decades, from many months to just 30 days to
combat fast-moving threats – KernelCare narrows the timeframe to
what’s about as minimal a window as you could get.

KernelCare achieves this without disrupting regular operation of
servers and services. End users will never realize the patch has
been deployed. One moment a server is vulnerable, and the next it
simply isn’t vulnerable anymore.

What about patching libraries?

We’ve got you covered there too, thanks to LibrayCare^[5], TuxCare’s solution for
critical system libraries, which covers patching of other critical
components like glibc and OpenSSL. Those are fundamental components
of any Linux system that are heavily used by third-party developers
for providing functionality such as IO or encryption.

Libraries are a high profile target for malicious actors looking
to get a foothold in a system. OpenSSL alone is associated with a
list of hundreds of known
vulnerabilities^[6]. The unfortunate side
effect of being used by other applications is that any patching
applied to a library will incur business-disrupting downtime, just
like kernel patching.

Again, that is the factor that contributes the most to patch
deployment delays – the inability to deploy patches without
affecting the regular flow of business activities on affected
systems. For libraries, it also requires planning, approval, and
implementation of maintenance windows, an anachronism in a modern
IT environment. Thanks to live patching, LibraryCare can
effectively patch libraries without requiring even a single service
restart on other applications.

Ensuring database security in running, live database
services

Databases store the most valuable assets in a company’s arsenal,
its data. Keeping it safe is paramount for business continuity and
effectiveness, and this is covered by multiple standards like GDPR,
the CCPA and other industry-specific standards in, say, healthcare
and finance, that translate data breaches into heavy,
business-threatening fines. For example, Amazon reported the largest GDPR fine to date^[7], with a staggering USD
887m in value.

However, data has to be reachable at all times under penalty of,
again, causing business disruption if patching is attempted. For
this reason, the TuxCare team extended live patching technology to
also cover database systems^[8]
like MariaDB, MySQL or PostgreSQL, the most commonly used
open-source database systems today.

Now, you can keep your database backend secure from known
vulnerabilities, with the timely deployment of patches that no
longer need to be scheduled weeks or months in advance. It helps
meet data security requirements transparently and with no friction
with other users and systems.

Virtualization is covered too

Another TuxCare product, QEMUcare^[9], takes away the
complexity of patching virtualization hosts that rely on QEMU.
Prior to live patching, getting QEMU up to date was a task that
used to imply extensive migration of virtual machines around nodes,
a complex and error-prone task that would impact performance and
usability of those virtual machines.

Patching used to impact the end-user experience of virtual
tenants significantly. QEMUcare solves this by live patching QEMU
while the virtual machines are happily running on the system.

Traditionally, virtual infrastructure was planned in such a way
that additional capacity was available to cover for some nodes
going down for maintenance, thus wasting resources that would be
just sitting there most of the time twiddling its proverbial IT
thumbs.

If you don’t need to take your hosts down or migrate virtual
machines around anymore, you don’t need to acquire extra hardware
to accommodate those operations, saving on equipment, electricity,
cooling, and vendor support bills. Your systems are patched within
a very short period after patches are available and your
infrastructure is more secure.

Legacy systems are not left behind

Companies commonly have legacy systems that for one reason or
another have not or cannot be migrated to more recent operating
systems. These older systems will go out of support eventually,
thus crossing the commonly referred to “end-of-life” (EOL)
date.

At this point in time, the vendor behind those systems will no
longer support them or provide patches for emerging threats. That
means that organizations running those systems automatically fail
compliance standards because, of course, you can’t patch if you
don’t have patches available to you.

Developing patches in-house is a steep hill to climb. The amount
of effort that goes into the development, testing, deployment, and
maintenance of patches quickly gets overwhelming in anything other
than the simplest situations. Even then, you won’t have the comfort
of having a dedicated team of developers with the experience and
expertise to help you if anything goes wrong.

TuxCare has that experience, and our Extended Lifecycle Support^[10] (ELS) service is the
result. It has, for years, helped users of EOL Linux distributions
such as CentOS 6, Oracle 6, and Ubuntu LTS. TuxCare backports
relevant fixes to the most used system utilities and libraries.

TuxCare provides ongoing cover for
patching

We are continuously adding EOL systems as these reach end of
life, with CentOS 8^[11] the latest addition to
the supported distribution list, given that CentOS 8 reached EOL on
January 1st, 2022.

With our established live patching service now also joined by
patching across libraries, virtualization and more, TuxCare
provides a truly comprehensive patching service that fills the
major security gaps that so many organizations battle with.

Thanks to live patching you can now rest assured that your
critical systems are protected against newly discovered exploits as
fast as possible, and with minimal disruption. That powerful
combination gives TuxCare live patching the power to be a key
weapon in your cybersecurity arsenal.