Not

if there were proper authentication and control in software updates then all these zero-day, shoot from the hip updates would not be needed

it's the zero day threats that creates the pressure updates and pressure leads to errors

I feel like you have run off onto an unrelated tangent with this topic, this problem would have happened no matter what kind of trust module or digital certification was present.

McAfee put out a bad update that caused problems.

McAfee wrote the original program, McAfee wrote update, McAfee compiled the update, McAfee distributed the update.

No matter what you do in terms of trust, certificates, or other validation used, this bad update would have happened for the end user.

If you want to talk about Quality Control, then that is a whole other issue, but security really isn't the concern with the problem brought up by this article and this type of situation. This was a huge QC/QA screw up, not a security screw up.

DHC:="Will/Can technology ever be secure right out of the box?"

i refer you back to the tech article that you brought to my attention earlier

There was this:

While it was an early design goal of Windows Vista to use elevations with the secure desktop, Windows Integrity Mechanism, and UIPI to create an impermeable barrier—called a security boundary—between software running with standard user rights and administrative rights, two reasons prevented that goal from being achieved, and it was subsequently dropped: usability and application compatibility.

Remember the x86 since 80386 provides kernel(RING0) and user(RING3) mode* enabling the O/S to monitor what the user is doing -- and to refuse any untoward requests

All that's left is to install the needed authentication requirement and we can snuff the hackers like a clay pidgeon

~~

*these act like two separate computers talking to each other... the user asks* for varous things while kernel gets it done.  Certain things require Special Permission obviously and this is when UAC will ask the operator for permission... but this is where the authentication is needed. The Devil hath power to assume a pleasing form... but he cannot fool a digital signature -- where the Trust Model is properly used.

* has to: the user computer is only a simulator; it cannot do I/O or allocate memory; it has to ask the kernel for these things. this is in the hardware and is the difference between the RING0 computer and a RING3 computer.

~~

when influential people in business and industry realize that the argument that security is too complex  to attain or too restrictive to be acceptable is entirely specious they will then insist on corrective service. If this is not promptly forthcomming steve and some of his buddies from msft will find themselves on the plane to washington. the issue affects not only business and industry, but our national security as well.

and there is not that much left to do.

we do not need to put the A/V people out of business in this either: we need them all to get busy with our softrware inventory audit and control programs so we can verify our results.

Rswinney,

If you mean the CUSTOMER is responsible for testing the updates/patches, I’d disagree somewhat with your assessment here:  “It sounds to me the McAfee's latest patches is a result of some IT staff not doing what they were supposed to do which is test the patches before a live installation.”

To me, actually, the main burden of testing falls onto the vendor McAfee. Yes, the customer COULD do additional testing in their environments, but most technical people know how that goes in companies these days (testing usually doesn’t occur, happens rarely or is incomprehensive). The software vendor is offering a product for a fee; if that product doesn’t work, the brunt of the issue falls to the vendor and as proof of that, McAfee backpedaled here offering free support and subscriptions to customers. Though this was a small issue, less than 0.5% of customers were effected, it still highlights the state of software (especially Security Software) in the Internet age – LOUSY.

The REAL answer as Bruce Schneier alludes to is to make computers, OS's networks and applications not only user friendly but also secure right out of the box; “If we want home users to be secure, we need to design computers and networks that are secure out of the box, without any work by the end users. There simply isn't any other way.” 

Mike, I agree with your points on the validation.  Those were the points that I agreed with rswinney.

It is also true that the open systems have redefined computing by the "user" markets which have confused the issue.  That is where there should be no distinction in verifiable products and solutions.    We have ended up "nuancing" technology.  The standards should be consistent.  The applications and commercial product solutions can vary by the end user and markets.

DHagar

Good points, rswinney.  I fully agree!

DHagar

RS: ="There are two types of computing users:"

the "type" of user has NOTHING to do with this

the issue is: updates must be authenticated or trashed

preferably trashed

the whole concept of "open" systems has made a mess out of computing generally

There are two types of computing users: individual and enterprise. For individuals, the push and pull methods are best because the typical individual just wants to use the computer for daily activities and does not desire understanding the underlinings of software maintenance. When discussing businesses like Shavlik and Kaseya, it is actually the business of enterprise IT staff to test patches and upgrades via sandboxes.

It sounds to me the McAfee's latest patches is a result of some IT staff not doing what they were supposed to do which is test the patches before a live installation. (Just like some programming students not testing their programs before submission.)

DC: "the point I was trying to make was that even WITH that OEM approved signature, couldn't a bad (buggy) update still get through"

yes. an example of this is the malware that was distributed pre-loaded on OEM drives recently manufactured off-shore and imported with malware pre-installed...

and this gets into DH question: "When it is being sold, it seems there should be a way to confirm that the deliverable is meeting the standards it is selling."

She's right except she needs to go 1 step farther: we need to apply Quality Control on everything that is received and before it is incorporated into any larger assembly

the software on those defective disks should have provided also the signature of the programmer and the auditor who certified that product.

the need for responsibility is not unique to the computer industry: I bought a brand new car for my wife. with less than 3,000 miles she complained it would not start.

engine replacement

whoever supplied the rod cap bolts did not supply grade 8s. and so the rod cap bolts broke

quality ain't free.

it's just cheaper than fixing things later

the point is: in software components -- as in other things -- OEM must take pride in their work, sign it, and take responsibility for quality. but remember this: quality is not something you get: it's something you do.  we must all learn to apply a QC check on the parts -- software -- we receive before we incorporate them.

but here I'm talking the finer points.

before we go there we need to plug up the big holes

to get started we need everyone to understand what a digital signature is, how it fits into a Trust Model and how to properly manage a Trust Model

start by getting your own copy of PGP

I agree with you, Mike.  It affirms David's point about leaving the trust up to the software patches.  I like your idea of responsibility for the software product, which Verisign cannot provide.  When it is being sold, it seems there should be a way to confirm that the deliverable is meeting the standards it is selling.

I like the pull approach where there are options for the customer to select from verifiable software companies and/or patches.  Of course David actually points out the best solution, which was when IT "managed" the systems. 

DHagar