More thoughts on XProtect Updater
I’ve been thinking more about Apple’s Xprotect Updater mechanism in light of the recent updates that have disabled Java web plugins. See yesterday’s post, for example.
In many enterprise environments, admins choose to run their own Software Update server to provide Apple updates. This is done for several reasons. One is to save bandwidth — it’s more efficient for a single machine to download available Apple updates over your Internet connection, then have all the other machines get those updates over the local LAN.
But another reason is to be able to control which updates are offered to your managed computers. Apple may offer an update that causes issues in your organization. For example, we did not deploy the “Java for OS X 2012-006″ update in our environment because it disabled the Java 6 Web Plugin, which we needed.
Yesterday’s Xprotect update essentially did the same thing, this time over a wider range of machines. I quickly put together a workaround, but one of the things the workaround does is to turn off the automatic updates of the XProtect data.
After thinking more about the ramifications of this, I think that this is exactly what most enterprise sites should do. They should treat this update mechanism like all other update mechanisms. I think you should turn this off on most or all of your managed machines.
“But wait,” you are thinking. “Isn’t this risky? Apple is trying to protect users from malware.” If you only turned off the update mechanism on all your machines and did nothing else, you are adding risk. But what you should do is something similar to what an admin that vets Apple Software Updates (or third-party application updates) does before releasing them.
You should enable the update mechanism on an admin machine. When there are new XProtect.meta.plist and/or XProtect.plist files, you should test to see that they don’t cause any issues in your organization, modifying them if needed. You can then use your favorite software deployment system (I like Munki) to distribute these files to your managed machines.
In this way, your managed machines can still get the benefit of updates to Apple’s malware protection mechanism without risking that a component vital to your organization will be blocked without warning.Explore posts in the same categories: Commentary, Deployment, OS X, Security