Tailored Event Monitoring on macOS

Introduction

If you've navigated here, you're likely interested in learning how to write your own custom analytics for custom macOS event monitoring. This resource is designed to guide you through the process!

You might be asking yourself, "What exactly are custom analytics, and why would I need them?"

To clarify right at the start, for protection of your macOS endpoints with Jamf Protect against threats or for detecting suspicious user or system activity, crafting custom analytics isn’t a necessity. Jamf-managed analytics and threat prevention capabilities offer extensive coverage, monitoring real-time, event-driven activities on macOS systems.

However, there are scenarios where security analysts seek to track activities specifically targeted at their organization. In such cases, custom analytics, functioning as predicate-based filters, can be particularly beneficial. But, before delving into custom analytics, it's important to understand the situations in which they are truly needed.

Deciding when to implement custom Analytics

The more you familiarize yourself with Jamf Protect, the more you'll realize its ability to collect valuable data from endpoints, crucial for security and IT teams. However, determining which specific area of Jamf Protect can provide the necessary data for your particular use case or scenario may require some guidance or research.

If the goal is to implement a pre-defined solution that offers both broad and deep macOS event monitoring, telemetry would be more appropriate.

Before we delve into how to start writing custom analytics, let's first review the types of events and data streams that Jamf Protect can set up. Understanding these will better inform your decision on whether a custom analytic is necessary, either to collect specific information from an endpoint or to detect activities unique to your organization or endpoints that are not covered by Jamf-managed analytics.

Given that you have likely already explored Jamf Protect, you've probably noticed multiple areas where custom items can be created. Let's take a closer look at these areas before proceeding.

• Analytics
  • Analytics are predicate based rules that detects suspicious user behaviour and malicious system activity on macOS computers, Jamf Threat Labs creates and maintains Jamf-managed Analytics monitoring and alerting up suspicious activity or behaviour.
  • Custom Analytics
    • Custom Analytics provides security teams a framework to create custom predicate based rules to start monitoring for specific activity happening on managed endpoints. Depending on the chosen sensor type activity can be monitored and reported on. We’ll go deeper in to this further down in the write-up.
• Telemetry
  • Telemetry allows you to collect system and user event log data and send it to a security information and event management (SIEM). Telemetry log data helps administrators and information security specialists proactively monitor and detect anomalies on macOS endpoints in their environments.
    • Telemetry is divided into two log levels and based on the chosen level an certain amount of telemetry data collected.
• Unified Logging
  • The Unified Logging system on macOS provides a central location to store log and event data on the Mac, with Jamf Protect, you can use predicate-based filters to collect relevant log entries from computers and send them to a security information and event management (SIEM) solution or a third party storage solution (e.g., AWS).
• Threat Prevention
  • Threat Prevention provides prevention capabilities to detect and block threats up on execution, meaning that Jamf Protect monitors each process execution and allow or deny the operation and execution of the process based on the fact if there is an match in Jamf Protect’s threat database.
  • Custom Prevention Lists
    • Custom prevention lists allow you to specify additional processes to block using Jamf Protect based on file hashes and Apple-specific signing information.
• Network Threat Prevention
  • Network Threat Prevention offers web threat prevention on-device to keep your users and system safe from cyber threats. This protection includes vulnerability assessments, network-based security protections and content-filtering.

Now that we have reviewed this, it’s clear that Jamf Protect provides an extremely powerful framework to gather an extensive list of curated information from macOS endpoints out-of-the-box or provides the tools to create custom rules to gather additional information from macOS endpoints.

More and more security teams are keen to get additional information from an endpoint or start monitoring activity that is specific to their organization or user group. Without knowing the capabilities of Jamf Protect, administrators usually start creating custom analytics to detect certain activity or behavior, while this is not always necessary as the data that we might need for detection is already being collected by telemetry.

As you know, endpoint protection does not come for free from a system resource perspective, meaning we need to be mindful when creating custom analytics or Unified Log filters and really evaluate if this data is not already collected by default by telemetry, thus avoiding the duplication of collecting data. Both telemetry and Unified Logging require integrating with a SIEM or third-party storage solution, so if that’s not yet in place, or on the roadmap of the organization, then yes, we might already have more reasons to rely on leveraging custom analytics.

Let’s take a look at some use cases to provide some context:

• As a security analyst, I want to monitor process executions that are not signed with a valid Developer Certificate or unsigned at all.
  • While this could be tracked with a custom analytic and generate an alert, Telemetry Level 1 already reports on process executions and contains the related signing information as well. We could use this data in a SIEM, saving us from creating a custom analytic and preserving system performance.
• As a security analyst, I want to monitor tamper events related to the Jamf Pro management framework.
  • This would be a good use case for writing a custom analytic. However, Jamf Protect already provides detections for this activity using a set of Jamf-managed analytics.
• As a security analyst, I want to monitor a particular file being created, renamed, or modified on a specific file path by anyone except a particular user UID.
  • This is a perfect use case for creating a custom analytic where we can monitor file system events and use a set of criteria to detect this activity and generate an alert.
• As a security analyst, I want to keep track of user and group creation or changes across all my endpoints.
  • Telemetry by default keeps track of this activity and generates events that inform you as these changes happen. AUE_create_group or AUE_create_user are relevant examples to review.
• As a security analyst, I want to keep track of files being written to a removable storage device by a specific process.
  • There are default Jamf-managed analytics that provide informational alerts on USBWrite events, or telemetry information about a drive being mounted. However, custom analytics could be used here to detect specific files or file types being written to an external volume by specific processes, and could generate a low or medium severity alert.

The examples provided above are basic, yet they offer valuable context to consider before you continue on building a custom analytic. Below, you’ll find a simple diagram that can serve as a useful reference.

Now that we have this covered, you can decide if we need to create a custom analytic to capture specific activity or if we can rely on the above-mentioned features of Jamf Protect.

If it’s the former, let’s continue to the second section. If it’s the latter, then this is a good future reference to revisit!

Fundamentals of creating (custom) Analytics

As you have already read in the introduction, analytics are predicate-based filters that provide capabilities for monitoring specific user or system activity on macOS endpoints. Once the conditions are met for an event, an alert is triggered, providing the relevant context to the security administrator in the Jamf Protect macOS Security portal.

Jamf-managed analytics are provided and kept up to date by Jamf Threat Labs to offer detection and protection against novel security events, including thousands of previously unknown and undiscovered threats.

Just as Jamf Threat Labs employs analytics for detection purposes, security analysts or administrators can similarly leverage custom analytics to create their own detections.

Let's review the basic requirements of a custom analytic in order to exist in Jamf Protect before we go deeper into the specific sensor types, the predicate, query language, and the available documentation.

Each custom Analytic does require to to have at minimum

• Analytic Description
  • Name
    • The name provided by the security administrator will be the name of the Analytic, but also the name of the alerts that could be generated as well. TIP: be mindful about a name format that makes sense to your security team, try to keep it consistent and specific.
  • Description
    • It’s optional to provide a description, but it’s strongly recommended. As you are building a custom analytic, it’s not always easy for anyone to read the predicate filter and understand what it’s detecting. Provide a description of the event once detected, as this will be the summary in the alert that gets created.
  • Category
    • Optionally select the categories to associate with the custom analytic or define your own categories in the dropdown menu. This data is exposed in generated alerts and forwarded data to a SIEM or 3rd party storage solution as well.
  • Level
    • For now, we’ll leave the level set to 0, but this can be used to build chained analytics where potentially a level 1 or level 2 analytic can only be triggered if a lower level has been triggered, and they have been linked to each other using Tags.
• Severity
  • Select the severity that you would like to associate with the custom Analytic.
    • If informational is chosen as severity, ensure that in the action configuration for sending alert data to Jamf Protect, the minimum severity is set to Information as well.
    • If alerts are being forwarded to a SIEM or 3rd party storage solution, then the severity is represented in integers where 0=informational, 1=low, 2=medium, 3=high.

We have now covered the basics that each custom analytic requires, but the analytic doesn't mean anything until we have defined what type of activity it's going to monitor and have provided a valid predicate filter.

Exploring the range of Sensor Types in Analytics

As an important step during the creation of a custom analytic, we need to select the type of behaviour or activity we initially want to monitor. The chosen sensor type defines what type of detection we are able to create.

Below, we will explain the various sensor types that are available in Jamf Protect and what they are capable of providing.

• Analytic Filter
  • Sensor Type
    • File System Event
      • This event provides capabilities in to detecting the creation, renaming, modification or deletion of files or directories.
    • Download Event
      • This event provides capabilities in to detecting files being downloaded from the internet on to the file system using the Safari Sandbox broker.
    • Process Event
      • This event provides capabilities in to detecting a process being launched or terminated and containing the relevant subtypes (eg. exec, fork, posix_spawn, execve).
    • Screenshot Event
      • This event provides capabilities in to detecting a process using the ScreencaptureKit framework on macOS and is creating a file on to the file system.
    • Keylog Register Event
      • This event provides capabilities into monitoring for new "event tap" registrations via the Core Graphics framework on macOS. Core Graphic event taps are often used by certain types of key logging and accessibility software.
    • USB Event
      • This event provides capabilities into monitoring the insertion or removal of USB devices from an endpoint.
    • Gatekeeper Event
      • This event provides capabilities into monitoring actions and logs from Gatekeeper, Apple's built-in feature for enforcing code signing and verifying downloaded apps before opening them.

That's an extensive list of sensor types, and for each analytic, we can only pick one. We’ll leave this as it is for now and jump into explaining the predicate language.

Understanding the critical role of predicates in Analytics

A custom analytic is not worth much without a valid predicate, which is essentially a rule containing a set of criteria and conditions that need to be met in order to trigger an alert.

The ability to build custom predicates is really valuable but comes with great responsibility. Any minor mistake or overly broad set of criteria can either trigger tons of alerts or heavily impact system performance on its endpoints.

Jamf Protect uses Apple’s own NSPredicate and NSExpression query language for analytics, similarly to how we can use filters to search or stream logs using the Unified Logging subsystem.

Fortunately, Jamf Protect provides a built-in query builder and documentation that help you in building predicates. This can be especially useful when you are new to building custom analytics.

Before we delve into building a custom analytic using an example use-case, here are some things to remember while you plan to build them yourself in the future:

Do’s

• Aim to be as specific as possible with the conditions in your predicate to ensure targeted and efficient results
• Prioritize the most restrictive or significant condition at the top of your predicate. This approach minimizes unnecessary evaluations. For instance:
  • If using MATCHES with a regular expression, place them towards the end of your predicate statement. This allows the predicate to filter objects first before undertaking more intensive look-ups and calculations.
• When evaluating data that is an array, consider using the IN operator instead of multiple AND or OR conditions. This method is more efficient as it avoids recalculating and re-evaluating the same data set multiple times. An example of this would be:
  • $event.type == 1 AND (($event.process.pgprocess.signingInfo.appid IN {"com.jamf.management.daemon", "com.jamfsoftware.jamf"}) OR ($event.process.responsible.signingInfo.appid IN {"com.jamf.management.daemon", "com.jamfsoftware.jamf"}))

Dont’s

• Avoid using overly broad conditions in order to preserve system performance and prevent generating too many alerts. For example:
  • An predicate for process events with only having one condition like $event.type == 1 as this would create an alert for each process being launched
  • Similar for file system events only having one condition like $event.type == 4 as this would create an alert for each file being modified
  • Avoid overly broad file paths if possible as example
    • $event.process.path BEGINSWITH "/"

Useful resources related to NSPredicate and NSExpression

• NSPredicate cheatsheet

Example custom Analytics

For practice we are going to walk through the process of building an four custom analytics using all of the above we have learned.

Each of them have their own purpose and we'll go through using various sensor types and predicate filtering

    Executable=/usr/bin/security
    Identifier=com.apple.security
    Format=Mach-O universal (x86_64 arm64e)
    CodeDirectory v=20400 size=2667 flags=0x0(none) hashes=73+7 location=embedded
    Platform identifier=15
    Signature size=4442
    Signed Time=11 Oct 2023 at 08:28:27
    Info.plist=not bound
    TeamIdentifier=not set
    Sealed Resources=none
    Internal requirements count=1 size=68

$event.type == 1 AND 
$event.process.signingInfo.appid == "com.apple.security" AND 
$event.process.commandLine CONTAINS "dump-keychain"

$event.type == 1 AND
$event.process.tty == nil AND
$event.process.signingInfo.appid == "com.apple.security" AND 
$event.process.commandLine CONTAINS "dump-keychain"

$event.file.data != $event.file.snapshotData.data

$event.path == "/etc/pam.d/sudo_local" AND
$event.file.sha256hex == "d0e654850da470b1fa823f02c4209bf6e01570c32b30b230064902947026bde4" AND
$event.type  IN {0, 4} AND
$event.file.data != $event.file.snapshotData.data

$event.process.signingInfo.appid == "com.apple.sfltool"

$event.process.signingInfo.appid == "com.apple.sfltool" AND
$event.type  == 1 AND
($event.process.commandLine CONTAINS "resetbtm" AND  $event.process.parent.signingInfo.teamid != "483DWKW443")

(($event.process.args CONTAINS[c] "deletelocalsnapshots" AND $event.process.args CONTAINS "/") OR ($event.process.args CONTAINS[c] "delete"))

$event.process.signingInfo.appid == "com.apple.timemachine.tmutil" AND
$event.type == 1 AND
$event.process.tty == nil AND
(($event.process.commandLine CONTAINS[c] "deletelocalsnapshots" AND $event.process.commandLine CONTAINS "/") OR ($event.process.commandLine CONTAINS[c] "delete"))