Chad Waters via plug on 13 Jan 2022 12:33:28 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] TuxCare

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Thursday, January 13th, 2022 at 1:15 PM, jeffv via plug <> wrote:

> Meeting Patching-Related Compliance Requirements with TuxCare


> 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.

> [parts might be commercial]

Ehhh...I'd be weary about this. It's mostly saying your distribution isn't fast enough with security updates (most distros are rather responsive BTW), so trust us to add another layer of complexity and spin up all your kernels and libraries with our custom builds. I wouldn't want anyone running automatic live kernel updates on my production assets.

Where you get into trouble is having an application or device that you don't have full control of that suddenly has a vulnerable software component. We are talking about that network controller that manages all your switches, or that medical imaging server that shares studies with remote radiologists. Sure its running some linux under the hood, but the real lag is waiting for the vendor to package the fix or validate it that it doesn't break anything for you. Maybe you have shell access to it but it is ill-advised to go rogue. In these cases, compensating controls and work-arounds hopefully fill that gap. 


Attachment: publickey - - 0x93D3331B.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --