SECURITY AUDITING ON MODERN OPERATING SYSTEMS NXLog Ltd. 2020-07-01 14:54:13 UTC
SECURITY AUDITING ON MODERN
OPERATING SYSTEMSNXLog Ltd.
2020-07-01 14:54:13 UTC
Audit logging is important for maintaining security and investigating incidents, and is
required by many cybersecurity standards. Most operating systems have a native
auditing system available for this purpose.
About security event auditingAuditing systems in modern operating systems collect detailed information about security-related events.
The audit or security logs generated by an auditing system facilitate identification of attempted attacks,
security policy improvement, security incident investigation, and review by auditors. Logging of security
events is required by ISO/IEC 27001,[1] the NIST Cybersecurity Framework (CSF),[2] various Common Criteria
protection profiles,[3] and many other cybersecurity standards and guidelines.[4]
Note that an auditing system does not provide improved security directly. It is the responsibility of an
operating system’s security policy to specify whether an action should be allowed or denied. Meanwhile,
the auditing system is responsible for keeping a detailed record showing how the security policy was
applied. In most cases, an audit record will include a success or failure status along with any relevant
information such as a username. An audit policy specifies which attempted action and status combinations
should be logged, allowing administrators to reduce auditing scope to the security events that are
considered important for the organization. For example, an audit policy may include only successful user
login events but include all attempts to access a restricted resource (successful or not).
Once an auditing system is configured and enabled, the resulting audit logs should be stored in a secure
location and retained for a period of time, so they are available for any audits or investigations that may be
required. In some cases it may be necessary to forward audit logs to another system with higher security,
perhaps even at a remote location.
Native auditing systemsMost modern operating systems have some form of audit system available, but the functionality,
configuration, and audit log formats vary. Generally, an auditing system has a kernel component and
various user space utilities. The kernel portion watches for system calls and generates those events that are
specified by the audit policy. User space utilities may be available for functionality such as enabling or
disabling auditing, configuring audit policy, collecting events from the kernel, filtering events, or creating
reports for administrators.
Implementing an organization-wide auditing policy requires working with a variety of auditing systems,
depending on which operating systems are deployed in the organization’s network.
Linux
The Linux Audit system is available with most Linux-based operating systems. The Audit system can log
many different types of events, including file and network accesses, system calls, failed logins, and
commands run by users. It is composed of a kernel component that generates events, an Audit daemon
(auditd) for collecting events, and several other tools for configuring auditing, relaying events, and
reading the log files.[5] The system is configured with control rules, which specify the system’s behavior;
file system rules, which audit access to a file or directory; and system call rules, which log system calls
made by specified programs.[6]
By default, auditd collects events from the kernel and writes them in a key-value pair format to
/var/log/audit/audit.log.[7] The ausearch and aureport commands can be used to search audit
records and generate audit reports, respectively. For more information about the Linux Audit system,
see the Red Hat Security Guide, as well as the audit(8) manual page and other pages listed there.
Microsoft Windows
Windows security auditing provides two groups of policy settings for configuring native auditing on
Windows: "basic" and "advanced". The two groups are considered incompatible in practice; if advanced
settings are used, it is recommended that a Group Policy setting be enabled to force the basic settings to
be ignored.[8] The current local audit policy can be displayed and manipulated with the auditpol
command. Audit records are written to the Security channel of the Windows Event Log.
The basic audit policy settings, available since Windows 2000,[9] include nine settings for auditing. Each
setting controls a group of related auditable events. Settings are available for a range of events
including logon activity, account management, object access, policy changes, and privilege use.[10] These
settings are configured using the Local Security Policy snap-in (secpol.msc) under Local
Policies\Audit Policy or via Group Policy under Computer Configuration\Windows Settings\Security
Settings\Audit Policy.[11] For more information, see Basic security audit policies on Microsoft Docs.
The advanced settings, introduced in Windows Vista and Windows Server 2008,[9] offer more detailed
policy configuration, with more than fifty settings in ten categories. These settings overlap with the
basic settings and provide more granularity for specifying auditable events. As with the basic settings,
each advanced setting controls a group of events. These settings are found under Computer
Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System
Audit Policies in Group Policy.[12] For more information, see Advanced security audit policies on
Microsoft Docs.
The Sysmon utility, included in Microsoft’s Sysinternals toolset, is a Windows system service and device
driver that monitors and logs system activity to the Windows Event Log. Sysmon logs events and event
information beyond what is possible with standard security auditing. Events include process creations,
network connections, driver loading, raw filesystem reading, changes in file creation timestamps, and
early boot process activity. Additional logged details include process command lines and hashes;
process and session identifiers for event correlation; and for network connections, parent processes, IP
addresses, and port numbers. An XML configuration system allows the administrator to specify the
events to be logged with detailed rules for filtering events. Starting with Windows Vista, Sysmon events
are written to the Microsoft-Windows-Sysmon/Operational channel.[13] For more information, see
Sysmon on Microsoft Docs.
Apple macOS, FreeBSD, and Oracle Solaris
These operating systems each implement Sun’s Basic Security Module (BSM) auditing system.[14] The
BSM auditing system can be used to audit a variety of events, including authentication, logins, program
execution, inter-process communication (IPC), file activity, and network access.[15] It has a kernel
component for generating events, a user space daemon (auditd) for collecting the events, and several
other utilities for working with the audit logs (referred to as "audit trails"). Auditable events are
grouped into event classes, such as the fc class for file creations. The audit policy is configured by
listing these classes (with optional prefixes to select success/failure events) in the system-wide policy
and in any per-user policies that may be required.[15]
The audit daemon writes audit trails to files in /var/audit/ using the BSM binary format. A stream of
audit records, useful for live monitoring, is also available through the /dev/auditpipe device.[16] In
both cases, the auditreduce command can be used to filter events and praudit will parse the audit
trail and dump it to plain text. For more information about BSM auditing, see the NIST Guide to
Securing Apple OS X 10.10 Systems for IT Professionals (section 6.4.2), the Security Event Auditing
chapter in the FreeBSD Handbook, and Solaris Auditing in the System Administration Guide.
IBM AIX
The AIX auditing subsystem logs a wide array of "security-relevant occurrences": process and file
activity, network connections, user account management, audit system administration, filesystem
volume changes, mail delivery configuration, job scheduling, and so on.[17] The system has a kernel
audit logger and several commands for controlling the audit system and processing audit logs. Audit
policy is based on a per-process or per-object scope. With per-process auditing, auditable events are
selected and grouped into classes, which are then assigned to users. With per-object auditing, events
are assigned to file objects.[18]
Output can be written to binary audit files for long-term storage (BIN mode), to a circular buffer that
can be read from /dev/audit (STREAM mode), or both.[19] For either mode, processing of audit data is
done with a chain of commands that read, filter, compress, and convert the audit records as required.[18]
[20] For more information about AIX auditing, see the Auditing overview topic in IBM’s AIX 7.2
documentation and AIX Auditing Best Practices on IBM Support.
Auditable system events may also be generated outside of a platform’s native auditing system. For
example, PAM authentication events on Linux are logged to Syslog, and audit events for a particular
application may be written to a separate Windows Event Log channel.
Using NXLog to collect audit eventsNXLog Enterprise Edition is a flexible, high-performance logging solution that offers a wide range of
functionality for collecting audit data on multiple platforms. All log data is collected and processed using a
structured log format, where each event is comprised of a set of fields. This reduces or eliminates the need
for event parsing and allows event data to be collected in a unified way across different audit log sources.[21]
NXLog includes native auditing support for several operating systems, a unique feature not found in
competing products. Native auditing improves performance and simplifies administration by eliminating
the need for an audit daemon—events are collected directly from the kernel as they are generated.
Without native auditing, events are written to disk by the audit daemon, read from disk by the logging
agent, and then parsed.
Linux Audit system
NXLog’s im_linuxaudit module collects Audit events using the Linux kernel’s audit interfaces as a local
agent—auditd is not required. This module also performs Audit system configuration, with Audit rules
specified in the NXLog configuration or in a separate file.
For cases where direct Audit system configuration and collection is not feasible, audit events can
instead be collected via Syslog or by reading from the local Audit log file written by auditd.
Alternatively, for agentless audit log collection, NXLog can be configured to accept events forwarded by
the Audit dispatcher (audispd).
See the Linux Audit System chapter in the NXLog User Guide for detailed information and examples.
Windows Event Log
Audit events generated by the Windows security auditing system, and audit events from Sysmon, can
be read from the Windows Event Log. With the im_msvistalog module, NXLog supports collection either
as a local agent or remotely using MSRPC.[22] The im_wseventing module is also available for collecting
events remotely from hosts with Windows Event Forwarding (WEF) configured.
For more information, see Collecting Event Log Data and Sysmon in the NXLog User Guide.
Basic Security Module (BSM) auditing
For collecting events from the BSM auditing system on FreeBSD and macOS, the im_bsm module
supports reading directly from the /dev/auditpipe device. The audit daemon is not required.
Alternatively, or for Solaris where the auditpipe device is not available, the xm_bsm module parses
events after they have been written to file by the audit daemon.
AIX auditing
For auditing on AIX, NXLog’s im_aixaudit module reads directly from the /dev/audit device and
parses the data. No system audit commands are needed for processing audit records; NXLog’s
processing features can be used to implement any filtering, compression, or conversion that may be
required, whether at the local agent or a remote agent (if logs are forwarded).
For cases where AIX audit events are already written to disk, the xm_aixaudit module can be used to
parse events in binary format.
In addition to the auditing systems above, NXLog offers many other features for meeting an organization’s
auditing requirements. Any auditable system events written to regular system logs can be collected
separately. Functionality is available for collecting logs generated by Exchange administrator and mailbox
auditing, SQL Server Auditing, and a variety of other applications, services, and enterprise hardware. File
integrity monitoring and Windows Registry monitoring can be implemented as an additional layer of
security. Once audit data has been collected, NXLog can implement retention policies and/or forward log
data to an event management product or service for monitoring and analysis.
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.
[1] ISO/IEC 27001:2013, International Organization for Standardization (ISO), 2013-10 (reviewed in 2019)
[2] Framework for Improving Critical Infrastructure Cybersecurity (category DE.CM), U.S. National Institute of Standards and
Technology (NIST) Cybersecurity Framework, version 1.1, published 2018-04-16
[3] See the Common Criteria Protection Profiles, including the General Purpose Operating Systems protection profile
[4] See the NIST SP 800-92 "Guide to Computer Security Log Management", section 2.2
[5] Red Hat Enterprise Linux Security Guide: System Auditing, Red Hat, retrieved 2020-06-30
[6] Red Hat Enterprise Linux Security Guide: Defining Audit Rules, Red Hat, retrieved 2020-06-30
[7] Red Hat Enterprise Linux Security Guide: Understanding Audit Log Files, Red Hat, retrieved 2020-06-30
[8] Advanced security auditing FAQ: "What is the interaction between basic audit policy settings and advanced audit policy settings?",
Microsoft Docs, retrieved 2020-06-30
[9] Advanced security auditing FAQ: "What are the differences in auditing functionality between versions of Windows?", Microsoft
Docs, retrieved 2020-06-30
[10] Basic security audit policies, Microsoft Docs, retrieved 2020-06-30
[11] Create a basic audit policy for an event category, Microsoft Docs, retrieved 2020-06-30
[12] Advanced security audit policies, Microsoft Docs, retrieved 2020-06-30
[13] Sysmon, Microsoft Docs, retrieved 2020-06-30
[14] Security Event Auditing, FreeBSD Handbook, retrieved 2020-06-30
[15] Audit Configuration, FreeBSD Handbook, retrieved 2020-06-30
[16] Working with Audit Trails, FreeBSD Handbook, retrieved 2020-06-30
[17] Audit events, IBM Knowledge Center, retrieved 2020-06-30
[18] Audit logger configuration, IBM Knowledge Center, retrieved 2020-06-30
[19] Auditing subsystem, IBM Knowledge Center, retrieved 2020-06-30
[20] Setting up auditing, IBM Knowledge Center, retrieved 2020-06-30
[21] See Event Records and Fields in the NXLog User Guide
[22] MSRPC: Microsoft Remote Procedure Call