Hacker News new | ask | show | jobs
by mc32 2392 days ago
I'm not familiar with their environment but depending on the software and vendors who support aspects of software, those patches may be held at their request. That is people like Rockwell, Emmerson, whatever, may not “release” a patch because it can have implications for GxP environments. So not saying this is the case, but there are times when that is the case and companies have to sit on fixes.

However in these situations those systems are siloed and segregated do that things don’t propagate. I have no idea how Merck is setup.

3 comments

Unless you do development where a Windows patch could break a complex environment, most people in the workplace are always using all Microsoft products anyway so they should just be on auto-update. All it takes is for some IT manager to sit on a critical patch for too long. If auto-updates break your setup, then you could opt-out and be moved to a sandboxed environment where you still get patches but only after they are verified. I remember when some vcredist patch broke a very expensive development suite. Despite all the engineers affected complaining to IT, it took them weeks to roll it back for us. In the mean time, we had figured out ways to debug the tool with Visual Studio, catch the error, and continue past it without crashing everything. The patch must have broke quite a lot of things because there was another one that came shortly after that seemed to avoid the problems.
If you’re in a large organization you do not want an auto-update to mess up something for 10,000+ people who are unable to work because the VPN or whatever other enterprise system/software stopped working.

I’ve seen enough issues this year with Azure and multi-factor sso being down. It makes me weary of Microsoft’s updates. Lots of customers screaming because they can’t access our portals.

Sometimes your vendors have to wait for Microsoft to fix something they broke which complicates it even more.

In many cases unpatched systems automatically fail GxP by not being patched but pharmaceutical organisations still run operations like it's the 90s and they just don't acknowledge the problems. Have worked in pharma IT for 10 years.
I think the problem is that their vendors’ applications run like it's the ‘90s. Often the orgs will be waiting on a vendor’s patch to be released which has been qualified for the sec patch. This requirement is kind of dubious but if you patch before they release their patch you’re on your own.
You'd think so but most vendor security patches appear very quickly even for 90s style systems, the problem is almost always the customer's own processes. All vendors in the pharma business space maintain a dedicated support and patch team for all deployed and commercially supported products and or course charge customers for the privilege.
As far I understood, particular machines were under GxP requirements, but the vast majority were not. We scientists had local admin access to our laptops. To access some GxP software, we connected via a client that was like a remote desktop.