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.
