Third-party patch management software for Mac OS X is available (such as LANrev, Bigfix, and PatchLink), but only a few suites are designed for anything but Mac OS X -- which makes it hard to have a unified suite for Windows and Mac patch management.
The danger here is in allowing individual users to manage their patches, which could lead to systems -- especially laptops carried by mobile users -- being far out of patch compliance and, thus, vulnerable to long-fixed security holes.
Solutions: Install an intranet proxy for Apple's software updates.
Review Mac-oriented patch management; these suites also include options for distributing other software updates and corporate documents, as well as auditing settings and installed software. Check with your patch management vendors about plans to add Mac support if yours do not. Send reminders to Mac-using employees whenever critical patches appear to install the updates as soon as possible.
Schedule patch sessions for laptops that are primarily out of the office, as they are most vulnerable to proximity attacks via Wi-Fi or Bluetooth, as well as attacks from untrusted networks on which they are located.
Security flaw No. 2: Serious third-party security flaws are slow to be fixed
Most of Apple's most serious security updates, ones in which remote code execution or arbitrary code execution are possible, typically involve third-party software -- often open source or free software components. (Notable exceptions are Safari and QuickTime, Apple-developed products that have had dozens of serious flaws, none of which have so far turned into attacks prior to being patched.)
While the project running the software often patches such vulnerabilities in hours or days, Apple often lags in releasing such updates. For example, Apple included version 2.2.6 of the Apache Web server in Mac OS X 10.5 (Leopard) in October 2007. Apache was updated to 2.2.8 to fix several security flaws in January 2008, but Apple didn't ship an update until March 2008.
But other times, Apple is speedy. For example, an Apple researcher discovered a set of flaws in the Ruby language and environment, which were documented and patched June 20, 2008. In this case, Apple took only 10 days to release its security patch.
In both cases, it's critical to note that neither Apache nor Ruby is used by default in Mac OS X. Apache must be enabled either through the Sharing preference pane's Web Sharing service check box or at the command line. Ruby isn't used for any native Apple products, and it must be wired in at the command line or through third-party packages.
Locking down this sort of access would prevent the most likely security flaws from being exposed, but that's problematic with the current OS. Configuration management software does exist to help such a lockdown, but again, Mac support may not exist in the software you're running companywide.
That should change. "We are starting to see early signs that some vendors are supporting Mac as a platform for those configuration management systems," Mogull says.
Solution: Consider limited deployment of third-party software to restrict configuration by administrative users if your current solution doesn't include Mac support.
Security flaw No. 3: Everybody's an administrator (or not)
Apple has a binary attitude when it comes to modifying system settings, gaining access at the command line to its Unix underpinnings, and installing software: You're either an administrator -- or you're not.