Adding OctoXLabs CAASM via Syslog

Purpose

This guide explains how to forward OctoXLabs CAASM (Cyber Asset Attack Surface Management) activity logs to Logsign USO over syslog and what Logsign does with them. The integration reads the OctoXLabs activity records that describe who did what on the OctoXLabs console: successful and failed logins, OTP verification and other user actions such as creating, updating or deleting users.

Prerequisites

• An OctoXLabs administrator account that is allowed to change the syslog forwarding settings.
• Network connectivity from the OctoXLabs server to the Logsign USO collector on your syslog port (TCP or UDP 514 by default).
• The Logsign user account that will add the data source needs access to Settings > Data Collection.
• The OctoXLabs CAASM plugin on the Logsign appliance. If OctoXLabs does not appear in the vendor list in Step 2, contact Logsign support to get the plugin package for your version.

Step 1: Forward OctoXLabs activity logs to Logsign

OctoXLabs sends its activity logs through its own syslog forwarding settings. Menu names can differ between OctoXLabs releases, so use the OctoXLabs documentation for your version to find the syslog server settings. Add the IP address of the Logsign USO collector and the syslog port there, and keep the default OctoXLabs message format. Logsign recognizes a message only when it starts with the octoxlabs tag followed by the timestamp= field, so do not add a custom prefix or template on the OctoXLabs side.

Step 2: Add the data source in Logsign USO

Open the Logsign USO web interface and click + Device under Settings > Data Collection. Choose Syslog as the collection method, select OctoXLabs as the vendor and CAASM as the product, and enter the IP address of the OctoXLabs server as the host. Click Save. Once OctoXLabs starts sending, events appear under Search.

Supported message format

Every OctoXLabs activity message is a list of key=value pairs separated by commas. The message carries the event time, the client IP address, the API path, the browser user agent, the OctoXLabs user, the action and, when the action concerns an object, its type and ID. The last field, data_summary, is a block in braces with extra details such as the account name and the failure reason. Two typical events look like this (anonymized):

octoxlabs 1 - timestamp=2026-10-20T12:23:20.880175+00:00, ip=192.0.2.10, path="/api/token/ldap", user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64)", user=anonymous, action=logged in unsuccessfully, data_summary={username=user.one, reason=invalid_credentials}

octoxlabs 1 - timestamp=2026-10-20T12:23:18.726298+00:00, ip=192.0.2.10, path="/api/token/ldap", user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64)", user=system, action=logged in successfully, object_type=user, object_id=10, data_summary={username=user.two}

Notes and limits

• Time.Generated keeps the clock value written in the message. The fraction of a second and the time zone offset are dropped and not converted, so an OctoXLabs server that logs in UTC produces UTC values in Time.Generated.
• Only the three actions in the table above have their own classification. Every other action stays on Identity / Other / Info (VendorID 999). Use Event.Action to filter them.
• The event severity comes from the classification table, not from the syslog priority of the incoming message.
• Values such as None or - are treated as empty and do not fill the related Logsign field.

Verification

After both sides are saved, one successful login and one failed login on the OctoXLabs console are enough to check the integration end to end.

• In Logsign USO, open Settings > Data Collection and confirm that the OctoXLabs source is receiving data.
• Log in to the OctoXLabs console. In Search, look for events with Vendor OctoXLabs and Product CAASM. The login should appear with EventMap Identity / User / Login and your OctoXLabs user name in Source.UserName.
• Enter a wrong password once. That attempt should appear as Identity / User / Deny with severity warning and the failure reason in Event.Reason.
• If the source is receiving data but no events show Vendor OctoXLabs, the messages are not in a format this integration recognizes. Check that OctoXLabs is sending its default activity log format and that nothing on the way rewrites the message.