Managing Rapid Security Response on Apple Devices

The latest version of iOS/iPadOS 16.4.1 (a) and macOS 13.3.1 (a) marks a significant change in how Apple releases updates for the OS updates. It is the first time that Rapid Security Response (RSR) has been included in the OS for iPhones, iPads and macOS. These latest updates come with a new feature called Rapid Security Response. This mechanism enables faster delivery of security updates to devices, allowing more frequent and timely fixes to security vulnerabilities. RSRs are included in the ensuing minor updates (not upgrades), and on a Mac, updated content appears on the Preboot volume.

There was a lot of excitement surrounding the launch of the RSR from Apple after its initial announcement; however, the actual release was fraught with difficulties and unforeseen challenges, resulting in a tumultuous experience for all involved. Here are a few of them to list:

• A completely new naming convention for OS.
• Compliance policies in Microsoft Intune are not ready yet to adapt to the new naming convention.
• Issues with rules & policies configured in Microsoft Defender for Endpoint.
• Conditional Access Policies caused issues due to new iOS/iPadOS or macOS build numbers.

To begin with, it is essential to understand the new updates and how they can be managed on supervised devices. It is crucial to know the install behaviour and how to control it for the best results.

Overview:

Rapid Security Response, aka RSR, are released by Apple to deliver critical security updates between software upgrades — for example, improvements to the Safari web browser, the WebKit framework stack, or other critical system libraries. They may also be used to mitigate some security issues more quickly, such as issues that might have been exploited or reported to exist "in the wild."

New Rapid Security Responses are delivered only for the latest version of iOS, iPadOS and macOS — beginning with iOS 16.4.1, iPadOS 16.4.1, and macOS 13.3.1.

I have attempted to break down the information into separate points to fully understand the rapid security updates.

• Rapid Security Responses that are intended for the operating system require the device to restart.
• If enabled, these responses can happen automatically without requiring permission from the user. (If the response is not for OS)
• Once the device requests the Rapid Security Response update, it will be downloaded; it only gives users a 10-second window to click "Not Now".
• The update takes approximately 5-10 mins (depending on your internet connection) from start to restart finish.
• The update download is around 85MB, and the installation takes a bit longer, but the restart is relatively quick.
• On macOS, the updated operating system content may be made available to Safari and its associated processes with just a relaunch of those processes. However, a restart is required to make this content broadly available to the rest of the operating system.
• On iOS & iPad OS, it may need to restart enterprise applications if they were being used in the foreground. So it may lead to data loss if not handled properly.
• Users, by default, have the option to uninstall, i.e. remove the responses.
• Rapid Security Responses don’t adhere to the managed software update delay.
• If you have enforced a software deferral policy from Microsoft Intune, then the response is also effectively delayed because they apply only to the latest minor operating system version.

Now, let's review the process at the device level in more detail:

Manage Rapid Security Response with MDM

When managing supervised devices, you have multiple options to modify settings related to rapid security response. These options ensure that mobile devices are secure and protected from potential threats. Let's look at all the possible approaches to handling Rapid Security Response policies.

Apple provides the following restriction keys to be used on supervised iPhone and iPad devices for managing the responses:

• allowRapidSecurityResponseInstallation
• allowRapidSecurityResponseRemoval

1. The allowRapidSecurityResponseRemoval restriction key can block or allow a user to remove responses from the device.
2. Setting CriticalUpdateInstall to "true" enables rapid security response in macOS.
3. Device Info and AvailableOSUpdate queries can be used for reporting the status of Rapid Security Response to Microsoft Intune.
4. allowRapidSecurityResponseInstallation restriction key allows admins to disable Rapid Security Response, which is enabled by default.

Manage RSR using Settings Catalog

The settings catalog lists all the settings you can configure and all in one place. This feature simplifies how you create a policy and how you see all the available settings. Follow the below steps to configure the policy for responses:

• Sign in to the Microsoft Intune admin center.
• Navigate to Devices > iOS/iPadOS devices >Create Profile > Settings Catalog > Create.
• Enter a descriptive name for the profile and click Next.

• Search for "Rapid", and select both options under Restrictions.

• If you are not ready to install Rapid Security Response in your organization, then toggle the "Installation" option to "False". Then Rapid Security Response will be disabled for users. This means the RSR will not be visible on the end user's devices.

This is not recommeded, as it will leave the device vunerable to threats!

• To block users from removing the security response, toggle the "Removal" option to "False". When enforced, the users will not see any option to remove the installed update.

• Push the policy to your test devices first. Review the effects and, when ready, go for a production rollout.

Manage RSR using Custom Policy

Using Microsoft Intune, you can also add or create custom settings for your iOS/iPadOS devices using "custom profiles". There are two ways to get custom settings into Intune:

• Apple Configurator
• Apple Profile Manager

Here is the custom profile I am using with Microsoft Intune to manage Rapid Security Response:

<dict>
    <key>allowRapidSecurityResponseInstallation</key>
    <true />
    <key>allowRapidSecurityResponseRemoval</key>
    <false />
    <key>PayloadDisplayName</key>
    <string>iOS 16 Restrictions</string>
    <key>PayloadDescription</key>
    <string>Restrictions</string>
    <key>PayloadOrganization</key>
    <string>Intune-IRL</string>
    <key>PayloadType</key>
    <string>com.apple.applicationaccess</string>
    <key>PayloadUUID</key>
    <string>336123456-4E5D-BCE5</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
    <key>PayloadIdentifier</key>
    <string>com.apple.applicationaccess.336123456-E41D-4E5D-BCE5</string>
</dict>

• Create a custom profile in Intune and upload the .mobileconfig or .xml file created in the previous step.

• Push the policy to your test devices first. Review the effects and, when ready, go for a production rollout.

Looking Forward

Allowing major build upgrades on the managed device's without thorough testing and user approval can lead to many adverse outcomes, such as severe disruptions in business applications, unsatisfactory user experience, and significant financial loss.

Therefore, exercising utmost caution and diligence is imperative when upgrading operating systems. To avoid this, responses are tailored to the minor version of the OS and provided between major updates, ensuring a smooth and seamless experience for the user. However, it seems that the release of these Rapid Security Response updates was too early. MDM systems still need to tweak a few configurations in the back end before these responses can be rolled out at the enterprise level.  

Microsoft Intune Support team have also released an advisory regarding the same detailing the impact of these new updates.

At the time of writing this article and as per my testing, the following configurations are impacted:

• Admins can’t create new compliance policies to check for the new iOS update with an “(a)” added to the version string. Existing policy checks are unaffected.
• Admins can’t create a policy to block conditional launches based on OS version with the character “(a)” for Mobile Application Management (MAM), is unable to check for the new version and can't validate whether an application can launch or not.
• Enrollment restriction policies may not work as intended with non-numerical character versions for Apple products.
• Reports with build-specific values will report OS without the “(a)”.
• For Mobile Device Management (MDM), admins can use Intune update controls to set the required version to the latest to get the security update.

Thank you for being with me on this article for configuring the policies for the all-new Rapid Security Response updates. I hope it was helpful and that you will have better control on managing Apple Operating System Updates.