Ability to detect macOS upgrade using Endpoint Security Events

Use case: Enable more efficient and quick OS Upgrade on mac systems by detecting the OS upgrade.

Why? What are you actually trying block/prevent/track here?

Our observations: To understand how OS upgrade works, we observed ES events during the upgrade (using eslogger)

First of, I'd recommend reading through "Inferring High-Level Semantics from Low-Level Operations", as this is exactly the kind of thing it's talking about.

https://developer.apple.com/forums/thread/744265

and found the below observations:

For OTA upgrade:

• nsurlsessiond starts downloading the UpdateBrainService to a temporary location

<...>

• Processes from within the full installer App like InstallAssistant_springboard, InstallAssistant, osinstallersetupd, osisstashhelper, osishelperd_intel.

Sure, those all basically sounds like things the system would be doing.

The problem is when you ask this:

Confirm if the above processes and events we are looking at are good enough, or if there are more significant events (file operations or process launches) that we can look at to more certainly detect the OS upgrade start.

You're asking a question that can't really be answered, at least not in a reliable way. Architecturally, all of the pieces here are independant components, generally written and maintained by different teams, which intentionally try and minimize any they're "knowledge" about each "other". Most of the details you're describing aren't because of any specific high level architectural choice but are instead simply the way that particular component happens to work. In theory, Apple could determine the EXACT details of how something like the update sequence works but, in practice, we'd do that using the same basic process you're using.

As a more clearcut example of this dynamic, no one person at Apple can actually answer the question "What does the system write to /tmp?". The point of the "/tmp" directory is to provide a location where temporary data can be written without the need for the components involved to actively coordinate with each other. Trying to track and manage all possible I/O sources would be recreating the coordination and management problems "/tmp" was created to avoid. Looking for problems or unexpected behavior is obviously part of our testing an QA process, but that's very different than specifically trying to Know™ exactly what's going on.

Any kind of formal answer we could provide to this sort of questions would:

• Require a lot of work, since the first step would be to try and determine what the system happened to be doing.

• Would only be accurate to the extent that the behavior HAPPENED to be stable across machine configuration, system configuration, and system version.

• Create a false sense of stability.

That last point is critical. What you're looking at here are the undocumented internal implementation details of the system. These details have never been documented because we want to be able to change them without worrying about software breaking because they changed.

There are valid reasons why you might choose to build code that relies on these details, however, that choice can only be safely made if you also accept that this behavior is NOT in fact stable/reliable. That means building the testing infrastructure necessary to monitor the systems behavior (so you know when it changes) and building your application logic so that it behaves well regardless of how the system evolves (so you don't break when it changes). That's the only safe option.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you so much for the detailed reply and information. We will raise a feedback/enhancement request with more detailed description of our requirements.