The biggest challenge when working with the external SIEM servers is to map messages existing in the system in the correct CEF/LEEF format. In order to allow administrators to have full control over how to represent FileCloud's System Alerts and Audit records in the external SIEM system a flexible mapping syntax is supported.
On this page:
SIEM Mappings - general rules
Create and access SIEM mappings files
Access WWWROOT. It is typically located at:
(later than Ubuntu 14.04)
(earlier than Ubuntu 14.04)
Navigate to the following directory:
It contains the following files:
These files store mappings and mapping samples for audit and system alert.
- To enable FileCloud to convert audit entries to valid SIEM messages edit auditmap.php.
- To enable FileCloud to convert FileCloud's System Alerts to valid SIEM messages edit systemalertsmap.php.
- Samples are provided in auditmap-sample.php and systemalertsmap-sample.php.
Mappings are stored in the .php file, so they have to follow all PHP syntax rules as well as internal mappings rules and syntax. To validate all mappings, navigate to Settings > Third Party Integrations > SIEM and click on Validate mappings.
SIEM mapping format
A sample SIEM mapping is a PHP array entry, which itself is an array. It contains the following fields:
id (required) - identifies the SystemAlert / Audit entry this map refers to.
Note that it can be a string literal that matches the audit operation name or one of the SiemArea values available in FileCloud, an array of values, or a wildcard '*' that specifies that the mapping is applied to all audit entries/system alerts.
prefilter (optional) - A collection of preconditions that an event has to meet in order to be processed and sent to the SIEM system. It is an array of filters, where each filter has the following format: property => value
- property is a valid property available for the Audit/System Alert record
- value is a value that has to be matched in order to process the Audit / System Alert record, i.e.
specifies that only System Alerts with the Meltdown criticality level would be sent to the SIEM server.
map (Required) - specifies the actual mapping between the FileCloud object being processed and the SIEM-formatted message that will be sent to the SIEM server. SIEM object to contain the following four fields:
- eventClass - class of the event in the SIEM system.
- eventName - The name of the event.
- severity - this is a SIEM side severity, which is a number from the 1-10 range.
- extension - a collection (array) of additional key-value pairs that will be stored in the SIEM system (i.e. the user that performed the action, IP address of the request, etc.). The key can be any arbitrary string.
To resolve mappings, provide values in any of the following ways:
As a literal value (string or number)
As a property binding that resolves the value with the actual value provided by the FileCloud audit system alert being processed:
Properties should appear on the right-hand side of the arrow operator (=>). The property name must be prefixed with a dollar sign ($). Properties can take one of the following values:
A standalone value - '$property'
An array of values of an object with properties. The following syntax can be used to access any of the values: '$array.field' or '$object.field', for example, '$request.filename'. This can be applied recursively if the internal field is also an array or object, for example, '$response.meta.type'.
- As a chain of fallback properties ('$property1 > $property2.field > $property3') - the value is resolved to the first non-empty property value. For example, the following syntax is resolved to filename if present or to the $request.fname otherwise: 'fname' => '$filename > $request.fname'. This allows the admin to provide more generic rules.
As a method call:
NOTE: Users can create and use their own methods here. The first parameter is the PHP callback (class, method name) and the second parameter is the array of values (optional) that is processed by that callback. Parameters can be set to literal values or runtime-resolvable properties as described earlier. In FileCloud 19.2 getSysAlertSeverity is the only method available out of the box. It assigns internal System Alerts a severity of 1-10 as required by SIEM integration in the following way:
- Critical: 7
- Warning: 4
- Information: 1
Properties listed below can be used in both System Alerts and Audit mappings.
|who||Author of the operation||Name of the user or process that has triggered the operation|
|IP Address||A regular IPv4 address|
Audit stores information about actions being performed within the system. Currently, audit stores information about 200+ unique operations being performed within FileCloud. Each Audit record contains some generic information, shared with the System Alerts properties (see Shared Properties, above), common for each audit entry, and some unique properties, stored only for a group of actions.
Shared Audit Properties
The full request payload provided as a collection of key-value pairs that can be extracted in the mapping. Each operation carries a unique request.
The request can be mapped as a full object, and its info will be sent to the SIEM server as a string.
Each field can also be sent individually if provided in the mapping:
Similar to the request, the response provides a collection of key-value pairs that can be extracted in the mapping or sent as a string.
Each operation has a different response, so it is better to use this for dedicated rules.
NOTE: Responses are not stored in audit by default, and they have to be enabled in Admin > Settings > Admin (Audit Settings section) > Audit Logging Level (FULL),
This is not recommended for production as it may affect performance and usually is not needed for auditing.
|notes||Context of the operation||This field provides the most important information about each operation. The content is unique for each operation.|
|userAgent||The User-Agent that triggered the operation||NOTE: Web browser is used as a generic user-agent for all web browsers.|
|userName||Name of the user that triggered the operation|
|operation||Name of the operation that was triggered|
|resultCode||Result of the operation|
1 - the operation was performed successfully (for example, login attempt was successful, a file was deleted)
0 - operation failed (for example, login was not possible, a file was not deleted due to invalid permissions)
|recordId||A MongoDB id of the audit entry||This is a MongoDB ObjectId|
|hostname||A name of the host||The name of the current host. This allows SIEM to differentiate tenants.|
Operation-specific Audit Properties
|auditArea||Provides information about the system area of the operation||Name of the system area|
Currently only supported for operations from the following groups:
|Additional information about the operation target||Carries additional information about the operations such as the name of the workflow or the id of the retention policy that was updated||Available only when the auditArea field is present|
|bandwidth||Information about the size of the file||File size in bytes|
Available for the following operations:
|realpath||File or folder realpath||FileCloud's original location of the file/folder, for example. /johndoe/document/internal/doc.txt|
Available only for retention-related and dlp operations
|metadata||A list of non-empty, custom attributes assigned to the file or folder||Any non-empty attributes assigned by the Custom metadata sets as a result of the Smart Classification rule|
The following operations are supported:
|deviceInfo||Name of the client application||Name of the application, i.e. FileCloud Drive|
Any operation that is performed by one of the client apps: Drive or Sync
The following shows sample mappings for the most common operations:
System Alert mappings
FileCloud allows admins to create mappings for System Alerts generated by the system due to unexpected or unwanted behaviors. System Alert mappings contain properties that can be sent to the SIEM server or logged in the syslog for further processing.
|siemArea||System area where the alert was raised||One of the following values:|
|level||System alert critical level|
One of the following values:
|type||Type of system alert|
One of the following values:
|username||The user whose actions raised the alert|
|alertContext||Additional information, related to the alert|
Various contexts, depending on the Alert.
file - filename for the File version deletion operation
filePath - file location for the Infected file
fileName - file name for the Infected file