This Monday saw Apple release its next OS upgrade, macOS 13 Ventura. Apple took the unusual step of pre-announcing the release date last week, perhaps in recognition of the calamities caused with Catalina a couple of years ago. Then, as now, SentinelOne was ready with a supported agent (more details below) to ensure all enterprises can upgrade while remaining protected against the latest macOS malware threats.
For organizations, upgrading a major OS can be a fretful experience. In our previous post on Ventura, we covered seven new security changes coming in macOS 13. In this post, we’ll discuss some of the wider impacts of upgrading to macOS 13 on users, admins and security teams.
Arguably the most significant change for existing macOS users is the number of models that macOS 13 doesn’t support, and for enterprises looking to upgrade to the latest and most secure version of macOS that could mean an upgrade of their Apple hardware.
Ventura requires a Mac that was manufactured no later than 2017. For MacBook Airs and Mac Minis the minimum is a 2018 model, and the 2019 model or later is required for the Mac Pro.
Users with hardware older than that are out of luck, although for personal devices projects like OpenCore Legacy Patcher can revitalize aging hardware. Security implications (not to mention licensing) rule that out in organizational settings.
Like most recent Apple OS iterations, Ventura brings with it a new set of user ‘consent and control’ alerts. With macOS 13, this is primarily centered around USB and Thunderbolt peripherals that users plug into their Macs. These new controls, which ask users to approve or reject a new device via a dialog alert box, are intended to help protect users against malicious wired accessories, or what Apple calls “close-access attacks”.
Organizations using MDM solutions can choose to bypass user authorization via the allowUSBRestrictedMode
restriction key, and other MDM options are available to control which devices a managed Mac can pair with.
There are, however, a number of caveats to bear in mind. The Accessory alert is triggered by the cable that is plugged in to the port, but after approval, users can change what device sits on the other end of a cable without causing a further prompt. In the case where the user has a USB hub or dock attached to the computer, plugging a thumb drive into an approved hub will not trigger an alert. The other major caveat to bear in mind is the more general one with TCC (aka UAC) alerts: if the user unknowingly plugs in a malicous flash drive, they are almost certainly going to approve the device if an alert pops up, since this was their intent when plugging it in.
Accessory security represents another barrier for threat actors to surmount, but it’s no replacement for proper and fine-grained device control managed by the security team.
Ventura’s headline UI feature is Stage Manager, a “new” way to control and switch application focus. We put “new” in quote marks as it turns out the concept was actually prototyped back in 2007.
That’s a lot of baking time! While at first glance Stage Manager might seem like a merely cosmetic addition (remember LaunchPad, anyone?), it does add some practical advantages to application management. Chief among these is the ability to organize windows into groups to create restorable ‘workspaces’, a feature that’s long been missing on macOS.
Stage Manager allows users to group windows together by dropping them onto an existing window in the strip to the left (or right, if you have your Dock on the left). Clicking on a Window group switches these to centre stage, in the orientation and size that you previously had them.
What’s even nicer is that each Desktop ‘space’ has its own strip, creating lots of possibilities, particularly when combined with multiple displays.
There’s a couple of things missing with Stage Manager that would be nice to see for extra productivity: at present, adding a window to the strip is driven by drag and drop; some keyboard shortcuts would be nice. The ability to name groups would also help.
By default, Stage Manager is “off”, so turning it on requires a trip to the new System Settings.app (more on that below).
The short answer is: in the search bar! As we noted in our preview of the Ventura beta, System Preferences has now become System Settings. Discovering where things are can be challenging compared to the System Peferences.app, and the search field is now all but mandatory.
Perhaps the first and most obvious difference for security teams and admins is to update any scripts with the new name, as obviously they will fail on Ventura if they target “System Preferences”.
The settings themselves have some novelties and quirks. Persistence items are now visible and controllable to users via the General > Login Items menu item. Here, users can find a list of items that are set to run when the Mac is booted and when the user logs in to an account. Since the initial beta, this functionality has changed somewhat, and in the release version of Ventura only items that are labelled as ‘from an unidentified developer’ can be revealed in the Finder, via clicking the adjacent “i” button.
This is unfortunate, on two counts. First, since users cannot easily trace the parent application for items from identified developers, there is the risk that users will disable some essential services simply because they don’t recognize the name of the item displayed in System Settings. This is particularly problematic because the name displayed is the name of the developer rather than the name of the application.
In the image above, there are Login Items belonging to BBEdit, Carbon Copy Cloner and Pacifist, but unless users are familiar with the developers’ names, their parent applications are difficult for users to identify from System Settings. Will this cause some users to toggle off services they might need? We wouldn’t bet against it, and it’s something front-line IT support teams will need to keep in mind.
Also somewhat unfortunate is that Apple’s own login items show up as “Item from unidentified developer”. Admins can expect to see plenty of users asking about these and similar items here, too.
SentinelOne, like most other security vendors on macOS, takes advantage of Apple’s ES framework to provide part of our advanced security solution, and as such requires Full Disk Access. Unfortunately, granting FDA seems to allow various other permissions on Ventura that are not required or requested and not seen in Monterey.
For example, the Developer Tools pane in Privacy and Security shows that any application using the ES Framework has permission to “run software locally that does not meet the system’s security policy”.
This wording is unfortunate and may be disconcerting to some users, but in fact it is not a material change in the SentinelOne agent. We presume this is a macOS bug and have reported it to Apple as such.
A headline feature for iOS and macOS over the summer was the announcement of Lockdown mode, an option that users can enable in System Settings and which restricts the device’s ability to communicate with various services. Apple says that Lockdown mode helps protect devices against extremely rare and highly sophisticated cyber attacks.
According to Apple, when Lockdown Mode is enabled:
Other impacts of Lockdown mode can be found in Apple’s support documentation here.
Importantly, admins and security teams should note that Lockdown cannot be prevented by MDM. Although there is some warning that Lockdown mode is enabled in Safari’s toolbar, it is not generally obvious otherwise, and users that enable Lockdown may even forget that they have done so, which raises the risk of confusing support calls about malfunctioning or unavailable services. We predict that “Is Lockdown mode enabled?” is going to be one of the first questions support teams are going to want to ask users submitting tickets about various non-functioning services.
Another Ventura feature touted at WWDC last summer was something Apple have called ‘Rapid Security Response’. In essence, this is “a mechanism for shipping security fixes to users more frequently”, though details are still scarce.
So far, Apple has only given broad details, such as that Rapid Security Responses apply only to the latest minor operating system version. To receive these, users need to ensure that “Install Security Responses & System Files” in the Advanced option of Software Update in System Settings > General is checked.
Organizations using MDM can set CriticalUpdateInstall
to achieve the same effect so long as the device is on the latest minor version. MDM solutions can report on Rapid Security Responses with the Device Info
and the AvailableOSUpdate
queries.
At present, Apple hasn’t rolled out a Rapid Security Response and we will need to await seeing it in action in order to evaluate the impacts in practice.
SentinelOne did extensive testing of Ventura during the beta phase, and we are delighted to announce that Ventura is supported on both Intel Macs and Apple silicon Macs with agent releases 22.2.3 and later. The SentineOne agent runs natively on both Apple platforms.
Admins should ensure that the SentinelOne agent is updated to support Ventura before running the Ventura upgrade. More information can be found in the Ventura Support article in the Support portal.
Ventura seemed to have a much smoother beta cycle than some other recent versions of macOS, and overall our first impression of the first public release is that it is relatively stable. There are, of course, some chinks to iron out and we do expect to see users needing support from their IT teams as they experiment with some of the new options in System Settings.
Upgrading to a new OS is never a light undertaking, particularly in an organizational setting, and with Apple pushing software updates and upgrades more aggressively, we hope this post will help admins and security teams get up to speed with some of Ventura’s idiosyncracies. For more information on security changes in Ventura, also see our post here.
The Complete Guide to Understanding Apple Mac Security for Enterprise
Learn more about the challenges and threats facing security and IT teams running macOS devices in the enterprise.