• Products
    LOG COLLECTOR
    NXLog Enterprise Edition
    Full feature multi-platform log collection
    NXLog Community Edition
    Open-source free log collector
    ADD-ONS FOR NXLOG ENTERPRISE EDITION
    NXLog Add-Ons
    Integration with various software
    AGENT MANAGER FOR NXLOG ENTERPRISE EDITION
    NXLog Manager
    Manage and monitor NXLog instances
    NXLog Minder
    Hyper-scalable, API-first agent management
    DATABASE FOR NXLOG ENTERPRISE EDITION
    Raijin Database Engine
    The schemaless SQL database for storing events
    more from nxlog
    Professional Services
    Compare NXLog EE and CE
  • Downloads
    NXLog Enterprise Edition
    Full feature multi-platform log collection
    NXLog Manager
    Manage and monitor NXLog instances
    NXLog Community Edition
    Open-source free log collector
  • Solutions
    Integrations
    With SIEM, Devices, SaaS...
    Specfic OS support
    AIX, Linux, FreeBSD
    SCADA/ICS
    Energy, Oil & Gas, Transport...
    Windows Event log
    Collect locally or remotely, ..
    DNS Logging
    Enterprise-grade DNS log...
    Log Collection Modes
    Agent-based, Agentless or Cloud
    Agent Management
    Agents management and monitoring
    FIM
    File Integrity Monitoring
    macOS Logging
    ULS events, Apple System Logs ...

    By Industry

    Financial Services
    Government & Education
    Entertainment & Gambling
    Telecommunications
    Medical & Healthcare
    Military & Defense
    Law Firms & Legal Counsel
    Industrial & Manufacturing
  • Partners
    Find a Reseller
    Look for our resellers worldwide
    Technology Ecosystem
    See all our partners and integrations
    Partner Program
    Join our community of partners
    Partner Portal →
  • Resources
    Documentation
    Products guides and integrations
    Blog
    Tutorials, updates and releases
    White papers
    Datasheets, infographics and more
    Videos
    Trainings and tutorial on specific topics
    Webinars
    Community events and webinars
    Community Forum →
  • Support
  • Why Nxlog
    About Us
    Our journey, team and mission
    Customers
    Testimonials and case studies
    Careers
    We are hiring!
    Contact Us →
Log In Sign Up
Request Trial
LOG COLLECTOR
NXLog Enterprise Edition
Full feature multi-platform log collection
NXLog Community Edition
Open-source free log collector
ADD-ONS FOR NXLOG ENTERPRISE EDITION
NXLog Add-Ons
Integration with various software
AGENT MANAGER FOR NXLOG ENTERPRISE EDITION
NXLog Manager
Manage and monitor NXLog instances
NXLog Minder
Hyper-scalable, API-first agent management
DATABASE FOR NXLOG ENTERPRISE EDITION
Raijin Database Engine
The schemaless SQL database for storing events
more from nxlog
Professional Services
Compare NXLog EE and CE
NXLog Enterprise Edition
Full feature multi-platform log collection
NXLog Manager
Manage and monitor NXLog instances
NXLog Community Edition
Open-source free log collector
Integrations
With SIEM, Devices, SaaS...
Specfic OS support
AIX, Linux, FreeBSD
SCADA/ICS
Energy, Oil & Gas, Transport...
Windows Event log
Collect locally or remotely, ..
DNS Logging
Enterprise-grade DNS log...
Log Collection Modes
Agent-based, Agentless or Cloud
Agent Management
Agents management and monitoring
FIM
File Integrity Monitoring
macOS Logging
ULS events, Apple System Logs ...

By Industry

Financial Services
Government & Education
Entertainment & Gambling
Telecommunications
Medical & Healthcare
Military & Defense
Law Firms & Legal Counsel
Industrial & Manufacturing
Find a Reseller
Look for our resellers worldwide
Technology Ecosystem
See all our partners and integrations
Partner Program
Join our community of partners
Partner Portal →
Documentation
Products guides and integrations
Blog
Tutorials, updates and releases
White papers
Datasheets, infographics and more
Videos
Trainings and tutorial on specific topics
Webinars
Community events and webinars
Community Forum →
Support
About Us
Our journey, team and mission
Customers
Testimonials and case studies
Careers
We are hiring!
Contact Us →
  • Loading...
Request Trial
February 17, 2022 siemmacoslog managementos

Aggregating macOS logs for SIEM systems

By John Kirch

Share
ALL SIEM STRATEGY SECURITY ANNOUNCEMENT DEPLOYMENT COMPLIANCE COMPARISON RSS

Apple has made great strides in recent years, not only with its innovative hardware, but also with incremental improvements to its operating systems. For a number of reasons, Macs have become viable alternatives to PCs in many large corporations. Apple also continues to maintain a strong presence in institutions of higher education, as it has for decades in the US. Whether your Mac users are working on spreadsheets in accounting or they belong to creative teams developing software or marketing content, your digital assets are valuable and need to be monitored to detect any potential security threats.

Logged events generated by Macs are just as important as those logged by Windows PCs and laptops. No operating system is completely immune from malware or other security threats. Relying on the log analytics and security alerts that a SIEM system can provide has become standard practice among organizations of all sizes. Only NXLog provides an end-to-end solution for collecting, aggregating, and feeding SIEM systems with high-quality log events from systems running macOS.

Log data aggregation has become perhaps the single most important factor in scaling log collection to the demands of large enterprises. Without it, the ability to perform real-time correlation and analysis of events is impossible, which can hamper threat detection and the ability to take appropriate countermeasures in a timely manner. However, log aggregation is often performed at multiple levels and at different stages in this process. Let’s first take a look at log aggregation at the workstation or user level.

The Apple Unified Log

What’s that? It’s one of those incremental operating system improvements we just mentioned. Security relies on logging. The availability of diverse, meaningful logs is a must for a SIEM to be able to assess not only threat levels but also how, when, and where a suspicious event is happening. In the late 2010s, Apple decided that a more modern approach was needed to meet today’s more challenging demands of application and security logging.

Note
The terminology for this new logging system is still fluid. Newer articles and posts often refer to it as the Apple Unified Log (AUL). Apple’s Developer Documentation for OSLog has the subheading: "A unified logging system for the reading of historical data." The teaser for their Logging page is: "Capture telemetry from your app for debugging and performance analysis using the unified logging system." Since NXLog’s focus is on macOS, we have coined the term macOS Unified Logging System (ULS) when referring to the native integration NXLog has with this new logging facility. For the rest of this post, we will simply refer to events from the AUL as ULS events.

macOS ULS is not a hodge-podge collection of plain-text, syslog-like files generated by a handful of few operating system services as things were before ULS came along. If you are a PC person, you might look at it as Apple’s answer to Windows Event Log. Even though they share the same concept of a centralized logging facility, that’s where their similarities end. macOS ULS was designed with different goals in mind. Here are a few of the most defining goals Apple had during the planning phase:

Cross-OS functionality

The logging system should provide interoperability and common features across all Apple operating systems, not just macOS.

Aggregation of all logs

At the workstation level, all logs should be aggregated. No matter which log source an event comes from, whether it belongs to the Mac system log, audit log, kernel log, security log, application log, etc., every event can be retrieved from a common, centralized log repository. With such a centralized logging architecture, searches could reveal events from totally unrelated log sources sharing common attributes and values specific to a given security threat. Unlike Windows Event Log they are not partitioned off into different channels.

Application logs are welcome

Apple strongly encourages application developers to integrate their application’s logging and debugging into macOS ULS, providing simple tutorials on how to generate log messages from your code.

Resource efficiency

The logging should log as many events as possible while simultaneously minimizing system resource usage, compress logs, and rotate older logs.

Privacy

Events having fields known to contain private, sensitive data should hide this information prior to storage.

NXLog is the only third-party solution that can natively read and forward ULS events. Other non-ULS logs, like those from third-party apps, kernel logs, BSM auditing, etc., can be collected simultaneously with ULS events using a single agent with only minor configuration changes.

Processing logs

Now that we have a logging solution that can collect all types of Mac logs, all that’s left to do is send them to the SIEM, right? Well, yes, we could do that, but it’s probably not going to provide the results we’re looking for.

Log filtering

First of all, not every logged event is created equal. Informational events about a hostname lookup for a mail server are not going to be as valuable as a critical error logged by the kernel. You might ask, "Why does this matter if the SIEM can filter out the low-value events?" Well, this could become expensive if your SIEM service bills by data volume ingested. Also, collecting and sending thousands of relatively useless events from each and every Mac, like informational bonjour events, might lead to excessive network usage.

Event record enrichment

Second of all, macOS logs, especially ULS logs do not have any workstation identifier field, like hostname on Linux machines or Computer on Windows workstations. Without such an identifier, aggregated logs would be of limited use. Thirteen intrusion attempts in the last five minutes might sound interesting, but this information is much too general to be actionable. Was one workstation attacked 13 times? Maybe it was two Macs. Or, could it have been 13 Macs that were being attacked during the same time frame? Being able to establish the identity of a compromised device as a security risk with a high level of confidence is absolutely essential. Any additional hardware identifiers your organization might use, like "asset tag numbers", should be added to each logged event. The same holds true for large organizations comprised of hierarchical units, like in higher education: campus, college (e.g., Liberal Arts), and department (e.g., Linguistics). By enriching each event from each log source with these three new fields, campus, college, and department, your security analysts will have valuable clues to assist them in their forensic work when tracking security-related activity.

Schema normalization

Schemas are most often discussed in the context of database tables, but structured logging also uses schemas. What if we could prepare all logs on each Mac — or more broadly, on each workstation — for merging with logs from other Macs, so that when they are collected together, the overall health and metrics across your team, your business unit, or even across your entire enterprise could be measured and viewed. We’ve already discussed the former flat logs that macOS has inherited from its UNIX-based origins and how they differ from the highly structured ULS events. If we have the ability to rename event fields that collect the same type of data, we could translate information from this older schema to the newer ULS, if it has information that complements the existing ULS events.

Ideally, the best possible solution a security analyst could hope for in today’s diverse landscape of devices and operating systems are events that contain highly structured data that has been normalized to the point of being completely OS-agnostic.

Formatting structured data

One final processing step needs to be completed before most SIEMs will be able to ingest the logs it receives: formatting the structured data that has been filtered, enriched, and normalized. The log format requirements can vary from SIEM to SIEM, so it is essential that you have the ability to format your ULS events in any format a SIEM system might require.

Although JSON is one of the most popular formats for structured data, the network protocol or authentication requirements some SIEMs have can create even more requirements. Splunk is pretty easy to satisfy. ULS events can output as newline-delimited JSON (NDJSON) streamed over TCP. Microsoft Sentinel, on the other hand, has very specific authentication requirements for the HTTPS payloads it will accept, which can only be constructed as an array of comma-delimited JSON objects, not NDJSON.

NXLog can fulfill all of these requirements. It can filter out noisy logs, enrich event records, rewrite events to normalize log sources for optimal data aggregation, and format structured data in any format that a SIEM might require.

Aggregating Mac logs

As we explained from the start, ULS events are already aggregated, but only for the Mac that generated them. For any situation other than a single user working in a silo, log aggregation is a requirement, if you wish to have any benefit from your SIEM solution.

Because NXLog can enrich log events, like adding a Hostname field, which we touched on in Event record enrichment, aggregation can now be used to provide insight into which users, teams, business units, regions, are experiencing which types of threats, how often, and using which processes. Once these enriched events are ingested by your SIEM, it is possible to query for specific types of events to see which workstations might have been targeted by a known threat.

If your organization is relatively small and you do not have any need to archive logs for compliance reasons, you might be best served by having each Mac send its logs directly to the SIEM. For maintaining an archive of collected logs, or for larger organizations that might need to implement load balancing or failover, clustered relay servers would probably be recommended.

Setting up a centralized NXLog relay server

The ultimate log aggregation solution would be a cluster of NXLog agents functioning as log relays. This would minimize the number of open network connections with your SIEM system, and it would provide options for failover and load balancing, should your log traffic ever need to be scaled out by adding additionally nodes. Thanks to the NXLog agent’s small footprint and minimal resource requirements, it can run on commodity hardware and is supported on practically any modern operating system. This means even smaller organizations can afford such a robust solution. NXLog even offers a hybrid load balancing / failover solution that is easy to set up.

Why NXLog is the best choice for your logging solution

You shouldn’t treat Mac users in your organization like second-class citizens. They deserve the same protection from security threats as your Windows users. NXLog provides a platform-agnostic, end-to-end log collection solution using a robust, modular, distributed architecture that is unparalleled in its flexibility, functionally, and variety of third-party integrations.

It is the all-in-one solution: one logging tool that can rule them all, and do it all.

GET STARTED TODAY:
CONTACT US Our experts are happy to help REQUEST A FREE TRIAL Give NXLog Enterprise Edition a try GET PRICING Request a quote

NXLog Ltd. develops multi-platform log collection tools that support many different log sources, formats, transports, and integrations. The tools help administrators collect, parse, and forward logs so they can more easily respond to security issues, investigate operational problems, and analyze event data. NXLog distributes the free and open source NXLog Community Edition and offers additional features and support with the NXLog Enterprise Edition.

This document is provided for informational purposes only and is subject to change without notice. Trademarks are the properties of their respective owners.

  • log aggregation
  • macos
  • siem
  • macos logs
Share

Facebook Twitter LinkedIn Reddit Mail
Related Posts

How a centralized log collection tool can help your SIEM solutions
5 minutes | April 1, 2020
Windows Event Log collection in a nutshell
4 minutes | June 14, 2021
Log aggregation with NXLog
4 minutes | January 3, 2022

Stay connected:

Sign up

Keep up to date with our weekly digest of articles.

By clicking singing up, I agree to the use of my personal data in accordance with NXLog Privacy Policy.

Featured posts

Announcing NXLog Enterprise Edition 5.7
January 20, 2023
NXLog - 2022 in review
December 22, 2022
Need to replace syslog-ng? Changing to NXLog is easier than you think
November 23, 2022
The EU's response to cyberwarfare
November 22, 2022
Looking beyond Cybersecurity Awareness Month
November 8, 2022
GDPR compliance and log data
September 23, 2022
NXLog in an industrial control security context
August 10, 2022
Raijin vs Elasticsearch
August 9, 2022
NXLog provides native support for Google Chronicle
May 11, 2022
Aggregating macOS logs for SIEM systems
February 17, 2022
How a centralized log collection tool can help your SIEM solutions
April 1, 2020

Categories

  • SIEM
  • STRATEGY
  • SECURITY
  • ANNOUNCEMENT
  • DEPLOYMENT
  • COMPLIANCE
  • COMPARISON

Subscribe to our newsletter to get the latest updates, news, and products releases.

© Copyright 2023 NXLog Ltd.

PRIVACY POLICY TERMS OF USE

  • PRODUCTS

  • NXLOG ENTERPRISE EDITION
  • NXLOG COMMUNITY EDITION
  • NXLOG ADD-ONS
  • NXLOG MANAGER
  • NXLOG MINDER
  • RAIJIN DATABASE
  • MORE NXLOG

  • COMPARE SOLUTIONS
  • INDUSTRIES
  • INTERGRATIONS
  • FIND A RESELLER
  • PARTNER PROGRAM
  • RESOURCES

  • DOCUMENTATION
  • WHITE PAPERS
  • WEBINARS
  • TUTORIALS
  • BLOG
  • COMMUNITY FORUM
  • ABOUT US

  • WHY NXLOG
  • CUSTOMERS
  • CAREERS
  • CONTACT US
  • DOWNLOADS

  • NXLOG ENTERPRISE EDITION
  • NXLOG COMMUNITY EDITION
  • NXLOG MINDER
  • NXLOG MANAGER
  • NXLOG ADD-ONS
  • RAIJIN DATABASE