unixfool |
12-01-2009 11:07 PM |
In everything related to IT (and life), there's such a thing called mitigation. If you can't update (and the reasons may well vary), you evaluate the risk of updating (or not updating) based on the changes that need to be applied. You then make decisions based on the results of the evaluation. You can't always have it your way or the next individual's way. Each and every admin has to decide whether they can patch or not based on all the above, plus supervisor input and change management procedures. If you know that there's serious risk, argue to do the patching. If you can't perform the patching, mitigate the risk (harden against any discovered vulnerabilities. I really don't think (and this is my own professional opinion) you should blindly push every kernel major change/addition/removal without a proper evaluation of how it would affect a business (or a SOHO but critical system).
Do I have the very latest BIOS update for all of my systems? NO! I only update the BIOS if I need a particular feature/issue that the later version may address. Kernel updates aren't quite the same as MS Tuesay notifications. Most local kernel level exploits can be mitigated. You just need to be able to trust that your hardening is hard enough to keep unwanted people out of the systems.
I know of several critical Linux systems at my workplace that don't have the latest/greatest kernel. These systems are behind at least 5-6 hardware firewalls/IPSs, each system has its own software FW, ACLs are tighter than a python's knot, and they've been running for years. Is it right that they aren't semi-current? No, but again, the risks are mitigated. These boxes don't even go outbound to the internet...every connection is established via PTP VPN. When people know what they're doing, mitigation works.
It's a different approach but it works. Every system that I have control of, I try to make it as close to a bastion host as possible...that's the way it should be, IMO.
All of this is up for interpretation. There is no real standard and there shouldn't be. There is no right way (and there shouldn't be). If we become so rigid in addressing security, we only make it that much easier for crackers to do the things they do.
So, if your boss rejects updating a box's kernel, do you argue until you're fired? IMO, you do what you're hired to do, take direction from your boss (and cover your tracks), then let the boss take the fall if it comes to that. For SOHO environment where you're in charge, do it sensibly. If sensibly means postponing, then postpone (and mitigate the risk)! If one of your machines becomes compromised, learn from the experience, clean up the mess properly, then move on.
|