Collect Linux auditd and AIX systems logs

This parser handles Linux audit logs in SYSLOG format, transforming them into UDM. It processes both JSON-formatted and plain text log messages, extracting fields using grok, XML parsing, and JSON parsing techniques, and mapping them to appropriate UDM fields based on the event type. The parser also handles specific audit log formats from AIX systems and enriches the UDM with additional fields like security_result and intermediary details.

Before you begin

• Ensure that you have a Google Security Operations instance.
• Ensure that you have root access to the Auditd host.
• Ensure that you installed rsyslog on the Auditd host.
• Ensure that you have a Windows 2012 SP2 or later or Linux host with systemd.
• If running behind a proxy, ensure that the firewall ports are open.

Get Google SecOps ingestion authentication file

1. Sign in to the Google SecOps console.
2. Go to SIEM Settings > Collection Agents.
3. Download the Ingestion Authentication File.

Get Google SecOps customer ID

1. Sign in to the Google SecOps console.
2. Go to SIEM Settings > Profile.
3. Copy and save the Customer ID from the Organization Details section.

Install Bindplane Agent

1. For Windows installation, run the following script:
   msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet
2. For Linux installation, run the following script:
   sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh
3. Additional installation options can be found in this installation guide.

Configure Bindplane Agent to ingest Syslog and send to Google SecOps

1. Access the machine where Bindplane is installed.

2. Edit the config.yaml file as follows:

   receivers:
     tcplog:
       # Replace the below port <54525> and IP <0.0.0.0> with your specific values
       listen_address: "0.0.0.0:54525" 
   
   exporters:
       chronicle/chronicle_w_labels:
           compression: gzip
           # Adjust the creds location below according the placement of the credentials file you downloaded
           creds: '{ json file for creds }'
           # Replace <customer_id> below with your actual ID that you copied
           customer_id: <customer_id>
           endpoint: malachiteingestion-pa.googleapis.com
           # You can apply ingestion labels below as preferred
           ingestion_labels:
           log_type: SYSLOG
           namespace: auditd
           raw_log_field: body
   service:
       pipelines:
           logs/source0__chronicle_w_labels-0:
               receivers:
                   - tcplog
               exporters:
                   - chronicle/chronicle_w_labels
   

3. Restart Bindplane Agent to apply the changes using the following command: sudo systemctl bindplane restart

Exporting Syslog from Auditd

1. Access the machine from which you want to export audit logs.

2. Open the Auditd configuration file (typically located at /etc/audit/auditd.conf).

   sudo vi /etc/audit/auditd.conf
   

3. Find or add the following line(s) to configure auditd:

   active = yes
   output = syslog
   log_format = ENRICHED
   dispatcher = /sbin/audispd
   

Optional: Specify Syslog Facility: Add or modify the following line in auditd.conf:

```none
syslog_facility = LOG_AUTHPRIV
```

1. Open audispd configuration file (typically located at /etc/audisp/plugins.d/syslog.conf):

   sudo vi /etc/audisp/plugins.d/syslog.conf
   

2. Find or add the following line(s) to configure audispd:

   active = yes
   direction = out
   path = builtin_syslog
   type = builtin
   args = LOG_INFO
   format = string
   

3. Restart Auditd service to apply the changes:

   sudo systemctl restart auditd
   

4. Use a tool like tail to monitor the syslog and verify that Auditd logs are being sent:

   tail -f /var/log/syslog | grep auditd # Follow syslog and filter for auditd messages (path may vary depending on your system)
   

5. Edit the rsyslog.conf or create a custom configuration:

   sudo vi /etc/rsyslog.d/50-audit-forwarding.conf
   

6. Add a rule to forward logs:

   • if $programname == 'auditd' then @@<Bindplane_Agent>:<Bindplane_Port>
   • Use @for UDP or @@ for TCP
   • Replace <BindPlane_Agent> with your server's IP/hostname.
   • Replace <BindPlane_Port> with your server's Port.

7. Restart rsyslog service to apply the changes:

   sudo systemctl restart rsyslog
   

UDM mapping table

UDM mapping delta reference

On September 23, 2025, Google SecOps released a new version of the Okta parser, which includes significant changes to the mapping of Okta log fields to UDM fields and changes to the mapping of event types.

Log-field mapping delta

The following table lists the mapping delta for Okta log-to-UDM fields exposed prior to September 23, 2025 and subsequently (listed in the Old mapping and Current mapping columns, respectively).

Event-type mapping delta

Multiple events that were classified before as generic event are now properly classified with meaningful event types.

The following table lists the delta for the handling of Okta event types prior to September 23, 2025 and subsequently (listed in the Old event_type and Current event-type columns respectively).

Additional changes

• Removed duplicate mapping of res from security_result.description. It's captured in security_result.action_details.
• Removed unnecessary auditd_msg_data from additional fields.
• Removed unnecessary auditd_msg_data from security_result.summary.
• When type=ADD_USER, removed duplicate mapping of acct to target.user.display_name. It's already mapped under target.user.userid.
• Removed duplicate mapping of comm from principal.process.command_line and principal.process.file.names. It's captured in principal.application.
• Removed duplicate mapping of target.hostname when the value is there in principal.
• Removed unnecessary hard-coded mapping of target.resource.type to SETTING.
• Removed about labels mappings since it is deprecated.
• Corrected mapping: IP's now route to principal.ip, not principal.hostname.
• Fixed the repetition of events being generated.

Need more help? Get answers from Community members and Google SecOps professionals.