SIEM Integrations

Security Information and Event Management (SIEM) integrations bring Files.com activity into the monitoring platform your organization already uses. Security and operations teams can examine file transfers, authentication, and configuration changes alongside records from other systems, rather than investigating each service in isolation.

Files.com sends audit and activity logs to the remote collection endpoint over HTTP in JSON format. Setting up the integration means choosing the records your team needs, configuring the receiver, and confirming how it accepts and retains them. Use Log File Streaming instead when the receiving workflow needs files delivered at a configured interval.

SIEM Integration and Event Channels

Files.com offers two paths for sending data to a SIEM or external platform. This page covers log streaming, which batches and forwards audit logs every 60 seconds. Event Channels deliver individual operational events (SSO failures, automation failures, user lockouts, and others) to a webhook target as they occur. Use log streaming for dashboards, historical analysis, and broad audit coverage. Use Event Channels when you need real-time alerting on specific event types.

Additional SIEM Platforms

If your SIEM platform is not in the list of natively supported platforms, use the Generic SIEM Connector, listed as the SIEM (Any Provider) Connector in the SIEM integration catalog. The Generic SIEM Connector supports any SIEM, log management platform, log aggregator, or observability pipeline that receives data in JSON format over HTTP, in cloud-based or on-premises environments.

If your platform supports Splunk's HEC protocol but is not Splunk itself (such as Cribl Stream, Vector, or Mezmo), use the Splunk Compatible integration. It sends logs using the same HEC format and token authentication that Splunk uses, without requiring manual header configuration.

Log Selection

Choose the log categories available for ongoing delivery. All log types are enabled by default; adjust the selection for the records the receiving system needs. Each configured integration can have its own selection.

Sample Log Data

Some SIEM platforms, such as Microsoft Sentinel, may require you to upload sample log files to generate custom log tables as part of the schema and transformation process.

To obtain the sample log files for each log type, use the developer-reference links in Logs Available for Ongoing Delivery for the log type you need. On the landing page, you will find an Example LogType Object on the right side when REST API is the selected language. For instance, sample SFTP logs can be found under the Example SftpActionLog Object section in this link.

Copy the content of the example to your clipboard and save it locally as a file with a .json or .log extension. The resulting file is the sample log file used to configure custom log types in Microsoft Sentinel or other SIEM platforms.

Configuring Files.com for SIEM Integration

To integrate Files.com with your SIEM solution, first create or identify an HTTP destination or endpoint in your SIEM that can receive JSON data, and configure HTTP headers if required by your system. Then, in Files.com, set up the integration to include this destination and any necessary headers, and enable the required log types.

Log streaming automatically uses your site's default dedicated IP addresses when they are available; otherwise, it uses Files.com's general IP pool. There is no option to select the general pool or an additional Custom Domain's addresses. The receiver's firewall must allow the addresses used by this connection. If you also send events through an Event Channel Webhook target, its source addresses depend on the target's own Use Dedicated IPs option.

Once the configuration is complete, Files.com audit logs are forwarded to the designated SIEM endpoint at the forwarding interval.

Log Sizes, Interval, and Retries

Logs are transmitted in batches of JSON records. Your receiver must support the payload format used by the selected integration. Payload size depends on the records included.

Logs are not held until a full batch is ready; your site forwards all collected logs every 60 seconds. Files.com does not currently compress logs.

When logs cannot be delivered, the site retries every 60 seconds for five minutes. After the first 5 minutes, the site retries every 15 minutes.

Log Retention

Files.com keeps a seven-day delivery backlog for SIEM integrations. This backlog is separate from the retention period for the original log in Files.com or the copies accepted by the receiver. If the integration is paused, either manually or due to a connection failure, the logs from the last 7 days are sent in batches once the connection is restored or the integration is resumed manually. This allows you to pause the integration to perform maintenance on the receiving application without losing audit data.

The destination can impose a shorter acceptance window for older events. Check your SIEM provider's timestamp and ingestion limits before pausing delivery; Files.com's retention window does not guarantee that the receiver will accept the entire backlog.

Dashboards and Alerts

Your SIEM builds dashboards and alerts from the log types you select. Choose records for the operational question and alert thresholds for the workload's expected activity. The receiving platform owns these rules and their notifications.

Account Access

Login activity, API logs, and protocol logs support review of who connected and from which IP addresses. Compare activity with approved access patterns or the account's history. Geographic analysis requires the SIEM to interpret those addresses; a new location is a reason to review the activity, not a conclusion about who performed it.

File Activity and Delivery

FTP, SFTP, and WebDAV logs show operations and their results. Group failures by account, path, or period to identify which exchange needs attention, and compare transfer volume with that feed's expected schedule. A low-volume feed that sends one file a day needs a different alert from an active shared folder. Expectations supply explicit arrival windows when the question is whether an agreed delivery arrived.

Review Public Hosting logs separately from authenticated user transfers: public requests do not necessarily identify a Files.com user. Volume alone does not establish whether a download was authorized.

Workflow and Connection Outcomes

Sync Runs and Automation logs show workflow outcomes, while Outbound Connections records actions on remote systems. Use them together to distinguish a failed workflow from a particular remote operation that failed. A successful Files.com transfer does not establish that the receiving business application accepted the file.

For an immediate operational signal to a team or external system, Event Channels can route selected success or failure events without building a log-analysis rule for the same outcome.

Delivery Status and Troubleshooting

SIEM Events record the outcome of each attempt to deliver log data to your configured SIEM integration. Use these logs to verify that your SIEM destination is receiving data and to diagnose delivery failures.

We retain these logs for 90 days.

Delivery Results

SIEM events record each delivery attempt to an HTTP-based SIEM destination. A success event confirms that data reached the SIEM provider. A failure event indicates that the delivery did not complete and includes error details.

Delivery Failure Alerts

Site Administrators can receive email alerts for SIEM delivery failures through the SIEM failures preference in their account settings. This preference covers failure and partial-failure events.

Details Recorded in SIEM Events

Each SIEM Event entry includes the following columns.

A successful delivery confirms acceptance by the destination's HTTP endpoint. Check the receiving platform's ingestion and indexing records to establish whether the records became available for analysis; the Splunk guide explains its acknowledgment requirements.

If logs are absent, first check whether the relevant category is selected and whether Files.com records a delivery attempt for the period. Review the destination URL, authentication credentials, required headers, and receiver response. Confirm that the receiver's firewall permits Files.com's source addresses. Then check the destination's schema, timestamp acceptance, and ingestion limits. A successful HTTP response and a usable indexed record are separate results.

Use the retry and backlog rules when assessing an interruption. Event Channels can deliver SIEM failure events to the team responsible for the receiver.