An Enterprise Security Roadmap for macOS

By Jesse Endahl

I recently spoke with the folks at the Mac Admins Podcast about the content of this post. You can listen to my episode here and get the full context (with lots of links and documentation) below.

Why should you (and Apple) care about enterprise?

Before getting into enterprise security, let’s first talk about why you (and Apple) should care about the enterprise. There are after all, many more consumers than businesses. The short answer is that consumers rely on businesses, and the employees of those businesses rely on Apple’s management of macOS as a platform.

However, Apple has historically been a consumer company first, an education company second, and an enterprise company third. The result of this prioritization is that while Apple hasn’t intentionally ignored enterprise needs, they also haven’t been top-of-mind.

Consumers rely on services provided by the world’s top technology companies, creating a vast trove of highly sensitive information that is very interesting to nation state attackers, and the majority of employees at some of those companies use macOS. So if Apple helps these (and other) companies protect their user data, it can protect even more individual consumers and amplify its impact.

Here’s a table illustrating the types of user data at stake. You can probably figure out what the companies in each category are.

Category Data being protected
Ride sharing Where you are, where you’ve been, and when you went there
Payment processing What you’ve bought
Modern hospitality Where you’re currently staying or have stayed in the past, and when
File sync & storage Sensitive photos, tax documents, other personal information or intellectual property
Social networking Your entire social graph—who you know and how you know them

Hopefully by now, you’re convinced that enterprise security is worth paying attention to. At the end of the day, a compromise of enterprise data often means a compromise of consumer data, so protecting enterprise devices actually protects everyone.

Defense in Depth

Now let’s take a moment to discuss the concept of “Defense in Depth” before diving into the details of macOS security. Apple took the time to explain this concept in the WWDC talk “Advances in macOS Security,” so we’ll start with a quote from that talk below.

“With a product as complex and with as many use cases as macOS, there is no single technology or feature that can deliver perfect security alone. So instead, macOS is designed with many different layers of security, each designed with a specific purpose or goal. And every year, we improve the technologies and policies at each of these layers to help keep you safe.”
“And this is an application of the principle of Defense in Depth. And the goal is to ensure that one layer of security failing doesn’t defeat the entire security model of the system. Instead, we rely on multiple layers of protection with different properties. Some layers are designed to delay the advance of an attacker, others to reduce the attack surface of a component, and some to create choke points to make it easier to defend a specific asset.”

I love this quote is because it highlights the relationship between the theoretical concept of “Defense in Depth” and the various “layers” that make up a platform security model, and maps them together directly. It will become apparent why this is important a little further on in this post, so just keep this in mind for now.

In recent years, Apple has been making great improvements to its macOS security model, adding defenses at new layers of the system and staying true to its “Defense in Depth” security strategy. The trend has also mostly consisted of bringing iOS security improvements to macOS. Though some in IT are concerned this means a sacrifice in control, the trend is net positive because iPhone and iOS form one of the most secure general computing platforms in the world. At this year’s WWDC, Apple made a welcome announcement that continued this trend:

In a future version of macOS, unsigned code will not run by default.

They were also quick to mention that there will always be a way to run whatever code you want—it just won’t be enabled by default. The default will be the most “secure” mode. This is in line with Apple’s (and Fleetsmith’s) belief that computing should be “secure by design,” and follows the trend we’ve seen with System Integrity Protection and Secure Boot. Both are enabled by default, but can be disabled or moved to a lower security mode via a reboot to Recovery Mode.

But it isn’t always possible to ensure all these protections are enabled.

Attack-driven defense and attack paths

Back in 2013, I saw Zane Lackey and Bea Hughes give a great talk called “Attack-Driven Defense,” and it made a huge impact on me. The thesis is simple: defensive security should be based on real-world attack patterns.

The concept of driving a defensive security roadmap based on a real-world “attack path” was also mentioned in the last two Verizon Data Breach Investigations Reports. In this year’s report, they write:

Our friends at the Center for Internet Security contributed some thoughts on mitigating attack paths [...]
Much of security has been founded on catalogues of controls, vague vendor promises, laborious legislation, and tomes of things to do to keep your organization safe. Within this sea of options, we also have to justify our budgets, staff, and meet the business needs of the organization. Leveraging an attack path model is not only an important step towards formalizing our understanding of attacks, but also a means to understanding our defense. [...]
The more we can understand the sequence of events happening in an attack, the more we as a community can make it harder for adversaries to reuse the same process.

How does that apply to this post? The hardening and detection capabilities I describe here are in service of aiming to stop and detect an incredibly common attack path, illustrated in the following graphic.

After listing my hardening and detection-related improvements below, I’ll show the same graphic of the attack path, but with the addition of the hardening and detection steps that can be taken at each stage of the attack to stop it.

Eliminating the need for third-party management agents

It’s possible to configure macOS securely, but it’s not possible to do so via the MDM protocol and Configuration Profiles alone. Currently, many of the most important security settings and configuration files cannot be managed via MDM—instead, they can only be managed via macOS command line tools, or direct manipulation of files on disk. As a result, companies must choose a solution that runs an “agent” on the device in order to fully configure the system to be secure. This is true regardless of whether a company chooses a commercial solution like Fleetsmith, or an open source option like Puppet or Chef. The fact that it’s not possible to manage macOS securely via MDM artificially limits the number of enterprises who employ all the right protections. Additionally, these agents typically run as root, so if they have been poorly engineered, the management agents themselves can pose a security risk.

Today, it’s not possible for an organization to ensure that all platform security protections on macOS are enabled and configured in their strongest security mode, but the concrete technical changes suggested in this post would allow companies to better protect their macOS fleets by taking full advantage of native platform security features and configuration settings. As will become apparent, it’s possible to do great hardening and detection on macOS, but not without relying on command line tools and/or third-party agents. Thus, a majority of the feature requests described in this blog post are meant to describe exactly what functionality would need to be added to the MDM protocol and/or Configuration Profiles to eliminate the need for agents.

If Apple adds the management capabilities enumerated in this post, and MDM solutions incorporated support for them, then two things would be accomplished:

  1. Corporate Apple device fleets would be less likely to be hacked, and consumers’ data will remain safe and secure.
  2. We could move to a “world without agents,” which would decrease development overhead for device management vendors, and improve security posture for all organizations by eliminating the need for a highly privileged piece of software running as root (the management agent).

Two buckets: Hardening and Detection

Improvements to macOS platform security can be put into two buckets: hardening and detection. We’ll focus on the first, hardening, then move onto detection. Let’s start with hardening.

Hardening defined

What’s the goal of hardening?

  1. To make it harder for an attacker to gain a foothold by executing malicious software in the first place.
  2. To make it difficult for them to “move around” (move laterally) to other devices, if they do “gain a foothold” in an organization by successfully compromising one device.

A note on sequencing — platform security features and the Defense in Depth “layers”

The ordering of the content below is very intentional. I walk through every layer of the platform security feature stack starting from the lowest layer (firmware) up the the highest layer (code execution of third party binaries). Each feature should be thought of as another “layer” in the macOS “Defense in Depth” security model.

Here’s a quick summary of the macOS platform security stack to orient yourself before we dive in:

  • Firmware updates
  • Secure Boot
  • Notarization
  • Gatekeeper
  • XProtect
  • System Integrity Protection (SIP)
  • Major OS upgrades
  • Security Updates
  • Software Update System Preferences
  • Firewall
  • Configurable binary whitelisting/blacklisting

Without further ado, here's the table of technical problems and feature requests related to hardening.

Hardening summary table

Feature category Category Reporting or enforcement? Feature request Feedback ID
Firmware updates Hardening Reporting Add an MDM command that allows the device to call into an Apple API for checking whether a given device is running latest firmware available. FB6853576
Firmware updates Hardening Enforcement Same as feature requests related to major macOS upgrades. See below. -
Secure Boot Hardening Enforcement Add the ability to enforce any level of Secure Boot mode via Configuration Profile. If there is concern with this approach, then only add support for enforcing “Full” or “Medium” and do not offer the ability to enforce “Off”. FB6853600
Notarization Hardening Reporting Notarization status should be should be returned as part of response to the InstalledApplicationList MDM command. FB6853614
Notarization Hardening Reporting “Bare” binaries should be included in the response to the InstalledApplicationList MDM command. FB6853651
Notarization Hardening Enforcement Add new option in Gatekeeper Configuration Profile to only allow notarized software, to simulate what the transition will be like. FB6853657
Gatekeeper Hardening Reporting Add detailed information on Gatekeeper mode/status to SecurityInfo. FB6853685
XProtect Hardening Reporting Make the status of ConfigDataInstall available in the SecurityInfo command so that the MDM server can understand whether automatic updates to XProtect definitions are being enforced. FB6853721
XProtect Hardening Reporting The currently installed XProtect definition version should be made available in the SecurityInfo command. FB6853745
XProtect Hardening Reporting The device should be able to query the latest available version of the XProtect definitions, and return that info back to the MDM server. FB6853745
XProtect Hardening Enforcement Add ability to enforce automatic updates to XProtect definitions from a Configuration Profile. See “Software Update” section below. FB6853729
System Integrity Protection Hardening Enforcement Introduce an MDM command that allows enabling (but not disabling) SIP. FB6853759
Major macOS upgrades Hardening Reporting Include device timezone information in DeviceInformation MDM command response. FB6854915
Major macOS upgrades Hardening Enforcement Allow use of the ScheduleOSUpdate MDM command on UAMDM devices to drive increase in total corporate fleet upgrade percentages to new versions of macOS. FB6855058
Major macOS upgrades Hardening Enforcement Show the same “OS upgrade” notification that is shown to consumers. This notification includes an active “countdown timer” embedded within the notification. FB6855114
Major macOS upgrades Hardening Enforcement Show a notification to the end-user that their admin has triggered an OS upgrade, and that they need to be plugged into wall power for it to download. FB6855169
Major macOS upgrades Hardening Enforcement Eliminate the multi-minute delay, so that the device actually reboots more or less immediately when the user clicks the button. Alternatively, somehow communicate to the user that the install is “preparing” (e.g. introduce a “pending state” in design terminology). FB6855206
Major macOS upgrades Hardening Enforcement Allow the MDM server to deliver macOS notifications for any given update ahead of time (e.g. days or weeks in the future), to warn end-users in advance that an update will occur at a given date/time in the future. FB6855234
Security Updates Hardening Reporting Add an MDM command that allows the device to report back whether it has all the latest Security Updates available to it installed. FB6855255
Security Updates Hardening Enforcement Same as major macOS upgrades. -
Software Update System Preferences Hardening Enforcement Add ability to manage all of the settings seen in Software Update section of System Preferences via Configuration Profile by updating them to rely on CFPreferences, instead of writing/reading values directly to a plist on disk. FB6855499
Remote Login / SSH (hardening) Hardening Reporting Add information on com.openssh.sshd LaunchDaemon status in the response to the SecurityInfo MDM command. FB6855778
Remote Login / SSH (hardening) Hardening Enforcement Add the ability to enforce a desired state on the com.openssh.sshd LaunchDaemon via Configuration Profile, so that an admin can enforce whether “Remote Login” (sshd) is permanently “On” or Off”. FB6855517
Remote Login / SSH (hardening) Hardening Enforcement Add ability to manage /etc/ssh/sshd_config via Configuration Profile. FB6855545
Remote Login / SSH (hardening) Hardening Enforcement Add ability to manage access control for SSH/Remote Login via Configuration Profile. FB6855551
Screen Sharing / VNC Hardening Reporting Add information on com.apple.screensharing LaunchDaemon status in the response to the SecurityInfo MDM command. FB6857135
Screen Sharing / VNC Hardening Enforcement Update the Restrictions payload documentation within the Profile-Specific Payload Keys section of the Device Management documentation to include explanations of what effect setting allowRemoteScreenObservation and allowScreenShot to false has on macOS. FB6855566
Screen Sharing / VNC Hardening Enforcement Add ability to manage access control for Screen Sharing / VNC via Configuration Profile. FB6857596
Firewall rules (hardening) Hardening Reporting Make the info available via /usr/libexec/applicationfirewall/socketfilterfw commands available via MDM, by introducing a new MDM command for getting information about the Application Layer Firewall. FB6857676
Firewall rules (hardening) Hardening Reporting Make the info available via sudo pfctl -s rules command available via MDM, by introducing a new MDM command for getting information about the currently loaded PF firewall rules. FB6857734
Firewall rules (hardening) Hardening Enforcement Add the ability to manage PF firewall rules via a Configuration Profile, potentially be expanding on the existing ALF payload, or by introducing a new PayloadType for managing PF. FB6857752
Binary whitelisting/blacklisting (hardening) Hardening Enforcement There should be a way to get a list of which apps/binaries are currently present in the system policy database (“Gatekeeper database”) via MDM. If a binary or app is being blocked, information on what caused the block should be included (path, anchor, hash) in the data made available via MDM. FB6857826

If you're interested in the nitty gritty details of each, scroll down to the Appendix section of this post for the full details, including screenshots where applicable (e.g. macOS upgrade notifications).

This sums up the hardening section. Now, onwards to detection…

Detection

What’s the goal of detection?


In short—the goal of detection is to reduce “time to discovery” of a breach.

You may be thinking, “But wouldn’t it be obvious if we got hacked?” Unfortunately, it probably won’t be. Below is a graph showing the average “time to discovery” for breaches. The figures are from the highly respected Verizon Data Breach Investigations Report (DBIR), and n represents days.

Time to discovery in 2017

Source: Verizon Data Breach Investigations Report 2018, page 10.

Time to discovery in 2018

Source: Verizon Data Breach Investigations Report 2019, page 19.‌‌

The 2018 report is based on over 53,000 incidents and 2,216 confirmed data breaches, and the 2019 report is built upon analysis of 41,686 security incidents, of which 2,013 were confirmed data breaches.

Hopefully this helps illustrate the importance of detection capabilities. Although it may not be obvious at first, detection capabilities also fit into the framework of “Defense in Depth”—because if your hardening measures fail, you need to have detection capabilities to give you a chance to catch the attacker. If an attacker gets past your hardening measures and you don’t have good detection capabilities, you could end up being compromised for a long time before you realize it. That’s how you end up with graphs like those above.

Detection defined

OK, so detection is important, but what does detection actually mean from a technical standpoint? Broadly speaking, being able to detect the activities of advanced attackers requires information about low-level computing events. So when security teams talk about building “detection capabilities,” they mean building automated security alerts on top of the log files they have determined are good sources of data necessary for identifying suspicious activity.

The data required for this kind of powerful “intrusion detection” alerting includes things like:

  • Process spawning
  • Filesystem operations (e.g. read/write/execute)
  • Network activity (e.g. an app connected to a remote server)
  • Event details:
    • Date and time
    • Relationships (parent-child relationships or shared keys which connect events, like process id)
    • Additional details to assess the relevance or impact of the event

Without this data, it’s impossible to detect targeted attacks on an organization. This is because sophisticated attackers targeting top-tier tech companies will put in the effort to create never-before-seen malware that won’t be detected by typical corporate AntiVirus software.

Now, let’s dive into the improvements needed in macOS to make it easier for IT and Security teams to detect malicious activity on their fleets.

Feature requests related to detection

OpenBSM logging

Quite a few of the feature requests below focus on something called OpenBSM. A description of OpenBSM could be an entirely separate blog post, so I won’t be doing that here. But if you need more context for this section, I highly recommend watching Patrick Wardle’s talk called "Getting Cozy with Auditing on MacOS." Please note that the talk is highly technical in nature! That said, you can find a simple explanation for why audit logs are important at the 3:23 mark of his talk. I’ve also linked his slides and the YouTube video in the Appendix at the end of this post.

While OpenBSM logs are very powerful, they are difficult to work with in a centralized log aggregation system due to their format. Thus, one of the feature requests here is to modernize OpenBSM's logging. Below, I've included a mockup for what modern OpenBSM logs could look like. Credit goes to Michael George of the Dropbox Detection & Response Team for doing the heavy lifting on creating this beautiful mockup.

What modern OpenBSM logs could look like (mockup)

Color-coded key for the mockup above.

A note on the difference between a framework (EndpointSecurity) and native logging (OpenBSM)

Apple announced a great new framework in macOS called EndpointSecurity at WWDC. It’s a welcome improvement because it allows AntiVirus vendors to get the data they need instead of utilizing a kernel extension—and a great move by Apple given the security track record of some AntiVirus solutions.

That said, the EndpointSecurity framework is not a replacement for a general auditing tool like OpenBSM. IT and Security teams still need something that ships with macOS and gives them system level auditing—this can either be OpenBSM or a replacement that Apple builds on top of EndpointSecurity. Regardless of how it’s built, it should include all important info necessary to detect novel malware.

Now, here's the summary table of feature requests related to improving macOS detection, and the ability to manage configs related to that functionality via MDM.

Detection summary table

Feature category Category Reporting or enforcement? Feature request Feedback ID
OpenBSM logging (detection) Detection Reporting Log parent PID. Newer versions of OpenBSM support this. FB6857877
OpenBSM logging (detection) Detection Reporting Integrate with unified system logging, obviating the need for praudit. FB6857902
OpenBSM logging (detection) Detection Reporting Provide OpenBSM logs in a structured data format with a well-defined schema, so that they’re easy to work with within a centralized log aggregation system. FB6857947
OpenBSM logging (detection) Detection Enforcement Allow all OpenBSM settings to be managed via a Configuration Profile. FB6857970
Firewall logging Detection Enforcement Allow configuring firewall logging for PF via a Configuration Profile. FB6857982
Binary blacklisting/whitelisting Detection Reporting There should be a way to get a list of which apps/binaries are currently present in the system policy database (“Gatekeeper database”) via MDM. If a binary or app is being blocked, information on what caused the block should be included (path, anchor, hash) in the data made available via MDM. FB6857826
Binary blacklisting/whitelisting Detection Reporting Include detailed information on binary whitelisting/blacklisting execution events in OpenBSM logs. Logs should include all relevant info such as timestamp, path, hash, developer certificate, in a structured data format like JSON with a well thought out schema. FB6858025
Remote Login / SSH Detection Enforcement Add ability to manage sshd_config via Configuration Profile. FB6855545

Dang! We made it through the detection section as well. What a journey—let’s wrap this up.

A look at that attack path again, this time with hardening and detection at each stage

Let’s take a look at that graphic of the attack path from the beginning of the post. Note the hardening measures that can be applied to attempt to prevent each stage of the attack, and the detection measures that can be applied to attempt to detect each stage of the attack. This graphic directly illustrates the power of building the features described in this post.

One more thing…


This post doesn't address physical attacks, but there’s one thing in particular that has become so table stakes that I thought it deserved special attention—that’s FileVault.

There are a few shortcomings when it comes to reporting on and enforcing FileVault, and I enumerated them below.

FileVault summary table

Feature category Category Reporting or enforcement? Feature request Feedback ID
FileVault Hardening Reporting Add the ability the validate a previously escrowed recovery key via an MDM command FB6858053
FileVault Hardening Reporting Make the information about FileVault state available via MDM FB6858082
FileVault Hardening Enforcement Allow the existing Configuration Profile for FileVault disk encryption to take effect immediately during Setup Assistant, without requiring a reboot. FB6858089

Insanely great macOS enterprise security

With FileVault out of the way, we’ve finally come to the end of this massive post.

To wrap things up—there is an opportunity for huge positive impact if these changes are implemented, and Apple, enterprises, and consumers all stand to benefit. If you’re outside of Apple, dupe those feedback reports! And if you work at Apple, please spread the word. Let’s make this stuff amazing and help protect each other from the malicious hackers out to ruin our days 🙂🔐🎉✨

Shoutouts!

Not last and definitely not least, a few quick shoutouts. A very heartfelt thank you to:

  • Michael George for his incredible contributions to the entire “detection” section of this post—and particularly the mockup JSON and color key! I couldn’t have done this section without you. Thank you again 🙂
  • Apple's Security Engineering and Device Management teams for the great talks at WWDC, and the great work they’re doing to push the platform forward.
  • @wikiwalk aka @groob aka Victor Vrantchan (micromdm, Google) for his excellent research and blog post documenting the issues with trying to manage macOS OS upgrades via MDM. A large amount of the material on the shortcomings of the MDM experience for major macOS upgrades is based the research he shared in that post.
  • Fleetsmith EPD (Engineering, Product, Design) for building an amazing product experience for both IT and end users, by implementing clever solutions that work around the problems described in this post.

Appendix

Resources and documentation

WWDC 2019 talks

Documentation

Talks

Blog posts and reports

Tools

  • SUpraudit, Jonathan Levin (Technologeeks) — A third-party (non-Apple) rewrite of praudit that makes OpenBSM logs much more useful by a) adding code-signing information to log events for processes, b) allowing output to JSON, and c) including socket activity and process lifecycle info. In the author’s words, SUperaudit is:
a praudit(8) clone on steroids which can track all activity on a MacOS system via the built-in BSM audit facility. It's every bit as good as filemon, and actually better, since it can do socket activity and process lifecycle as well.

Firmware updates — Reporting

Problem: Not possible to know whether a given device is running the latest firmware via MDM.
Feature request: Add an MDM command that allows the device to call into an Apple API for checking whether a given device is running latest firmware available. Allow the response to “proxy” the response back to the MDM server. Like Duo’s project “EFIgy” project, but provided by Apple.
Feedback ID: FB6853576

Firmware updates — Enforcement

Problem: In theory, information on firmware updates is available in the response to the AvailableOSUpdates MDM command since a firmware update would show up as IsFirmwareUpdate = true. In reality, the same problems that plague MDM OS update functionality apply here as well. See “Major macOS upgrades: section below for more info.
Feature request: Same as feature requests related to major macOS upgrades. See below.


Secure Boot — Reporting

Exists! Includes reporting on whether it’s supported by the device and what mode it’s in:

  • Off
  • Medium
  • Full

See the SecureBoot section of the response to the SecurityInfo MDM command.

Secure Boot — Enforcement

Problem: It’s not possible to enforce a specific security level for Secure Boot via MDM.
Feature request: Add the ability to enforce any level of Secure Boot mode via Configuration Profile. If there is concern with this approach, then only add support for enforcing “Full” or “Medium” and do not offer the ability to enforce “Off.”
Feedback ID: FB6853600


Notarization — Reporting

Problem: It’s not possible to know which apps are notarized via MDM. This limits the ability of an organization to understand in advance which apps could cause them problems (including legacy apps that are no longer developed). If reporting information was available, enterprises could plan ahead, and even help Apple push third party software vendors to get their apps notarized faster than they otherwise would.
Feature request: Notarization status should be should be returned as part of response to the InstalledApplicationList MDM command.
Feedback ID: FB6853614

Problem: Apple has said binaries “can and should be notarized”*, but they are not included in the response to the InstalledApplicationList MDM command.
Feature request:  “Bare” binaries should be included in the response to the InstalledApplicationList MDM command.
Feedback ID: FB6853651

*28:57 — “All About Notarization,” WWDC 2019

Notarization — Enforcement

Problem: It’s not possible for organizations to “simulate” the transition to a world where macOS only allows notarized software and “see what breaks”.
Feature request: Add new option in Gatekeeper Configuration Profile to only allow notarized software, to simulate what the transition will be like. A flag  for this almost certainly exists within macOS for Apple’s own internal development of Notarization as a platform security feature. Allowing a flag for RequireNotarization = true to be set via a Configuration Profile would allow enterprises to test and prepare for this transition ahead of time.
Feedback ID: FB6853657


Gatekeeper — Reporting

Problem: DeviceInformation MDM command provides some info on Gatekeeper, but needs more granularity. The only thing it returns is whether AutomaticSecurityUpdatesEnabled is on or off.
Feature request: Add detailed information on Gatekeeper mode/status in the response to the SecurityInfo MDM command.
Feedback ID: FB6853685

Gatekeeper — Enforcement

Exists! Gatekeeper policy can be managed via Configuration Profile.


XProtect — Reporting

Problem: DeviceInformation  query for OSUpdateSettings returns some info on Software Update settings related to XProtect, but needs more granularity. It only returns is whether AutomaticSecurityUpdatesEnabled is on or off.
Feature request: Make the status of ConfigDataInstall available in the SecurityInfo command so that the MDM server can understand whether automatic updates to XProtect definitions are being enforced.
Feedback ID: FB6853721

Problem: It’s not possible to know whether currently installed XProtect definitions are out of date, or what the newest version is via any method, including MDM.
Feature request #1: The currently installed XProtect definition version should be made available in the SecurityInfo command.
Feature request #2: The device should be able to query the latest available version of the XProtect definitions, and return that info back to the MDM server.
Feedback ID: FB6853745
Note: Both feature requests are associated with the same feedback ID.

XProtect — Enforcement

Problem: It’s not possible to specifically enforce XProtect definition updates via MDM/Configuration Profile.
Feature request: Add ability to enforce automatic updates to XProtect definitions from a Configuration Profile. See “Software Update” section below.
Feedback ID: FB6853729


System Integrity Protection (SIP) — Reporting

Exists! SIP status is available in the response to the SecurityInfo MDM command.

System Integrity Protection (SIP) — Enforcement

Problem: It’s not possible to re-enable SIP via MDM. It’s possible to (re)enable SIP via the csrutil command line tool by running csrutil clear and then rebooting the device. This same functionality should be possible via MDM.
Feature request: Introduce an MDM command that allows enabling (but not disabling) SIP.
Feedback ID: FB6853759


Major macOS upgrades — Context

Enforcing macOS upgrades via MDM is supported in theory, but has historically been unreliable and/or been a bad user experience for end users. groob’s “Updating to Mojave?” blog post on the micomdm blog covers the majority of issues described below. Among other things, it also describes how the functionality for the  IsMajorOSUpdate MDM command was non-functional for several months because Apple did not add the appropriate product key to the Software Update catalog.

Major macOS upgrades — Reporting

Problem: Local timezone info not available via MDM queries. Currently requires an running systemsetup -gettimezone or using an agent to get this info. This info is necessary for the MDM server to be able to schedule updates for all employees at the “same time” regardless of the employee’s timezone. This info can be obtained via the systemsetup command line tool (by running systemsetup -gettimezone), but command line tools can’t be invoked via MDM.
Feature request: Include device timezone information in DeviceInformation MDM command response.
Feedback ID: FB6854915

Major macOS upgrades — Enforcement

Problem: Due to requirement for Supervision to invoke the ScheduleOSUpdate MDM command, the total number of corporate macOS devices that have important security patches installed is reduced. Since UAMDM is not sufficient, this makes providing fleet-wide OS upgrade functionality via MDM impossible, since no organization has 100% of their fleet enrolled in DEP.
Feature request: Allow use of the ScheduleOSUpdate MDM command on UAMDM devices to drive increase in total corporate fleet upgrade percentages to new versions of macOS. Allowing OS upgrades to be enforced on UAMDM devices would allow a much greater number of devices in corporate environments to have automated OS upgrades performed on them. Since dot releases include many security updates, this change would lead to increased organizational security across all companies using an MDM solution.
Feedback ID: FB6855058

Problem: The macOS notification shown to an end-user after an OS upgrade has been scheduled via MDM does not have parity with the consumer-facing upgrade UX. Unlike the consumer experience, the MDM notification is generic—it says nothing about it being an OS upgrade. See screenshot.
Feature request: Show the same “OS upgrade” notification that is shown to consumers. This notification includes an active “countdown timer” embedded within the notification.
Feedback ID: FB6855114

Enterprise user experience.
Consumer user experience.

Problem: Download of OS update triggered by ScheduleOSUpdate MDM command only occurs when device is plugged into power, but this requirement is not communicated to the end-user.
Feature request: Show a notification to the end-user that their admin has triggered an OS upgrade, and that they need to be plugged into wall power for it to download. Before the APFS transition, there was macOS notification related to FileVault encryption/decryption that warned users about needing to be plugged into a power adapter for encryption to complete. The notification for OS upgrades should be fairly similar. I’ve included a screenshot of the FileVault notification below for reference.
Feedback ID: FB6855169

Problem: When using the InstallASAP subcommand of the ScheduleOSUpdate MDM command, there can be a multi-minute delay between when the user clicks “Restart” within the notification and when the device actually reboots. During this time, the user is given no indication that install has begun. The user experience is that it seems as if nothing is happening and the install has failed, until the device reboots several minutes later without warning.
Feature request: Eliminate the multi-minute delay, so that the device actually reboots more or less immediately when the user clicks the button. Alternatively, communicate to the user that the install is “preparing” (e.g. introduce a “pending state” in design terminology).
Feedback ID: FB6855206

Problem: It’s not possible for an MDM server to send macOS notifications to end-users, to proactively communicate a future date/time when the enterprise will enforce an OS upgrade on their device. This results in a poor user experience for employees, wherein their device will reboot without warning at the time the OS upgrade is triggered (e.g. via InstallASAP). This means device management vendors and/or IT teams who wish to offer a good user experience around upgrades are forced to build that functionality outside of MDM (via an agent or custom internal scripts).
Feature request: Allow the MDM server to deliver macOS notifications for any given update ahead of time (e.g. days or weeks in the future), to warn end-users in advance that an update will occur at a given date/time in the future. The ability to deliver notifications should either be standalone functionality, or work in tandem with the InstallApplication, InstallEnterpriseApplication, and ScheduleOSUpdate MDM commands.
Feedback ID: FB6855234


Security Updates — Reporting

Problem: It’s not possible to know whether a given device has the latest Security Updates installed via MDM.
Feature request: Add an MDM command that allows the device to report back whether it has all the latest Security Updates available to it installed.
Feedback ID: FB6855255

Security Updates — Enforcement

Problem(s): Same as major OS upgrades (previous slides).
Feature request: Same as major OS upgrades (previous slides).
Feedback ID: Same as previous macOS major upgrade feedback IDs.


Software Update System Preferences — Reporting

Exists! Possible to query status of all 5 checkboxes seen in System Preferences UI.

  • AutomaticAppInstallationEnabled
  • AutomaticCheckEnabled
  • AutomaticOSInstallationEnabled
  • AutomaticSecurityUpdatesEnabled
  • BackgroundDownloadEnabled

See the OSUpdateSettings section of the response to the DeviceInformation MDM command.

Here’s a screenshot of how this looks in the UI in System Preferences:

Software Update System Preferences — Enforcement

Problem: Some of the preferences found under System Preferences → Software Update → Advanced cannot be managed via Configuration Profile because they don’t use CFPreferences.

These 6 values are managed via 2 files. com.apple.SoftwareUpdate.plist does not use CFPreferences, which is where both XProtect/Gatekeeper definitions live (in ConfigDataInstall) and where Secutity Updates live (in CriticalUpdateInstall).

The management of all Software Update settings should move from utilizing file-based storage to using CFPreferences, so they can be managed via Configuration Profile.

The Mac Lovin’ blog has a highly relevant post on managing these System Preferences Software Update values via direct file plist manipulation.

Feature request: Add ability to manage all of the settings seen in Software Update section of System Preferences via Configuration Profile by updating them to rely on CFPreferences, instead of writing/reading values directly to a plist on disk.
Feedback ID: FB6855499


Remote Login / SSH (hardening) — Reporting

Problem: There is no way to check whether the SSH server (sshd) in macOS is running or not, via MDM. SSH is also known as “Remote Login” in macOS and can be found under: System Preferences → Sharing → Remote Login.
Feature request: Add information on com.openssh.sshd LaunchDaemon status in the response to the SecurityInfo MDM command.
Feedback ID: FB6855778

Remote Login / SSH (hardening) — Enforcement

Problem: It’s not possible to enforce whether “Remote Login” (sshd ) is On or Off via MDM or Configuration Profile.
Feature request: Add the ability to enforce a desired state on the com.openssh.sshd LaunchDaemon via Configuration Profile, so that an admin can enforce whether “Remote Login” (sshd) is permanently “On” or Off”. To sketch out how this could work—in a world where this was manageable via a Config Profile, there would be a way to specify ssh_enabled: false, which would prevent any user from loading the LaunchDaemon (even root, unless SIP was disabled). Note: The LaunchDaemon file lives at: /System/Library/LaunchDaemons/ssh.plist
Feedback ID: FB6855517

This is what this setting looks like in the UI (on/off checkbox on left side of image):

Problem: It’s not possible to manage macOS’s SSH server settings via MDM. Specifically, the settings that can be configured in /etc/ssh/sshd_config. This means it’s not possible to harden the configuration to do things like disable password-based authentication.
Feature request: Add ability to manage /etc/ssh/sshd_config via Configuration Profile. Note that changes that are particularly important to be able to manage for hardening purposes includes disabling password auth (enforce key-based auth) by setting ChallengeResponseAuthentication no and PasswordAuthentication no.
Feedback ID: FB6855545

Note: Settings in the sshd_config file that only relate to detection will be covered in the detection section further down in this blog post.

Problem: The access control options for managing allowed users and groups under System Preferences → Sharing → Remote Login can not be managed via MDM/Configuration Profile. Access control can only be managed via command line tools, which cannot be invoked via MDM. See this Github Wiki page for more info on how these access control settings have to be managed today by using the dseditgroup command line tool.
Feature request: Add ability to manage access control for SSH/Remote Login via Configuration Profile.
Feedback ID: FB6855551

Note: This is what this looks like in the UI (user/groups list on right side of image):


Screen Sharing / VNC — Reporting

Problem: There is no way to check whether the Screen Sharing server (screensharingd ) in macOS is running or not, via MDM.
Feature request: Add information on com.apple.screensharing LaunchDaemon status in the response to the SecurityInfo MDM command.

Feedback ID: FB6857135

Note: The LaunchDaemon file lives at /System/Library/LaunchDaemons/com.apple.screensharing.plist

Screen Sharing / VNC — Enforcement

Problem: Support for managing macOS Screen Sharing settings was announced at WWDC, but currently available documentation does not include enough information to be useful. See below:

And we also brought all of the settings that configure certain Classroom behaviors that you have on iOS back to macOS. Including the ones that control classroom screens view feature. But we didn’t stop there, we also made all of the other screen viewing features that you know and love in macOS—from screen sharing, screenshot, and Apple Remote Desktop—respect those restrictions as well.*

*7:20 — “What’s New in Managing Apple Devices,” WWDC 2019

Feature request: Update the Restrictions payload documentation within the Profile-Specific Payload Keys section of the Device Management documentation to include explanations of what effect setting allowRemoteScreenObservation and allowScreenShot to false has on macOS. The updated documentation should be specific about the effects on each area of functionality mentioned in the WWDC talk:

- Screen Sharing
- Screenshots
- Apple Remote Desktop

Feedback ID: FB6855566

Problem: The access control options for managing allowed users and groups under System Preferences → Sharing → Screen Sharing cannot be managed via MDM/Configuration Profile. Access control can only be managed via the command line tools dseditgroup command line tool, which can’t be invoked via MDM.
Feature request: Add the ability to manage access control for Screen Sharing / VNC via Configuration Profile.
Feedback ID: FB6857596

Note: This is what this looks like in the UI (user/groups list on right side of image):


Apple Remote Desktop (ARD) — Reporting

Exists! Available in SecurityInfo MDM command response under RemoteDesktopEnabled.

Apple Remote Desktop (ARD) — Enforcement

Exists! Can be enforced via MDM commands, and possibly also Configuration Profile (see feature request for better documentation on the “Restrictions” payload in “Screen Sharing / VNC” section above).

MDM commands:


Firewall rules (hardening) — Reporting

Problem: It’s not possible to get info on the state of the Application Layer Firewall via MDM.
Feature request: Make the info available via /usr/libexec/applicationfirewall/socketfilterfw commands available via MDM, by introducing a new MDM command for getting information about  the Application Layer Firewall. The same information returned by these flags should be made available:

  • --getglobalstate
  • --getblockall
  • --listapps
  • --getappblocked
  • --getallowsigned
  • --getstealthmode
  • --getloggingmode
  • --getloggingopt

Feedback ID: FB6857676

Problem: It’s not possible to get info on the state of the PF firewall via MDM.
Feature request: Make the info available via sudo pfctl -s rules command available via MDM, by introducing a new MDM command for getting information about the currently loaded PF firewall rules. See this page for documentation on working with PF on macOS, including bugs and limitations.
Feedback ID: FB6857734


Firewall rules (hardening) — Enforcement

Problem: It’s not possible to manage PF firewall rules via MDM. Currently, managing PF requires:

  • placing a custom PF “anchor” file placed in /etc/pf.anchors/ that contains the custom firewall rules
  • creating a custom LaunchDaemon to run the command to load the anchor
  • Frequent flushing and reloading of rules, so that ALF doesn’t “squash” custom anchors

None of the above is possible via MDM, since MDM can’t manage arbitrary files on disk or manipulate LaunchDaemons.

Feature request: Add the ability to manage PF firewall rules via a Configuration Profile, potentially be expanding on the existing ALF payload, or by introducing a new PayloadType for managing PF. Implementation should ensure specified firewall rules are enforced. Setting them a single time only at time of Config Profile installation would be insufficient.
Feedback ID: FB6857752


Binary whitelisting/blacklisting (hardening) — Reporting

Problem: It’s not possible to get info (via MDM) on which binaries are being blacklisted/whitelisted by Gatekeeper in the system policy database.
Feature request: There should be a way to get a list of which apps/binaries are currently present in the system policy database (“Gatekeeper database”) via MDM. If a binary or app is being blocked, information on what caused the block should be included (path, anchor, hash) in the data made available via MDM.
Feedback ID: FB6857826

Binary whitelisting/blacklisting (hardening) — Enforcement

Exists! Support for binary whitelisting and blacklisting exists behind the scenes in macOS as part of Gatekeeper, and it’s possible to manage via a Configuration Profile. See the documentation for the “System Policy” payload on how to manage whitelisting/blacklisting by:

  • path
  • anchor (certificate)
  • hash

More info can be found in the man page for spctl in the RULE SUBJECTS section.


OpenBSM logging — Enforcement

Problem: It’s not possible to configure OpenBSM settings via MDM, since it can only be configured by modifying files on disk. The files that need to be modified are:

  • /etc/security/audit_control
  • /etc/security/audit_class

See this excellent post by Rich Trouton for background context on how OpenBSM can be configured using those two files.
Feature request: Allow all OpenBSM settings to be managed via a Configuration Profile.
Feedback ID: FB6857970

OpenBSM logging — Reporting

Problem: OpenBSM logs are missing parent PID.
Feature request: Log parent PID. Newer versions of OpenBSM support this.
Feedback ID: FB6857877

Problem: It’s not possible to use MDM to enable and configure OpenBSM logging, since MDM is not able to manipulate LaunchDaemons. Currently, configuring the system to OpenBSM write logs in a non-binary format, and in a format that can be used for security alerting requires the following:

  • writing a custom LaunchDaemon that invokes praudit
  • loading that LaunchDaemon

Feature request: Integrate with unified system logging, obviating the need for praudit.
Feedback ID: FB6857902

Problem: OpenBSM logs are difficult to work with in a centralized log aggregation system due to their format.
Feature request: Provide OpenBSM logs in a structured data format with a well-defined schema, so that they’re easy to work with within a centralized log aggregation system. See below for a mockup of what this could look like.
Feedback ID: FB6857947


Firewall logging — Enforcement

Problem: It’s not possible to use MDM to configure PF’s powerful logging features. Configuring PF logging requires numerous steps, including a custom launchd and script that sets up a virtual interface and piping tcpdump. The configuration process requires modifying multiple files on disk, which is not possible via MDM. For information on multi-step process required setup PF logging, see the pflog section of the documentation on this page.
Feature request: Allow configuring PF firewall logging via a Configuration Profile.
Feedback ID: FB6857982


Binary blacklisting/whitelisting logging (detection) — Reporting

Problem: It’s not possible to get info (via MDM) on which binaries are being blacklisted/whitelisted by Gatekeeper in the system policy database.
Feature request: There should be a way to get a list of which apps/binaries are currently present in the system policy database (“Gatekeeper database”) via MDM. If a binary or app is being blocked, information on what caused the block should be included (path, anchor, hash) in the data made available via MDM.
Feedback ID: FB6857826

Problem: Detailed system policy (Gatekeeper) information on execution events is missing in OpenBSM logs.
Feature request: Include detailed information on binary whitelisting/blacklisting execution events in OpenBSM logs. Logs should include all relevant info such as timestamp, path, hash, developer certificate,  in a structured data format like JSON with a well thought out schema. See JSON mockup of modernized OpenBSM elsewhere in this blog post for an idea of what this could look like.
Feedback ID: FB6858025


Remote Login / SSH logging — Enforcement

Problem: It’s not possible to manage macOS’s SSH server settings via MDM. Specifically, the settings that can be configured in /etc/ssh/sshd_config. This means it’s not possible to log SSH key fingerprints, which is extremely important for detection.
Feature request:
Add ability to manage sshd_config via Configuration Profile.

  • There is only 1 change that is important to be able to manage for detection, which is ensuring that SSH public key fingerprints get logged for incoming connection attempts to sshd. This is accomplished by setting the log level to “verbose” like this:LogLevel VERBOSE

Feedback ID: FB6855545


FileVault — Reporting

Problem: It’s not possible to validate whether a previously escrowed FileVault PRK (Personal Recovery Key) is valid. This functionality exists in the command line tool fdesetup, but command line tools cannot be invoked via MDM. The relevant command is: fdesetup validaterecovery.
Feature request: Add the ability to validate a previously escrowed FileVault Personal Recovery Key via MDM.
Feedback ID: FB6858053

Problem: 5 pieces of information critical to understanding FileVault disk encryption state are not available via MDM. Getting this info currently requires invoking fdesetup, which is only possible via a script or a management agent.
Feature request: Make the information about FileVault state available via MDM, including:

  • Enabled (bool)
  • Complete (bool)
  • Paused (bool)
  • ProgressPercent (float64)
  • PendingReboot (bool)

Feedback ID: FB6858082

FileVault — Enforcement

Problem: The existing Configuration Profile PayloadType for FileVault cannot enforce FileVault at first login. It requires a reboot to enforce (at login window), even on new devices where that’s not necessary.
Feature request: Allow the existing Configuration Profile for FileVault disk encryption to take effect immediately during Setup Assistant, without requiring a reboot.
Feedback ID: FB6858089

Subscribe to Fleetsmith Blog

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!