[LINK] McAfee update problem

[Steven Clark]

On 24/04/2010 9:38 AM, Jan Whitaker wrote:
> At 09:58 AM 24/04/2010, Stilgherrian wrote:
>> Where fingers should be pointed here are at organisations like the
>>  Commonwealth Bank, Coles and Virgin Mobile for having ben caught.
>>  Did they not test the patch before installing it across multiple
>> systems?
>>
>> As Ed Skoudis says in SANS NewsBites today:
>>
>> We've been warning people in enterprises for years that they _must_
>> test AV updates in their labs before pushing them to their
>> enterprise. Every year or two, one of the major AV vendors pushes a
>> disastrous update. Here is another reminder.
>
> What "labs"?

any organisation with a large number of desktops *must* have a separate
system upon which to test new software *and* hardware - for integration,
stability, and all the other issues one can *expect* to have when
introducing new things, or changing existing things, in a working system
(of any kind).

smaller orgs should *at least* have a machine or two that replicates
their install-base to try stuff out on first.

it is a very different thing to update software than to update the
'signature files' used by software (essentially updating the database) -
though these notionally 'trivial' updates also ought to be tested.

if something is 'mission critical', you really shouldn't mess with it
without careful planning and testing.

> I can understand that approach. However, isn't the point of automatic
>  updates using a product like McAfee (or any other) the idea that they
just "happen"?

why should an organisation allow *anything* to 'just happen' on or to
their system? how does one audit that?

automatic updating is not actually essential to the functioning of the
update process. it *does* reduce 'nagging' but it also drops the
user's/owner's awareness of changes being made to their system by a
third party. in any other context, this might be called hacking/cracking
and be considered a security risk. (oh, hang on ...)

question: why are software developers trusted more than end users? why
do organisations allow software developers to change *their* work
environment without consultation? if you don't know it's happening, how
do you know what's happening?

by this i mean, why is symantec, microsoft, mcafee trusted to tinker
with your computers when the people who are employed to use them to *do
stuff* for the organisation are very often not trusted to tinker with
them ...

microsoft and mcafee are allowed to experiment with your systems - and
it is experimentation since they don't, can't and won't test their
updates in your environment. there are so many ways that changes can
cause knock-on issues in complex systems. and yet, many organisations -
in part because they don't understand the risks, and in part because
it's just *easier* - allow/enable automatic updating.

> Since we don't know when an update is going to occur (generally
> speaking),

there is no good reason why this ought to be so - and very often it isn't.

software companies usually have a way of announcing updates - say by
email. even for 'trivial' updates, they can (and should) be able to
inform customers of what changes they want to make, and why, and how to
notify of issues (and provide multiple means to do so - posting on a
website is meaningless if your internet link has been brought down :p)

afaik you can still get a lovely technical email from microsoft prior to
any update - in the manner of a 'knowledge base' data page: setting out
the update kb reference, and the content of the kb notice - which
includes the urgency with which ms recommends applying the patch, and
what it is intended to address.

> how does an enterprise do this efficiently? Do they have one machine
> that is on automatic with the others set for 24 hour delay to
> download updates from a local server?

once upon a time, i was the sys admin for a moderate-sized chunk of an
organisations network (several servers and an array of associated
desktops). part of my job was to routinely (at least daily, usually
two-three times per day) check for available patches, apply them to the
test rig (three machines set aside for the purpose - one server, one pc,
one mac), and try them out - before either adding them to the overnight
patch roll-out, integrating them into a new disk image, or filing a
request for better info from the supplier.

if coles, westpac, woolworths, and the like *don't* have dedicated
integration testing units within their ict group ... they're bloody
idiots. for a few months i was the entire integration testing unit of sa
health commission ... a self-appointed role as i tried to rebuild
back-end databases in certain 'mission critical' systems. rebuilding the
databases was only possible once i could stop the system from corrupting
it in the first place. which required tracking down the causes of the
issues. (which was not easy when much of that system was out of bounds
to me - beyond the scope of my authority.)

i suspect even eds has/had something of the kind in place when it took over.

> And what if it's over a weekend?

what, ict staff get weekends off now? when did that happen :p

> I can see this being v-messy.

but which is the messier? flying blind and hoping all goes well, or
being in some kind of control - at least being *aware* of what's going on?

hackers and malware are not the only risks, and they're certainly not
the 'most dangerous' - just often the most 'visible'.

-- 
Steven R Clark