Re: It would be nice if MS could settingle on a single subnet for updates
In line below
--
Mike Brannigan
"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in
message news
as0b3pgjqdp3cb1vrrr6mb405jq3nen3r@4ax.com...
> On Fri, 27 Jul 2007 15:13:52 +0100, "Mike Brannigan"
>>"Leythos" <void@nowhere.lan> wrote in message
>>> Mike.Brannigan@localhost says...
>
> This thread is about the collision between...
>
> No automatic code base changes allowed
>
> ...and...
>
> Vendors need to push "code of the day"
>
> Given the only reason we allow vendors to push "code of the day" is
> because their existing code fails too often for us to manage manually,
> one wonders if our trust in these vendors is well-placed.
>
> A big part of this is knowing that only the vendor is pushing the
> code, and that's hard to be sure of. If malware were to hijack a
> vendor's update pipe, it could blow black code into the core of
> systems, right pas all those system's defenses.
>
> With that in mind, I've switched from wishing MS would use open
> standards for patch transmission to being grateful for whatever they
> can do to harden the process. I'd still rather not have to leave
> myself open to injections of "code of the day", though.
>
>>NO never ever ever in a production corporate environment do you allow ANY
>>of
>>your workstations and servers to directly access anyone for patches
>>I have never allowed this or even seen it in real large or enterprise
>>customers. (the only place it may crop up is in mom and pop
>>10 PCs and a Server shops).
>
> And there's the problem. MS concentrates on scaling up to enterprise
> needs, where the enterprise should consolodate patches in one location
> and then drive these into systems under their own in-house control.
>
> So scaling up is well catered for.
>
> But what about scaling down?
>
That is where the free WSUS 3.0 product is targeted. One server to do all
the downloads and then you approve the ones you want to deploy and then your
client PCs just get them under their normal Windows Automatic Update process
(but this time they point to your WSUS server internally instead of going
external).
> Do "mom and pop" folks not deserve safety? How about single-PC users
> which have everything they own tied up in that one vulnerable box?
> What's best-practice for them - "trust me, I'm a software vendor"?
>
As above for anyone one with more then a couple of PCs.
Other wise you subscribe to the security update, are notified when they are
released, use the Download catalog to get the updates test them as you see
fit hem deploy them as you see fit using any production approach you want.
Sorry but this is not new and has been around for the last few years - patch
management for everyone from single user to mega corp. is well understood
out there in the field, which is why I was so surprised by the OPs post and
approach.
> How about scaling outwards?
>
WSUS scales outwards too - unless you mean something else.
If you mean for integration with other vendors - if they wish to create
catalog then SCCM 2007 can handle import of third party or in-house catalog
data to id out of patch machines and patch etc. I suggest you read up on the
SCCM 2007 product.
> When every single vendor wants to be able to push "updates" into your
> PC, even for things as trivial as prinyers and mouse drivers, how do
> you manage these?
Since MSFT is taking a huge number of these patches and updated drivers then
you can continue to handle these. as regards the rest if they start using
standard catalog methods as I mentioned above then integration becomes a no
brainer. Otherwise you again have to get informed of there new updates -
most publish some form of alert etc. then download, test and deploy using
whatever tools you like in your enterprise.
> How do you manage 50 different ad-hoc update
> delivery systems, some from vendors who are not much beyond "Mom and
> Pop" status themselves? Do we let Zango etc. "update" themselves?
>
> The bottom line: "Ship now, patch later" is an unworkable model.
>
There is almost no such thing as flawless software and particularly when
you are talking about tens of millions of lines of code in an OS.
Every major OS vendor on the planet regularly ships patches and updates for
their products.
>>As you said your only problem is with Microsoft then the solution I have
>>outlined above is the fix - only one server needs access through your
>>draconian firewall policies. And you get a real secure enterprise patch
>>management solution that significantly lowers the risk to your
>>environment.
>
> That's prolly the best solution, for those with the resources to
> manage it. It does create a lock-in advantage for MS, but at least it
> is one that is value-based (i.e. the positive value of a
> well-developed enterprise-ready management system).
>
> However, I have to wonder how effective in-house patch evaluation
> really is, especially if it is to keep up with tight time-to-exploit
> cycles.
Then that is their problem and they must address it in the manner best
suited to them either by increasing their resources assigned to it or taking
a firmer approach such as only taking absolutely critical patches etc.
I have worked with enterprise across this whole spectrum from full dedicated
patch management teams that perform full and complete regression testing for
all patches they need to roll out internally to extremely poor ad hoc
solutions and minimal testing,.
> It may be the closed-source equivalent of the open source
> boast that "our code is validated by a thousand reviewers"; looks good
> on paper, but is it really effective in practice?
>
>
>
>>--------------- ----- ---- --- -- - - -
> To one who has never seen a hammer,
> nothing looks like a nail
>>--------------- ----- ---- --- -- - - -