[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <NMEAJDJMDLJLOIOCIKJJCEKHEMAA.exibar@thelair.com>
From: exibar at thelair.com (Exibar)
Subject: [inbox] Re: 3 new MS patches next week... but none fix
>I think it is a totally lame approach. The patch distribution problem
>has been pretty much solved by other vendors. We would all sleep better
>at night if M$ would just get a clue. Oh well.
>
>tim
It's not that Microsoft doesn't have a clue, they do. We are getting
regular patches for holes that are found are we not? If they didn't have a
clue, we would have yearly patches or none at all. Ok, there may be some
holes that aren't patched yet, but I'm sure they're working on them and
they're coming. Some patches just have to take precedence over others.
I've seen quite a few vulnerabilities come across this list in this past
week, not many have vendor fixes yet either. This is not a Microsoft
exclusive problem. We need a better way to patch systems, ALL systems.
I've said it once on another list, and I'll say it here, we need a sort
of "patching server" that is on an isolated subnet. When a machine first
connects to the network, it gets an IP address and is only allowed to talk
to the patching server(s). Once the patching servers (for ALL OS's mind
you) determine that the machine is up to date with it's patches, then and
only then is it allowed to connect to the production network.
Now this won't take care of 0-day exploits for 0-day vulns, but it would
have taken care of 95% of the scrambles that a lot of companies went through
last year.
Let me ask this question, if you were running a company with 30,000 LINUX
boxes. How would you patch all of them? Don't a lot of Linux patches
require a re-build of the kernel?
Exibar
Powered by blists - more mailing lists