Meeting Patching-Related Compliance Requirements with TuxCare


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 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. 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 – 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, 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, 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. 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, 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 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, 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 (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 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.



Don't forget to share

You may also like...

Leave a Reply

Your email address will not be published.