Mike Boylan writes in a reply to my previous post:
…I have to respectfully disagree that disabling the auto-update mechanism for Xprotect should be done in organizations with managed machines. Do you disable the automatic update mechanism for your anti-virus software? Do you manually test every definition update and push each one out through Munki? I’d assume not. Xprotect (clearly) isn’t serving the same type of updates as Apple software update. It’s a malware prevention/blocking (and in some cases, removal) system. I won’t argue that Xprotect’s disabling of Java plugins will almost certainly have a larger impact across organizations than say something like a Sophos definition update, but nonetheless, the intent is still to protect systems. Xprotect and anti-virus software together are meant to serve complimentary roles. These Java plugins are being disabled because serious known exploits are being used in the wild. For a company that cannot function without version xyx of the Java plugin, does it make sense to make changes so that it can continue to operate effectively? Sure. But I doubt most organizations rely that heavily on a single plugin. Also, how many different types of updaters should we as admins be responsible for managing? There are already too many. For most admins, I don’t think it’d be a responsible decision to add Xprotect to the list.
Mike:
If Xprotect’s disabling of web plugins has not caused your organization any issues, or you are willing to react to any issues such disabling might occur in the future, it may well make sense to leave things as they are for your organization.
In my organization, the Java 6 web plugin is required to perform vital, daily business functions. When it doesn’t work, business functions are seriously impacted.
My argument might be subtle.
Apple is acting as systems administrator for machines by updating the XProtect plists. As long as you are content to let Apple make those changes, and won’t complain if Apple makes a change that breaks things for you, by all means, leave the XProtect updater mechanism alone.
If, on the other hand, _you_ are taking responsibility for managing your machines, making sure they are functional for your organization, and keeping them safe from malware, you’ll want to disable _Apple’s_ update of the XProtect malware definitions, and take over updating them yourself.
If you do not want to be surprised that one morning Java or Flash or some other plugin has been disabled on all the Macs you manage, you cannot let Apple update these definitions without your review. You must take responsibility for reviewing and implementing Apple’s changes, or a modification thereof.
Is this more work? Yes. Does it add risk to your organization? Probably. All security is a trade-off between functionality and protection. Malware protection that prevents my users from doing their work is not an acceptable trade-off. Apple has made one decision about the trade-offs, one that protects a great number of Mac users while negatively affecting a very small number of them. That is not the correct decision for my organization.
The only way I can ensure the correct decisions are made for my organization is to not leave the decision making process solely to Apple, but to instead review Apple’s changes and alter them if needed for the benefit of my organization.
Each organization needs to weigh this decision for themselves.
Managing OS X 
“Each organization needs to weigh this decision for themselves.” — That is really the point I was trying to make. Thanks for driving it home. But I was also eluding to the fact that in most cases, I think it will ultimately make more sense to leave it alone. Personally, if there’s a zero-day exploit that hits and I’m vacationing in Canada, I’d prefer our machines be protected. Does that mean I’ll occasionally field some e-mails and calls that Flash got disabled or the Java plugin stopped working? Probably. But we try to promote a culture of security in my organization, and fortunately we have no business critical apps that our Mac users need that rely heavily on the Java plugin.
You didn’t address my antivirus point. If maintaining a consistent working state is so critically important to you, how can you be certain that your antivirus vendor won’t release a definition update that will break something? I just think that sometimes we as admins try to manage too many things in an effort to maintain a consistent working desktop experience for our users. You have the resources and experience to make the decisions that are right for your environment. If managing Xprotect makes sense for you and WDAS, then by all means, manage it. But personally, Xprotect won’t be something I choose to manage.
“You didn’t address my antivirus point. If maintaining a consistent working state is so critically important to you, how can you be certain that your antivirus vendor won’t release a definition update that will break something?”
I can’t. But so far, that has never happened.
We’re comparing apples and oranges here anyway.
XProtect has in the past and probably will in the future disable normally-installed software. I am not aware of any other anti-malware or anti-virus software that does this. If another mechanism starts doing this, we might need to manage that as well.
“XProtect has in the past and probably will in the future disable normally-installed software. I am not aware of any other anti-malware or anti-virus software that does this. If another mechanism starts doing this, we might need to manage that as well.” — Fair enough. I don’t think we have any disagreement here. We’re just choosing to approach this differently.
I agree with Greg, here (I know…surprise!). With Xprotect in place, Apple essentially has a backdoor to pull changes to all of your (otherwise managed) machines. If you don’t want to manage or vet the xprotect.plist file, at least watch it for changes so you can understand what has happened if something suddenly stops working.
This I do plan on doing. Thanks, Ed.
Just as an interesting data point, I met someone at MacTech this year who works for a large well-known firm. His Mac client base is currently climbing from 10,000 to a global network of 80,000 machines, and they rely on Java for roughly 800 internal webapps.
Something tells me their desktop support people were probably pretty busy last week, and that disabling the Xprotect updater is something they would consider more applicable in their environment than I would in mine that uses one or two webapps requiring Java.
I also agree with Greg – I’ve got 4000 Macs here, and a government mandated Java app that depends on Oracle forms, which apparently doesn’t work with Java 7. We have no choice in the matter, Java 6 has to be running for our users… Period. While I can understand Apple trying to protect its users, you can be certain that the past month there has been a lot of cursing aimed at Oracle, Java, our required app, and Apple.
The place for a Mac admin (and their organization) to start thinking about this is to answer a question: You, Mac admin, are at a large conference that runs for three days. On the first day, Apple releases an update that causes to stop working. Is your response:
– “Whew! We’re safe from that threat–thanks Apple!”
– “Crud! Better go fire up the VPN and fix that–darn you, Apple!”
The answer should lead in the right direction.
That should be “causes ‘dangerous software’ to stop working”. WordPress ate my angle-brackets.
I take Apple’s usefulness at face value just like I do MS’s. Both companies have had bad updates and both have had good ones though mileage varies per incident. It’s good to have interaction options but cutting one out of the picture is likely to cause the kind of back and forth Apple and Java had. I’m grateful to have seen the syntax of using plistbuddy which let me delicately manage a specific setting.
This is a complex situation. While _you_ are responsible for _your_ machines, if they get owned because of a security hole that would have been patched because if not for you delaying updates, that could very easily affect not only your fleet but any networks your machines touch. And more than likely your fleet touches quite a bit more than you think.
There’s no clear and obvious answer here, other than remembering that it’s not paranoia if they really _are_ out to get you.
Is it reasonable to think that Apple could implement a white list feature for XProtect?
So that everything originating from a defined domain (or domains) will ignore the XProtect restrictions.
Command line would of course be acceptable, but it could also manifest itself in the GUI in a similar way to the Firewall settings.
Global on/off would also be acceptable, but granularity could also be implemented to allow individual control over individual plugins that are defined in XProtect.
I am thinking along these lines, because I am betting that a lage number of organizations that *must * use Java, only need it to work for one or two sites (that is my case). Even the guy with “800 internal web apps” might be hosting them from only one or two domains.
I am not a programmer, so this might be crazy talk…
I think it’s reasonable to think they _could_.
I think it’s unlikely that they _will_.
While I certainly agree with both positions, I am currently facing this particular issue in our organization.
Our management has only recently begun to take the OS X platform serious enough to budget for a better management solution this year. Meaning, we have no JAMF to rely on… but instead are doing things the good ol’ fashioned way with Apple Remote Desktop.
What’s more, we use IT Controls and Change Management in our environment. So while the average consumer can just install the update when it becomes available, I have to schedule it and define a window (typically two weeks) that the updates can be deployed.
Typically, it means our users (some of them critical) are down for at least a week before the updates begin to trickle through.
For the time being, I’m contemplating getting our IT Security department to bless disabling this feature in the name of productivity, but will also need to explore managing changes to XProtect to possibly be rolled out during our 30-day patching windows.
It’s not an ideal solution, but it may be a necessary evil for our particular scenario at the present time.
What would be nice is if Apple could provide organizations with advanced notice when updates to Xprotect would occur, but that’s likely not going to happen.
Another compromise I would be willing to accept is for them to separate Xprotect.plist and Xprotect.meta.plist, allowing the end user to choose which would be updated automatically. Right now, it’s all or nothing.
This way, you can still update the malware definitions automatically, but take a more managed approach to whether or not Adobe Flash and Java are going to be disabled before you can push out the updates.