Microsoft Sentinel
The Files.com integration with Microsoft Sentinel uses Sentinel's Logs Ingestion API in Azure Monitor to efficiently transfer Files.com logs into your Sentinel environment. The forwarded logs are stored by default in Azure Monitor's Log Analytics, which serves as the foundation of the Microsoft Sentinel workspace. From there, you can access the logs and use Kusto Query Language (KQL) to execute queries for threat detection and network activity monitoring.
This integration ensures that your data is consistently updated for real-time analysis. You have the flexibility to configure the integration to send various types of log data to Sentinel, enhancing your capability to monitor, analyze, and respond to security events with greater accuracy and speed.
Getting Started with Microsoft Sentinel Integration
To configure the Files.com SIEM integration with Microsoft Sentinel, you need the Destination URL, Stream name, DCR Immutable ID, Tenant ID, Client ID, and Secret from your Azure environment. To obtain these, follow the steps from the Microsoft Azure Sentinel tutorial provided below.
Start by configuring the Azure application registration to authenticate against the API by following the instructions. Note the Application (client) ID, Directory (tenant) ID, and Secret Value to use in Files.com.
Next, create a Data Collection Endpoint (DCE). Note the Logs ingestion URL, which will be used as the Destination URL in Files.com.
Add a custom log table by following the instructions. Avoid using the sample data or transform code provided in the Microsoft article. Instead, follow the steps outlined below.
Obtain the sample log data for each log type from the Developers.files.com documentation. For example, sample SFTP logs can be found at this link under Example SftpActionLog Object on the right side. Save the copied sample log locally as a file with a .json or .log extension.
After saving the file locally, upload it by selecting New custom log (DCR-based) to create a custom log table in the Log Analytics workspace.
After upload, you may need to use the Transformation Editor to resolve warnings related to timestamp conversion for the TimeGenerated column, as all log tables within Azure Monitor Logs must have a TimeGenerated column populated with the event's timestamp.
Run the KQL query below in the Transformation Editor to add the TimeGenerated column to the output, and then click Apply to save the transformation.
source
| extend TimeGenerated = todatetime(timestamp)
After generating the custom log table, follow these instructions to collect information from a Data Collection Rule (DCR). Note down the Stream name, DCR Immutable ID to use in Files.com.
Lastly, assign permissions to the DCR by following these instructions.
Files.com Stream Names
Files.com uses predefined stream names that follow industry best practices for log routing. Each log type corresponds to a specific stream name that should be used when configuring your custom log tables in Azure Sentinel:
| Log Type | Stream Name |
|---|---|
| Settings Changes Log | filescom_settings_change_log |
| SFTP Logs | filescom_sftp_action_log |
| FTP Logs | filescom_ftp_action_log |
| WebDAV Logs | filescom_web_dav_action_log |
| Sync Logs | filescom_sync_log |
| Outbound Connections Log | filescom_outbound_connection_log |
| Automations Log | filescom_automation_log |
| API Log | filescom_api_request_log |
| Public Hosting Logs | filescom_public_hosting_request_log |
| Outbound Emails Log | filescom_email_log |
| ExaVault API Log | filescom_exavault_api_request_log |
| Test Log | filescom_test_log |
Test Log is used for connection testing when creating a new connection.
You will need to create a separate custom log table in Azure Sentinel for each log type you wish to receive, using the corresponding stream name from the table above.
Configuring Files.com for Microsoft Sentinel Integration
After configuring the Log Ingestion API in Azure Monitor by following the steps outlined in the previous section, set up the integration in Files.com as detailed in the table below.
| Field | Details |
|---|---|
| Name | Integration name for your records |
| Destination URL | Logs ingestion URL collected from Data Collection Endpoint |
| Stream name | Custom Log Table Name |
| DCR Immutable ID | DCR ID |
| Azure OAuth Client Credentials Tenant ID | Tenant ID |
| Azure OAuth Client Credentials Client ID | Client ID |
| Azure OAuth Client Credentials Client Secret | Secret Value |
You can configure additional headers by specifying the Header Name and Header Value in the Key and Value fields, respectively, if you need to pass extra headers to your SIEM setup.
Choosing Log Types to Forward to Microsoft Sentinel
You can select multiple log types to forward to your Microsoft Sentinel instance. Each log type will be routed to its corresponding custom log table based on the predefined stream names listed above. Ensure that you have created the appropriate custom log tables in Azure Sentinel for each log type you wish to receive.
Select which types of logs are forwarded to your Microsoft Sentinel instance. By default, all log types are enabled, but you can customize this selection based on your monitoring requirements. Refer to the Log Types section to review the available options for forwarding logs to your Microsoft Sentinel platform.
Troubleshooting
If you encounter any issues with forwarding or receiving logs in Microsoft Sentinel, start by verifying that all configuration steps are performed according to Microsoft's documentation and that all values collected in the Files.com from are accurate.
If you are still experiencing issues, check for network connectivity issues or firewall rules that may be blocking the communication between Files.com and your Microsoft Sentinel environment. For additional insights, review any SIEM-related logs under External Logs by selecting "SIEM" as the Event Type. These logs may help identify any issues with the log forwarding process. If the problem persists, refer to Microsoft's troubleshooting documentation for further troubleshooting steps.