Configuring event sources

This section provides information on configuring the receipt of events from various sources.

Configuring receipt of Auditd events

KUMA lets you monitor and audit the Auditd events on Linux devices.

Before configuring event receiving, make sure to create a new KUMA collector for the Auditd events.

Configuring the receipt of Auditd events proceeds in stages:

1. Configuring the KUMA collector for receiving Auditd events.
2. Configuring the event source server.
3. Verifying receipt of Auditd events by the KUMA collector.

   You can verify that the Auditd event source server is configured correctly by searching for related events in the KUMA Console.

Configuring the KUMA collector for receiving Auditd events

At the Transport step, make the Auditd option active.

After creating a collector, in order to configure event receiving using rsyslog, you must install a collector on the network infrastructure server intended for receiving events.

For details on installing the KUMA collector, refer to the Installing collector in the network infrastructure section.

Configuring the event source server

The rsyslog service is used to transmit events from the server to the KUMA collector.

To configure transmission of events from the server to the collector:

1. Make sure that the rsyslog service is installed on the event source server. For this purpose, execute the following command:

   systemctl status rsyslog.service

   If the rsyslog service is not installed on the server, install it by executing the following command:

   yum install rsyslog

   systemctl enable rsyslog.service

   systemctl start rsyslog.service

2. Edit the audit.service configuration file /etc/audit/auditd.conf and change the value of the name_format parameter to NONE:

   name_format=NONE

   After editing the settings, restart the auditd service:

   sudo systemctl restart auditd.service

3. In the /etc/rsyslog.d directory, create the audit.conf file with the following content, depending on your protocol:
   • To send events over TCP:

     $ModLoad imfile

     $InputFileName /var/log/audit/audit.log

     $InputFileTag tag_audit_log:

     $InputFileStateFile audit_log

     $InputFileSeverity info

     $InputFileFacility local6

     $InputRunFileMonitor

     *.* @@<KUMA collector IP address>:<KUMA collector port>

     For example:

     *.* @@192.1.3.4:5858

   • To send events over UDP:

     $ModLoad imfile

     $InputFileName /var/log/audit/audit.log

     $InputFileTag tag_audit_log:

     $InputFileStateFile audit_log

     $InputFileSeverity info

     $InputFileFacility local6

     $InputRunFileMonitor

     template(name="AuditFormat" type="string" string="<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag% %msg%\n")

     *.* @<KUMA collector IP address>:<KUMA collector port>

     For example:

     *.* @192.1.3.4:5858;AuditFormat

4. Save the changes to the audit.conf file.
5. Restart the rsyslog service by executing the following command:

   systemctl restart rsyslog.service

The event source server is configured. Data about events is transmitted from the server to the KUMA collector.

Configuring receipt of KATA/EDR events

You can configure the receipt of Kaspersky Anti Targeted Attack Platform events in the KUMA

SIEM system

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

Before configuring event receipt, make sure to create a KUMA collector for the KATA/EDR events.

When creating a collector in the KUMA Console, make sure that the port number matches the port specified in step 4c of Configuring export of Kaspersky Anti Targeted Attack Platform events to KUMA, and that the connector type corresponds to the type specified in step 4d.

To receive Kaspersky Anti Targeted Attack Platform events using Syslog, in the collector Installation wizard, at the Event parsing step, select the [OOTB] KATA normalizer.

Configuring the receipt of KATA/EDR events proceeds in stages:

1. Configuring the forwarding of KATA/EDR events
2. Installing the KUMA collector in the network infrastructure
3. Verifying receipt of KATA/EDR events in the KUMA collector

   You can verify that the KATA/EDR event source server is configured correctly by searching for related events in the KUMA Console. Kaspersky Anti Targeted Attack Platform events are displayed as KATA in the table with search results.

Configuring export of KATA/EDR events to KUMA

To configure export of events from Kaspersky Anti Targeted Attack Platform to KUMA:

1. In a browser on any computer with access to the Central Node server, enter the IP address of the server hosting the Central Node component.

   A window for entering Kaspersky Anti Targeted Attack Platform user credentials opens.

2. In the user credentials entry window, select the Local administrator check box and enter the Administrator credentials.
3. Go to the Settings → SIEM system section.
4. Specify the following settings:
   1. Select the Activity log and Detections check boxes.
   2. In the Host/IP field, enter the IP address or host name of the KUMA collector.
   3. In the Port field, specify the port number to connect to the KUMA collector.
   4. In the Protocol field, select TCP or UDP from the list.
   5. In the Host ID field, specify the server host ID to be indicated in the SIEM systems log as a detection source.
   6. In the Alert frequency field, enter the interval for sending messages: from 1 to 59 minutes.
   7. Enable TLS encryption, if necessary.
   8. Click Apply.

Export of Kaspersky Anti Targeted Attack Platform events to KUMA is configured.

Creating KUMA collector for receiving KATA/EDR events

After configuring the event export settings, you must create a collector for Kaspersky Anti Targeted Attack Platform events in the KUMA Console.

For details on creating a KUMA collector, refer to Creating a collector.

When creating a collector in the KUMA Console, make sure that the port number matches the port specified in step 4c of Configuring export of Kaspersky Anti Targeted Attack Platform events to KUMA, and that the connector type corresponds to the type specified in step 4d.

To receive Kaspersky Anti Targeted Attack Platform events using Syslog, in the collector Installation wizard, at the Event parsing step, select the [OOTB] KATA normalizer.

Installing KUMA collector for receiving KATA/EDR events

After creating a collector, to configure receiving Kaspersky Anti Targeted Attack Platform events, install a new collector on the network infrastructure server intended for receiving events.

For details on installing the KUMA collector, refer to the Installing collector in the network infrastructure section.

Configuring Open Single Management Platform for export of events to the KUMA SIEM-system

KUMA allows you to receive and export events from Open Single Management Platform Administration Server to the KUMA SIEM system.

Configuring the export and receipt of Open Single Management Platform events proceeds in stages:

1. Configuring the export of Open Single Management Platform events.
2. Configuring the KUMA Collector.
3. Installing the KUMA collector in the network infrastructure.
4. Verifying receipt of Open Single Management Platform events in the KUMA collector

   You can verify if the events from Open Single Management Platform Administration Server were correctly exported to the KUMA SIEM system by using the KUMA Console to search for related events.

   To display Open Single Management Platform events in CEF format in the table, enter the following search expression:

   SELECT * FROM `events` WHERE DeviceProduct = 'KSC' ORDER BY Timestamp DESC LIMIT 250

Configuring KUMA collector for collecting Open Single Management Platform events

After configuring the export of events in the CEF format from Open Single Management Platform Administration Server, configure the collector in the KUMA Console.

To configure the KUMA Collector for Open Single Management Platform events:

1. In the KUMA Console, select Resources → Collectors.
2. In the list of collectors, find the collector with the [OOTB] KSC normalizer and open it for editing.
3. At the Transport step, in the URL field, specify the port to be used by the collector to receive Open Single Management Platform events.

   The port must match the port of the KUMA SIEM system server.

4. At the Event parsing step, make sure that the [OOTB] KSC normalizer is selected.
5. At the Routing step, make sure that the following destinations are added to the collector resource set:
   • Storage. To send processed events to the storage.
   • Correlator. To send processed events to the correlator.

   If the Storage and Correlator destinations were not added, create them.

6. At the Setup validation tab, click Create and save service.
7. Copy the command for installing the KUMA collector that appears.

Installing KUMA collector for collecting Open Single Management Platform events

After configuring the collector for collecting Open Single Management Platform events in the CEF format, install the KUMA collector on the network infrastructure server intended for receiving events.

For details on installing the KUMA collector, refer to the Installing collector in the network infrastructure section.

Configuring receiving Open Single Management Platform event from MS SQL

KUMA allows you to receive information about Open Single Management Platform events from an MS SQL database.

Before configuring, make sure that you have created the KUMA collector for Open Single Management Platform events from MS SQL.

When creating the collector in the KUMA Console, at the Transport step, select the [OOTB] KSC SQL connector.

To receive Open Single Management Platform events from the MS SQL database, at the Event parsing step, select the [OOTB] KSC from SQL normalizer.

Configuring event receiving consists of the following steps:

1. Creating an account in the MS SQL.
2. Configuring the SQL Server Browser service.
3. Creating a secret.
4. Configuring a connector.
5. Installation of collector in the network infrastructure.
6. Verifying receipt of events from MS SQL in the KUMA collector.

   You can verify that the receipt of events from MS SQL is configured correctly by searching for related events in the KUMA Console.

Creating an account in the MS SQL database

To receive Open Single Management Platform events from MS SQL, a user account is required that has the rights necessary to connect and work with the database.

To create an account for working with MS SQL:

1. Log in to the server with MS SQL for Open Single Management Platform installed.
2. Using SQL Server Management Studio, connect to MS SQL using an account with administrator rights.
3. In the Object Explorer pane, expand the Security section.
4. Right-click the Logins folder and select New Login from the context menu.

   The Login - New window opens.

5. On the General tab, click the Search button next to the Login name field.

   The Select User or Group window opens.

6. In the Enter the object name to select (examples) field, specify the object name and click OK.

   The Select User or Group window closes.

7. In the Login - New window, on the General tab, select the Windows authentication option.
8. In the Default database field, select the Open Single Management Platform database.

   The default Open Single Management Platform database name is KAV.

9. On the User Mapping tab, configure the account permissions:
   1. In the Users mapped to this login section, select the Open Single Management Platform database.
   2. In the Database role membership for section, select the check boxes next to the db_datareader and public permissions.
10. On the Status tab, configure the permissions for connecting the account to the database:
    • In the Permission to connect to database engine section, select Grant.
    • In the Login section, select Enabled.
11. Click OK.

    The Login - New window closes.

To check the account permissions:

1. Run SQL Server Management Studio using the created account.
2. Go to any MS SQL database table and make a selection based on the table.

Configuring the SQL Server Browser service

After creating an account in MS SQL, you must configure the SQL Server Browser service.

To configure the SQL Server Browser service:

1. Open SQL Server Configuration Manager.
2. In the left pane, select SQL Server Services.

   A list of services opens.

3. Open the SQL Server Browser service properties in one of the following ways:
   • Double-click the name of the SQL Server Browser service.
   • Right-click the name of the SQL Server Browser service and select Properties from the context menu.
4. In the SQL Server Browser Properties window that opens, select the Service tab.
5. In the Start Mode field, select Automatic.
6. Select the Log On tab and click the Start button.

   Automatic startup of the SQL Server Browser service is enabled.

7. Enable and configure the TCP/IP protocol by doing the following:
   1. In the left pane, expand the SQL Server Network Configuration section and select the Protocols for <SQL Server name> subsection.
   2. Right-click the TCP/IP protocol and select Enable from the context menu.
   3. In the Warning window that opens, click OK.
   4. Open the TCP/IP protocol properties in one of the following ways:
      • Double-click the TCP/IP protocol.
      • Right-click the TCP/IP protocol and select Properties from the context menu.
   5. Select the IP Addresses tab, and then in the IPALL section, specify port 1433 in the TCP Port field.
   6. Click Apply to save the changes.
   7. Click OK to close the window.
8. Restart the SQL Server (<SQL Server name>) service by doing the following:
   1. In the left pane, select SQL Server Services.
   2. In the service list on the right, right-click the SQL Server (<SQL Server name>) service and select Restart from the context menu.
9. In Windows Defender Firewall with Advanced Security, allow inbound connections on the server on the TCP port 1433.

Creating a secret in KUMA

After creating and configuring an account in MS SQL, you must add a secret in the KUMA Console. This resource is used to store credentials for connecting to MS SQL.

To create a KUMA secret:

1. In the KUMA Console, open Resources → Secrets.

   The list of available secrets will be displayed.

2. Click the Add secret button to create a new secret.

   The secret window is displayed.

3. Enter information about the secret:
   1. In the Name field, choose a name for the added secret.
   2. In the Tenant drop-down list, select the tenant that will own the created resource.
   3. In the Type drop-down list, select urls.
   4. In the URL field, specify a string of the following form:

      sqlserver://[<domain>%5C]<username>:<password>@<server>:1433/<database_name>

      where:

      • domain is a domain name.
      • %5C is the domain/user separator. Represents the "\" character in URL format.
      • username is the name of the created MS SQL account.
      • password is the password of the created MS SQL account.
      • server is the name or IP address of the server where the MS SQL database for Open Single Management Platform is installed.
      • database_name is the name of the Open Single Management Platform database. The default name is KAV.

      Example: sqlserver://test.local%5Cuser:password123@10.0.0.1:1433/KAV

      If the MS SQL database account password contains special characters (@ # $ % & * ! + = [ ] : ' , ? / \ ` ( ) ;), convert them to URL format.

4. Click Save.

   For security reasons, the string specified in the URL field is hidden after the secret is saved.

Configuring a connector

To connect KUMA to an MS SQL database, you must configure the connector.

To configure a connector:

1. In the KUMA Console, select Resources → Connectors.
2. In the list of connectors, find the [OOTB] KSC SQL connector and open it for editing.

   If a connector is not available for editing, copy it and open the connector copy for editing.

   If the [OOTB] KSC SQL connector is not available, contact your system administrator.

3. On the Basic settings tab, in the URL drop-down lists, select the secret created for connecting to the MS SQL database.
4. Click Save.

Configuring the KUMA Collector for receiving Open Single Management Platform events from an MS SQL database

After configuring the event export settings, you must create a collector in the KUMA Console for Open Single Management Platform events received from MS SQL.

For details on creating a KUMA collector, refer to Creating a collector.

When creating the collector in the KUMA Console, at the Transport step, select the [OOTB] KSC SQL connector.

To receive Open Single Management Platform events from MS SQL, at the Event parsing step, select the [OOTB] KSC from SQL normalizer.

Installing the KUMA Collector for receiving Open Single Management Platform events from the MS SQL database

After configuring the collector for receiving Open Single Management Platform events from MS SQL, install the KUMA collector on the network infrastructure server where you intend to receive events.

For details on installing the KUMA collector, refer to the Installing collector in the network infrastructure section.

Configuring receipt of events from Windows devices using KUMA Agent (WEC)

KUMA allows you to receive information about events from Windows devices using the WEC KUMA Agent.

Configuring event receiving consists of the following steps:

1. Configuring policies for receiving events from Windows devices.
2. Configuring centralized receipt of events using the Windows Event Collector service.
3. Granting permissions to view events.
4. Granting permissions to log on as a service.
5. Configuring the KUMA Collector.
6. Installing KUMA collector.
7. Forwarding events from Windows devices to KUMA.

Configuring audit of events from Windows devices

You can configure event audit on Windows devices for an individual device or for all devices in a domain.

This section describes how to configure an audit on an individual device and how to use a domain group policy to configure an audit.

Configuring an audit policy on a Windows device

To configure audit policies on a device:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type secpol.msc and click OK.

   The Local security policy window opens.

3. Select Security Settings → Local policies → Audit policy.
4. In the pane on the right, double-click to open the properties of the policy for which you want to enable an audit of successful and unsuccessful attempts.
5. In the <Policy name> properties window, on the Local security setting tab, select the Success and Failure check boxes to track successful and interrupted attempts.

   It is recommended to enable an audit of successful and unsuccessful attempts for the following policies:

   • Audit Logon
   • Audit Policy Change
   • Audit System Events
   • Audit Logon Events
   • Audit Account Management

Configuration of an audit policy on the device is complete.

Configuring an audit using a group policy

In addition to configuring an audit policy on an individual device, you can also configure an audit by using a domain group policy.

To configure an audit using a group policy:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type gpedit.msc and click OK.

   The Local Group Policy Editor window opens.

3. Select Computer configuration → Windows configuration → Security settings → Local policies → Audit policy.
4. In the pane on the right, double-click to open the properties of the policy for which you want to enable an audit of successful and unsuccessful attempts.
5. In the <Policy name> properties window, on the Local security setting tab, select the Success and Failure check boxes to track successful and interrupted attempts.

   It is recommended to enable an audit of successful and unsuccessful attempts for the following policies:

   • Audit Logon
   • Audit Policy Change
   • Audit System Events
   • Audit Logon Events
   • Audit Account Management

If you want to receive Windows logs from a large number of servers or if installation of KUMA agents on domain controllers is not allowed, it is recommended to configure Windows log redirection to individual servers that have the Windows Event Collector service configured.

The audit policy is now configured on the server or workstation.

Configuring centralized receipt of events from Windows devices using the Windows Event Collector service

The Windows Event Collector service allows you to centrally receive data about events on servers and workstations running Windows. You can use the Windows Event Collector service to subscribe to events that are registered on remote devices.

You can configure the following types of event subscriptions:

• Source-initiated subscriptions. Remote devices send event data to the Windows Event Collector server whose address is specified in the group policy. For details on the subscription configuration procedure, please refer to the Configuring data transfer from the event source server section.
• Collector-initiated subscriptions. The Windows Event Collector server connects to remote devices and independently gathers events from local logs. For details on the subscription configuration procedure, please refer to the Configuring the Windows Event Collector service section.

Configuring data transfer from the event source server

You can receive information about events on servers and workstations by configuring data transfer from remote devices to the Windows Event Collector server.

Preliminary steps

1. Verify that the Windows Remote Management service is configured on the event source server by running the following command in the PowerShell console:

   winrm get winrm/config

   If the Windows Remote Management service is not configured, initialize it by running the following command:

   winrm quickconfig

2. If the event source server is a domain controller, make the Windows logs available over the network by running the following command in PowerShell as an administrator:

   wevtutil set-log security /ca:’O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

   Verify access by running the following command:

   wevtutil get-log security

Configuring the firewall on the event source server

To enable the Windows Event Collector server to receive Windows log entries, inbound connection ports must be opened on the event source server.

To open ports for inbound connections:

1. On the event source server, open the Run window by pressing the key combination Win+R.
2. In the opened window, type wf.msc and click OK.

   The Windows Defender Firewall with Advanced Security window opens.

3. Go to the Inbound Rules section and click New Rule in the Actions pane.

   The New Inbound Rule Wizard opens.

4. At the Rule type step, select Port.
5. At the Protocols and ports step, select TCP as the protocol. In the Specific local ports field, indicate the relevant port numbers:
   • 5985 (for HTTP access)
   • 5986 (for HTTPS access)

   You can indicate one of the ports, or both.

6. At the Action step, select Allow connection (selected by default).
7. At the Profile step, clear the Private and Public check boxes.
8. At the Name step, specify a name for the new inbound connection rule and click Done.

Configuration of data transfer from the event source server is complete.

The Windows Event Collector server must have the permissions to read Windows logs on the event source server. These permissions can be assigned to both the Windows Event Collector server account and to a special user account. For details on granting permissions, please refer to the Granting user permissions to view the Windows Event Log.

Configuring the Windows Event Collector service

The Windows Event Collector server can independently connect to devices and gather data on events of any severity.

To configure the receipt of event data by the Windows Event Collector server:

1. On the event source server, open the Run window by pressing Win+R.
2. In the opened window, type services.msc and click OK.

   The Services window opens.

3. In the list of services, find and start the Windows Event Collector service.
4. Open the Event Viewer snap-in by doing the following:
   1. Open the Run window by pressing the key combination Win+R.
   2. In the opened window, type eventvwr and click OK.
5. Go to the Subscriptions section and click Create Subscription in the Actions pane.
6. In the opened Subscription Properties window, specify the name and description of the subscription, and define the following settings:
   1. In the Destination log field, select Forwarded events from the list.
   2. In the Subscription type and source computers section, click the Select computers button.
   3. In the opened Computers window, click the Add domain computer button.

      The Select computer window opens.

   4. In the Enter the object names to select (examples) field, list the names of the devices from which you want to receive event information. Click OK.
   5. In the Computers window, check the list of devices from which the Windows Event Collector server will gather event data and click OK.
   6. In the Subscription properties window, in the Collected events field, click the Select events button.
   7. In the opened Request filter window, specify how often and which data about events on devices you want to receive.
   8. If necessary, in the <All event codes> field, list the codes of the events whose information you want to receive or do not want to receive. Click OK.
7. If you want to use a special account to view event data, do the following:
   1. In the Subscription properties window, click the Advanced button.
   2. In the opened Advanced subscription settings window, in the user account settings, select Specific user.
   3. Click the User and password button and enter the account credentials of the selected user.

Configuration of the Event Collector Service is complete.

To verify that the configuration is correct and event data is being received by the Windows Event Collector server:

In the Event Viewer snap-in, go to Event Viewer (Local) → Windows logs → Forwarded events.

Granting permissions to view Windows events

You can grant permissions to view Windows events for a specific device or for all devices in a domain.

To grant permissions to view events on a specific device:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type compmgmt.msc and click OK.

   The Computer Management window opens.

3. Go to Computer Management (local) → Local users and groups → Groups.
4. In the pane on the right, select the Event Log Readers group and double-click to open the policy properties.
5. Click the Add button at the bottom of the Properties: Event Log Readers window.

   The Select Users, Computers or Groups window opens.

6. In the Enter the object names to select (examples) field, list the names of the users or devices to which you want to grant permissions to view event data. Click OK.

To grant permissions to view events for all devices in a domain:

1. Log in to the domain controller with administrator privileges.
2. Open the Run window by pressing the key combination Win+R.
3. In the opened window, type dsa.msc and click OK.

   The Active Directory Users and Computers window opens.

4. Go to Active Directory Users and Computers → <Domain name> → Builtin.
5. In the pane on the right, select the Event Log Readers group and double-click to open the policy properties.

   In the Properties: Event Log Readers window, open the Members tab and click the Add button.

   The Select Users, Computers or Groups window opens.

6. In the Enter the object names to select (examples) field, list the names of the users or devices to which you want to grant permissions to view event data. Click OK.

Granting permissions to log on as a service

You can grant permission to log on as a service to a specific device or to all devices in a domain. The "Log on as a service" permission allows you to start a process using an account that has been granted this permission.

To grant the "Log on as a service" permission to a device:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type secpol.msc and click OK.

   The Local security policy window opens.

3. Go to Security settings → Local policies → User rights assignment.
4. In the pane on the right, double-click to open the properties of the Log on as a service policy.
5. In the opened Properties: Log on as a Service window, click the Add User or Group button.

   The Select Users or Groups window opens.

6. In the Enter the object names to select (examples) field, list the names of the accounts or devices to which you want to grant the permission to log on as a service. Click OK.

Before granting the permission, make sure that the accounts or devices to which you want to grant the Log on as a service permission are not listed in the properties of the Deny log on as a service policy.

To grant the "Log on as a service" permission to devices in a domain:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type gpedit.msc and click OK.

   The Local Group Policy Editor window opens.

3. Select Computer configuration → Windows configuration → Security settings → Local policies → User rights assignment.
4. In the pane on the right, double-click to open the properties of the Log on as a service policy.
5. In the opened Properties: Log on as a Service window, click the Add User or Group button.

   The Select Users or Groups window opens.

6. In the Enter the object names to select (examples) field, list the names of the users or devices to which you want to grant the permission to log on as a service. Click OK.

Before granting the permission, make sure that the accounts or devices to which you want to grant the Log on as a service permission are not listed in the properties of the Deny log on as a service policy.

Configuring the KUMA Collector for receiving events from Windows devices

After you finish configuring the audit policy on devices, creating subscriptions to events and granting all the necessary permissions, you need to create a collector in the KUMA Console for events from Windows devices.

For details on creating a KUMA collector, refer to Creating a collector.

To receive events from Windows devices, define the following collector settings in the KUMA Collector Installation Wizard:

1. At the Transport step, define the following settings:
   1. In the Connector window, select Create.
   2. In the Type field, select http.
   3. In the Delimiter field, select \0.
2. On the Advanced settings tab, in the TLS mode field, select With verification.
3. At the Event parsing step, click the Add event parsing button.
4. This opens the Basic event parsing window; in that window, in the Normalizer field, select [OOTB] Microsoft Products and click OK.
5. At the Routing step, add the following destinations:
   • Storage. To send processed events to the storage.
   • Correlator. To send processed events to the correlator.

   If the Storage and Correlator destinations were not added, create them.

6. At the Setup validation tab, click Create and save service.
7. Copy the command for installing the KUMA collector that appears.

Installing the KUMA Collector for receiving events from Windows devices

After configuring the collector for receiving Windows events, install the KUMA Collector on the server of the network infrastructure intended for receiving events.

For details on installing the KUMA collector, refer to the Installing collector in the network infrastructure section.

Configuring forwarding of events from Windows devices to KUMA using KUMA Agent (WEC)

To complete the data forwarding configuration, you must create a WEC KUMA agent and then install it on the device from which you want to receive event information.

For more details on creating and installing a WEC KUMA Agent on Windows devices, please refer to the Forwarding events from Windows devices to KUMA section.

Configuring receipt of events from Windows devices using KUMA Agent (WMI)

KUMA allows you to receive information about events from Windows devices using the WMI KUMA Agent.

Configuring event receiving consists of the following steps:

1. Configuring audit settings for managing KUMA.
2. Configuring data transfer from the event source server.
3. Granting permissions to view events.
4. Granting permissions to log on as a service.
5. Creating a KUMA collector.

   To receive Windows device events, in the KUMA Collector Setup Wizard, at the Event parsing step, in the Normalizer field, select [OOTB] Microsoft Products.

6. Installing KUMA collector.
7. Forwarding events from Windows devices to KUMA.

   To complete the data forwarding configuration, you must create a WMI KUMA agent and then install it on the device from which you want to receive event information.

Configuring audit settings for managing KUMA

You can configure event audit on Windows devices both on a specific device using a local policy or on all devices in a domain using a group policy.

This section describes how to configure an audit on an individual device and how to use a domain group policy to configure an audit.

Configuring an audit using a local policy

To configure an audit using a local policy:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type secpol.msc and click OK.

   The Local security policy window opens.

3. Select Security Settings → Local policies → Audit policy.
4. In the pane on the right, double-click to open the properties of the policy for which you want to enable an audit of successful and unsuccessful attempts.
5. In the <Policy name> properties window, on the Local security setting tab, select the Success and Failure check boxes to track successful and interrupted attempts.

   It is recommended to enable an audit of successful and unsuccessful attempts for the following policies:

   • Audit Logon
   • Audit Policy Change
   • Audit System Events
   • Audit Logon Events
   • Audit Account Management

Configuration of an audit policy on the device is complete.

Configuring an audit using a group policy

In addition to configuring an audit on an individual device, you can also configure an audit by using a domain group policy.

To configure an audit using a group policy:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type gpedit.msc and click OK.

   The Local Group Policy Editor window opens.

3. Select Computer configuration → Windows configuration → Security settings → Local policies → Audit policy.
4. In the pane on the right, double-click to open the properties of the policy for which you want to enable an audit of successful and unsuccessful attempts.
5. In the <Policy name> properties window, on the Local security setting tab, select the Success and Failure check boxes to track successful and interrupted attempts.

   It is recommended to enable an audit of successful and unsuccessful attempts for the following policies:

   • Audit Logon
   • Audit Policy Change
   • Audit System Events
   • Audit Logon Events
   • Audit Account Management

The audit policy is now configured on the server or workstation.

Configuring data transfer from the event source server

Preliminary steps

1. On the event source server, open the Run window by pressing the key combination Win+R.
2. In the opened window, type services.msc and click OK.

   The Services window opens.

3. In the list of services, find the following services:
   • Remote Procedure Call
   • RPC Endpoint Mapper
4. Check the Status column to confirm that these services have the Running status.

Configuring the firewall on the event source server

The Windows Management Instrumentation server can receive Windows log entries if ports are open for inbound connections on the event source server.

To open ports for inbound connections:

1. On the event source server, open the Run window by pressing the key combination Win+R.
2. In the opened window, type wf.msc and click OK.

   The Windows Defender Firewall with Advanced Security window opens.

3. In the Windows Defender Firewall with Advanced Security window, go to the Inbound Rules section and in the Actions pane, click New Rule.

   This opens the New Inbound Rule Wizard.

4. In the New Inbound Rule Wizard, at the Rule Type step, select Port.
5. At the Protocols and ports step, select TCP as the protocol. In the Specific local ports field, indicate the relevant port numbers:
   • 135
   • 445
   • 49152–65535
6. At the Action step, select Allow connection (selected by default).
7. At the Profile step, clear the Private and Public check boxes.
8. At the Name step, specify a name for the new inbound connection rule and click Done.

Configuration of data transfer from the event source server is complete.

Granting permissions to view Windows events

You can grant permissions to view Windows events for a specific device or for all devices in a domain.

To grant permissions to view events on a specific device:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type compmgmt.msc and click OK.

   The Computer Management window opens.

3. Go to Computer Management (local) → Local users and groups → Groups.
4. In the pane on the right, select the Event Log Readers group and double-click to open the policy properties.
5. Click the Add button at the bottom of the Properties: Event Log Readers window.

   The Select Users, Computers or Groups window opens.

6. In the Enter the object names to select (examples) field, list the names of the users or devices to which you want to grant permissions to view event data. Click OK.

To grant permissions to view events for all devices in a domain:

1. Log in to the domain controller with administrator privileges.
2. Open the Run window by pressing the key combination Win+R.
3. In the opened window, type dsa.msc and click OK.

   The Active Directory Users and Computers window opens.

4. In the Active Directory Users and Computers window, go to the Active Directory Users and Computers section → <Domain name> → Builtin.
5. In the pane on the right, select the Event Log Readers group and double-click to open the policy properties.

   In the Properties: Event Log Readers window, open the Members tab and click the Add button.

   The Select Users, Computers or Groups window opens.

6. In the Select User, Computer, or Group window, In the Enter the object name to select (examples) field, list the names of the users or devices to which you want to grant permissions to view event data. Click OK.

Granting permissions to log on as a service

You can grant permission to log on as a service to a specific device or to all devices in a domain. The "Log on as a service" permission allows you to start a process using an account that has been granted this permission.

Before granting the permission, make sure that the accounts or devices to which you want to grant the Log on as a service permission are not listed in the properties of the Deny log on as a service policy.

To grant the "Log on as a service" permission to a device:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type secpol.msc and click OK.

   The Local security policy window opens.

3. In the Local Security Policy window, go to the Security Settings → Local Policies → User Rights Assignment section.
4. In the pane on the right, double-click to open the properties of the Log on as a service policy.
5. This opens the Properties: Log on as a Service window; in that window, click Add User or Group.

   This opens the Select Users or Groups window.

6. In the Enter the object names to select (examples) field, list the names of the accounts or devices to which you want to grant the permission to log on as a service. Click OK.

To grant the "Log on as a service" permission to devices in a domain:

1. Open the Run window by pressing the key combination Win+R.
2. In the opened window, type gpedit.msc and click OK.

   The Local Group Policy Editor window opens.

3. Select Computer configuration → Windows configuration → Security settings → Local policies → User rights assignment.
4. In the pane on the right, double-click to open the properties of the Log on as a service policy.
5. This opens the Properties: Log on as a Service window; in that window, click Add User or Group.

   This opens the Select Users or Groups window.

6. In the Enter the object names to select (examples) field, list the names of the users or devices to which you want to grant the permission to log on as a service. Click OK.

Configuring receipt of DNS server events using the ETW agent

The Event Tracing for Windows connector (hereinafter also referred to as the ETW connector) is a mechanism for logging events generated by applications and drivers on the DNS server. You can use the ETW connector to troubleshoot errors during development or to look for malicious activity.

The impact of the ETW connector on DNS server performance is insignificant. For example, a DNS server running on modern hardware and getting up to 100,000 queries per second (QPS) may experience a 5% performance drop while using the ETW connector. If the DNS server gets up to 50,000 requests per second, no performance drop is observed. We recommend monitoring DNS server performance when using the ETW connector, regardless of the number of requests per second.

By default, you can use the ETW connector on Windows Server 2016 or later. The ETW connector is also supported by Windows Server 2012 R2 if the update for event logging and change auditing is installed. The update is available on the Microsoft Support website.

The ETW connector consists of the following components:

• Providers are elements of the system that generate events and send them to the ETW connector. For example, Windows kernels or device drivers can act as providers. When working with code, developers must specify which events the providers must send to the ETW connector. An event may represent the execution of a function that the developer considers important, for example, a function that allows access to the Security Account Manager (SAM).
• Consumers are software systems that receive events generated by providers from the ETW connector, and use these events in some way. For example, KUMA can act as a consumer.
• Controllers are pieces of software that manage the interaction between providers and consumers. For example, the Logman or Wevtutil utilities can be controllers. Providers register with the controller to send events to consumers. The controller can enable or disable a provider. If a provider is disabled, it does not generate events.

Controllers use trace sessions for communication between providers and consumers. Trace sessions are also used for filtering data based on specified parameters because consumers may need different events.

Configuring DNS server event reception using the ETW connector proceeds in stages:

1. Configuration on the Windows side.
2. Creating a KUMA collector.

   When creating a KUMA collector, follow these steps:

   1. At step 2 of the Collector Installation Wizard:
      1. In the Type drop-down list, select the tcp connector type. You can also specify the http connector type and other connector types with verification for secure transmission.
      2. In the URL field, enter the FQDN and port number on which the KUMA collector will listen for a connection from the KUMA agent. You can specify any unoccupied port number.
      3. In the Delimiter field, enter \n.
   2. At step 3 of the Collector Installation Wizard, in the Normalizer drop-down list, select a normalizer. We recommend selecting the predefined extended normalizer for Windows events, [OOTB] Microsoft DNS ETW logs json.
   3. At step 7 of the Collector Installation Wizard, add a Storage type destination for storing events. If you plan to use event correlation, you also need to add a Correlator type destination.
   4. At step 8 of the Collector Installation Wizard, click Create and save service, and in the lower part of the window, copy the command for installing the KUMA collector on the server.
3. Installing the KUMA collector on the server.

   Do the following:

   1. Connect to the KUMA command line interface using a user account with root privileges.
   2. Install the KUMA collector by running the command that you copied at step 8 of the Collector Installation Wizard.
   3. If you want to add the KUMA collector port to the firewall exclusions and update the firewall settings, run the following commands:
      1. firewall-cmd --add-port=<collector port number>/tcp --permanent
      2. firewall-cmd --reload

   The KUMA collector is installed and the status of the KUMA collector service changes to green in the KUMA Console.

4. Creating a KUMA agent.

   When creating a KUMA agent, follow these steps:

   1. Go to the Connection 1 tab.
   2. Under Connector, in the Connector drop-down list, select Create and specify the following settings:
      1. In the Type drop-down list, select the etw connector type.
      2. In the Session name field, enter the provider name that you specified when you configured the reception of DNS server events using the ETW connector on the Windows side.
   3. Under Destinations, in the Destination drop-down list, select Create and specify the following settings:
      1. In the Type drop-down list, select the tcp destination type.
      2. In the URL field, enter the FQDN and port number on which the KUMA collector will listen for a connection from the KUMA agent. The value must match the value that you specified at step 2 of the Collector Installation Wizard.
   4. Go to the Advanced settings tab, and in the Disk buffer size limit field, enter 1073741824.
5. Creating a KUMA agent service.

   You need to copy the ID of the created KUMA agent service. To do so, right-click next to the KUMA agent service and select Copy ID in the context menu.

6. Creating an account for the KUMA agent.

   Create a domain or local Windows user account for running the KUMA agent and reading the analytic log. You need to add the created user account to the Performance Log Users group and grant the Log on service permission to that user account.

7. Installing a KUMA agent on a Windows server.

   You need to install the KUMA agent on the Windows server that will be receiving events from the provider. To do so:

   1. Add the FQDN of the KUMA Core server to the hosts file on the Windows server or to the DNS server.
   2. Create the C:\Users\<user name>\Desktop\KUMA folder on the Windows server.
   3. Copy the kuma.exe file from the KUMA installation package archive to the C:\Users\<user name>\Desktop\KUMA folder.

      

   4. Run the command interpreter as administrator.
   5. Change to the C:\Users\<user name>\Desktop\KUMA folder and run the following command:

      C:\Users\<user name>\Desktop\KUMA>kuma.exe agent --core https://<DOMAIN-NAME-KUMA-CORE-Server>:7210 --id <KUMA agent service ID>

      In the KUMA Console, in the Resources → Active services section, make sure that the KUMA agent service is running and its status is now green, and then abort the command.

   6. Start the KUMA Agent installation in one of the following ways:
      • If you want to start the KUMA agent installation using a domain user account, run the following command:

        C:\Users\<user name>\Desktop\KUMA>kuma.exe agent --core https://<DOMAIN-NAME-KUMA-CORE-Server>:7210 --id <KUMA agent service ID> –-user <domain>\<user account name for the KUMA agent> --install

      • If you want to start the agent installation using a local user account, run the following command:

        C:\Users\<user name>\Desktop\KUMA>kuma.exe agent --core https://<DOMAIN-NAME-KUMA-CORE-Server>:7210 --id <KUMA agent service ID> –-user <user account name for the KUMA agent> --install

      You will need to enter the password of the KUMA agent user account.

   The KUMA Windows Agent service <KUMA agent service ID> is installed on the Windows server. In the KUMA Console, in the Resources → Active services section, if the KUMA agent service is not running and has the red status, you need to make sure that port 7210 is available, as well as the Windows collector port in the direction from the KUMA agent to the KUMA collector.

   To remove the KUMA agent service on the Windows server, run the following command:

   C:\Users\<user name>\Desktop\KUMA>kuma.exe agent --id <KUMA agent service ID> --uninstall

8. Verifying receipt of DNS server events in the KUMA collector.

   You can verify that you have correctly configured the reception of DNS server events using the ETW connector in the Searching for related events section of the KUMA Console.

Configuration on the Windows side

To configure the reception of DNS server events using the ETW connector on the Windows side:

1. Start the Event viewer by running the following command:

   eventvwr.msc

2. This opens a window; in that window, go to the Applications and Services Logs → Microsoft → Windows → DNS-Server folder.
3. Open the context menu of the DNS-Server folder and select View → Show Analytic and Debug Logs.

   

   The Audit debug log and Analytical log are displayed.

4. Configure the analytic log:
   1. Open the context menu of the Analytical log and select Properties.

      

   2. This opens a window; in that window, make sure that in the Max Log Size (KB) field, the value is 1048576.

      

   3. Select the Enable logging check box and in the confirmation window, click OK.

      

      The analytic log must be configured as follows:

      

   4. Click Apply, then click OK.

   An error window is displayed.

   

   When analytic log rotation is enabled, events are not displayed. To view events, in the Actions pane, click Stop logging.

   

5. Start Computer management as administrator.
6. This opens a window; in that window, go to the System Tools → Performance → Startup Event Trace Sessions folder.

   

7. Create a provider:
   1. Open the context menu of the Startup Event Trace Sessions folder and select Create → Data Collector Set.

      

   2. This opens a window; in that window, enter the name of the provider and click Next.

      

   3. Click Add... and in the displayed window, select the Microsoft-Windows-DNSServer provider.

      

      The KUMA agent with the ETW connector works only with System.Provider.Guid: {EB79061A-A566-4698-9119-3ED2807060E7} - Microsoft-Windows-DNSServer.

   4. Click Next twice, then click Finish.
8. Open the context menu of the created provider and select Start As Event Trace Session.

   

9. Go to the Event Trace Sessions folder.

   Event trace sessions are displayed.

10. Open the context menu of the created event trace session and select Properties.
11. This opens a window; in that window, select the Trace Sessions tab and in the Stream Mode drop-down list, select Real Time.

    

12. Click Apply, then click OK.

DNS server event reception using the ETW connector is configured.

Configuring receipt of PostgreSQL events

KUMA lets you monitor and audit PostgreSQL events on Linux devices using rsyslog.

Events are audited using the pgAudit plugin. The plugin supports PostgreSQL 9.5 and later. For details about the pgAudit plugin, see https://github.com/pgaudit/pgaudit.

Configuring event receiving consists of the following steps:

1. Installing the pdAudit plugin.
2. Creating a KUMA collector for PostgreSQL events.

   To receive PostgreSQL events using rsyslog, in the collector installation wizard, at the Event parsing step, select the [OOTB] PostgreSQL pgAudit syslog normalizer.

3. Installing a collector in the KUMA network infrastructure.
4. Configuring the event source server.
5. Verifying receipt of PostgreSQL events in the KUMA collector

   You can verify that the PostgreSQL event source server is correctly configured in the Searching for related events section of the KUMA Console.

Installing the pgAudit plugin

To install the pgAudit plugin:

1. On the OS command line, run the following commands as a user with administrator rights:

   sudo apt update

   sudo apt -y install postgresql-<PostgreSQL version>-pgaudit

   You must select the plugin version to match the PostgresSQL version. For information about PostgreSQL versions and the matching plugin versions, see https://github.com/pgaudit/pgaudit#postgresql-version-compatibility.

   Example: sudo apt -y install postgresql-12-pgaudit

2. Find the postgres.conf configuration file. To do so, run the following command on the PostgreSQL command line:

   show data_directory

   The response will indicate the location of the configuration file.

3. Create a backup copy of the postgres.conf configuration file.
4. Open the postgres.conf file and copy or replace the values in it with the values listed below.

   ```

   ## pgAudit settings

   shared_preload_libraries = 'pgaudit'

   ## database logging settings

   log_destination = 'syslog'

   ## syslog facility

   syslog_facility = 'LOCAL0'

   ## event ident

   syslog_ident = 'Postgres'

   ## sequence numbers in syslog

   syslog_sequence_numbers = on

   ## split messages in syslog

   syslog_split_messages = off

   ## message encoding

   lc_messages = 'en_US.UTF-8'

   ## min message level for logging

   client_min_messages = log

   ## min error message level for logging

   log_min_error_statement = info

   ## log checkpoints (buffers, restarts)

   log_checkpoints = off

   ## log query duration

   log_duration = off

   ## error description level

   log_error_verbosity = default

   ## user connections logging

   log_connections = on

   ## user disconnections logging

   log_disconnections = on

   ## log prefix format

   log_line_prefix = '%m|%a|%d|%p|%r|%i|%u| %e '

   ## log_statement

   log_statement = 'none'

   ## hostname logging status. dns bane resolving affect

   #performance!

   log_hostname = off

   ## logging collector buffer status

   #logging_collector = off

   ## pg audit settings

   pgaudit.log_parameter = on

   pgaudit.log='ROLE, DDL, MISC, FUNCTION'

   ```

5. Restart the PostgreSQL service using the command:

   sudo systemctl restart postgresql

6. To load the pgAudit plugin to PostgreSQL, run the following command on the PostgreSQL command line:

   CREATE EXTENSION pgaudit

The pgAudit plugin is installed.

Configuring a Syslog server to send events

The rsyslog service is used to transmit events from the server to KUMA.

To configure the sending of events from the server where PostgreSQL is installed to the collector:

1. To verify that the rsyslog service is installed on the event source server, run the following command as administrator:

   sudo systemctl status rsyslog.service

   If the rsyslog service is not installed on the server, install it by executing the following commands:

   yum install rsyslog

   sudo systemctl enable rsyslog.service

   sudo systemctl start rsyslog.service

2. In the /etc/rsyslog.d/ directory, create a pgsql-to-siem.conf file with the following content:

   If $programname contains 'Postgres' then @<IP address of the collector>:<port of the collector>

   For example:

   If $programname contains 'Postgres' then @192.168.1.5:1514

   If you want to send events via TCP, the contents of the file must be as follows:
   If $programname contains 'Postgres' then @@<IP address of the collector>:<port of the collector>

   Save changes to the pgsql-to-siem.conf configuration file.

3. Add the following lines to the /etc/rsyslog.conf configuration file:

   $IncludeConfig /etc/pgsql-to-siem.conf

   $RepeatedMsgReduction off

   Save changes to the /etc/rsyslog.conf configuration file.

4. Restart the rsyslog service by executing the following command:

   sudo systemctl restart rsyslog.service

Configuring receipt of IVK Kolchuga-K events

You can configure the receipt of events from the IVK Kolchuga-K system to the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring the sending of IVK Kolchuga-K events to KUMA.
2. Creating a KUMA collector for receiving events from the IVK Kolchuga-K system.

   To receive IVK Kolchuga-K events using Syslog, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] Kolchuga-K syslog normalizer.

3. Installing a KUMA collector for receiving IVK Kolchuga-K events.
4. Verifying receipt of IVK Kolchuga-K events in KUMA.

   You can verify that the IVK Kolchuga-K event source is configured correctly in the Searching for related events section of the KUMA Console.

Configuring export of IVK Kolchuga-K events to KUMA

To configure the export of events of the IVK Kolchuga-K firewall via syslog to the KUMA collector:

1. Connect to the firewall over SSH with administrator rights.
2. Create a backup copy of the /etc/services and /etc/syslog.conf files.
3. In the /etc/syslog.conf configuration file, specify the FQDN or IP address of the KUMA collector. For example:

   *.* @kuma.example.com

   or

   *.* @192.168.0.100

   Save changes to the configuration file /etc/syslog.conf.

4. In the /etc/services configuration file, specify the port and protocol used by the KUMA collector. For example:

   syslog 10514/udp

   Save changes to the /etc/services configuration file.

5. Restart the syslog server of the firewall:

   service syslogd restart

Configuring receipt of CryptoPro NGate events

You can configure the receipt of CryptoPro NGate events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring export of CryptoPro NGate events to KUMA.
2. Creating a KUMA collector for receiving CryptoPro NGate events.

   To receive CryptoPro NGate events using Syslog, in the collector installation wizard, at the Event parsing step, select the [OOTB] NGate syslog normalizer.

3. Creating a KUMA collector for receiving CryptoPro NGate events.
4. Verifying receipt of CryptoPro NGate events in the KUMA collector.

   You can verify that the CryptoPro NGate event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring export of CryptoPro NGate events to KUMA

To configure the sending of events from CryptoPro NGate to KUMA:

1. Connect to the web interface of the NGate management system.
2. Connect remote syslog servers to the management system. To do so:
   1. Open the page with the list of syslog servers: External Services → Syslog Server → Add Syslog Server.
   2. Enter the settings of the syslog server and click .
3. Assign syslog servers to the configuration for recording logs of the cluster. To do so:
   1. In the Clusters → Summary section, select the cluster that you want to configure.
   2. On the Configurations tab, click the Configuration control for the relevant cluster to go to the configuration settings page.

   3. In the

      Syslog Servers

      field of the configured configuration, click the

      Assign

      button.

   4. Select the check boxes for syslog servers that you want to assign and click

      .

      You can assign an unlimited number of servers.

      To add new syslog servers, click .

   5. Publish the configuration to activate the new settings.

4. Assign syslog servers to the management system for recording Administrator activity logs. To do so:

   1. Select the Management Center Settings menu item and on the page that is displayed, under Syslog servers, click Assign.
   2. In the Assign Syslog Servers to Management Center window, select the check box for those syslog servers that you want to assign, then click .

      You can assign an unlimited number of servers.

As a result, events of CryptoPro NGate are sent to KUMA.

Configuring receipt of Ideco UTM events

You can configure the receipt of Ideco UTM application events in KUMA via the Syslog protocol.

Configuring event receiving consists of the following steps:

1. Configuring the export of Ideco UTM events to KUMA.
2. Creating a KUMA collector for receiving Ideco UTM.

   To receive Ideco UTM events, in the Collector Installation Wizard, at the Event parsing step, select the "[OOTB] Ideco UTM syslog" normalizer.

3. Creating a KUMA collector for receiving Ideco UTM events.
4. Verifying receipt of Ideco UTM events in KUMA.

   You can verify that the Ideco UTM event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring export of Ideco UTM events to KUMA

To configure the sending of events from Ideco UTM to KUMA:

1. Connect to the Ideco UTM web interface under a user account that has administrative privileges.
2. In the System message forwarding menu, move the Syslog toggle switch to the enabled position.
3. For the IP address setting, specify the IP address of the KUMA collector.
4. For the Port setting, enter the port that the KUMA collector is listening on.
5. Click Save to apply the changes.

The forwarding of Ideco UTM events to KUMA is configured.

Configuring receipt of KWTS events

You can configure the receipt of events from the Kaspersky Web Traffic Security (KWTS) web traffic analysis and filtering system in KUMA.

Configuring event receiving consists of the following steps:

1. Configuring export of KWTS events to KUMA.
2. Creating a KUMA collector for receiving KWTS events.

   To receive KWTS events, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] KWTS normalizer.

3. Installing a KUMA collector for receiving KWTS events.
4. Verifying receipt of KWTS events in the KUMA collector.

   You can verify that KWTS event export is correctly configured in the Searching for related events section of the KUMA Console.

Configuring export of KWTS events to KUMA

To configure the export of KWTS events to KUMA:

1. Connect to the KWTS server over SSH as root.
2. Before making changes, create backup copies of the following files:
   • /opt/kaspersky/kwts/share/templates/core_settings/event_logger.json.template
   • /etc/rsyslog.conf
3. Make sure that the settings in the /opt/kaspersky/kwts/share/templates/core_settings/event_logger.json.template configuration file have the following values, and make changes if necessary:

   "siemSettings":

   {

   "enabled": true,

   "facility": "Local5",

   "logLevel": "Info",

   "formatting":

   {

4. Save your changes.
5. To send events via UDP, make the following changes to the /etc/rsyslog.conf configuration file:

   $WorkDirectory /var/lib/rsyslog

   $ActionQueueFileName ForwardToSIEM

   $ActionQueueMaxDiskSpace 1g

   $ActionQueueSaveOnShutdown on

   $ActionQueueType LinkedList

   $ActionResumeRetryCount -1

   local5.* @<<IP address of the KUMA collector>:<port of the collector>>

   If you want to send events over TCP, the last line should be as follows:

   local5.* @@<<IP address of the KUMA collector>:<port of the collector>>

6. Save your changes.
7. Restart the rsyslog service with the following command:

   sudo systemctl restart rsyslog.service

8. Go to the KWTS web interface, to the Settings → Syslog tab and enable the Log information about traffic profile option.
9. Click Save.

Configuring receipt of KLMS events

You can configure the receipt of events from the Kaspersky Linux Mail Server (KLMS) mail traffic analysis and filtering system to the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Depending on the version of KLMS you are using, select one of the following options:
   • Configuring export of KLMS 8 events to KUMA
   • Configuring export of KLMS 10 events to KUMA
2. Creating a KUMA collector for receiving KLMS events

   To receive KLMS events, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] KLMS syslog CEF normalizer.

3. Installing a KUMA collector for receiving KLMS events.
4. Verifying receipt of KLMS events in the KUMA collector

   You can verify that the KLMS event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring export of KLMS events to KUMA

To configure the export of KLMS events to KUMA:

1. Connect to the KLMS server over SSH and go to the Technical Support Mode menu.
2. Use the klms-control utility to download the settings to the settings.xml file:

   sudo /opt/kaspersky/klms/bin/klms-control --get-settings EventLogger -n -f /tmp/settings.xml

3. Make sure that the settings in the /tmp/settings.xml file have the following values; make changes if necessary:

   <siemSettings>

   <enabled>1</enabled>

   <facility>Local1</facility>

   ...

   </siemSettings>

4. Apply settings with the following command:

   sudo /opt/kaspersky/klms/bin/klms-control --set-settings EventLogger -n -f /tmp/settings.xml

5. To send events via UDP, make the following changes to the /etc/rsyslog.conf configuration file:

   $WorkDirectory /var/lib/rsyslog

   $ActionQueueFileName ForwardToSIEM

   $ActionQueueMaxDiskSpace 1g

   $ActionQueueSaveOnShutdown on

   $ActionQueueType LinkedList

   $ActionResumeRetryCount -1

   local1.* @<<IP address of the KUMA collector>:<port of the collector>>

   If you want to send events over TCP, the last line should be as follows:

   local1.* @@<<IP address of the KUMA collector>:<port of the collector>>

6. Save your changes.
7. Restart the rsyslog service with the following command:

   sudo systemctl restart rsyslog.service

Configuring receipt of KSMG events

You can configure the receipt of events from the Kaspersky Secure Mail Gateway (KSMG) 1.1 mail traffic analysis and filtering system in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring export of KSMG events to KUMA
2. Creating a KUMA collector for receiving KSMG events

   To receive KSMG events, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] KSMG normalizer.

3. Installing a KUMA collector for receiving KSMG events.
4. Verifying receipt of KSMG events in the KUMA collector

   You can verify that the KSMG event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring export of KSMG events to KUMA

To configure the export of KSMG events to KUMA:

1. Connect to the KSMG server via SSH using an account with administrator rights.
2. Use the ksmg-control utility to download the settings to the settings.xml file:

   sudo /opt/kaspersky/ksmg/bin/ksmg-control --get-settings EventLogger -n -f /tmp/settings.xml

3. Make sure that the settings in the /tmp/settings.xml file have the following values; make changes if necessary:

   <siemSettings>

   <enabled>1</enabled>

   <facility>Local1</facility>

4. Apply settings with the following command:

   sudo /opt/kaspersky/ksmg/bin/ksmg-control --set-settings EventLogger -n -f /tmp/settings.xml

5. To send events via UDP, make the following changes to the /etc/rsyslog.conf configuration file:

   $WorkDirectory /var/lib/rsyslog

   $ActionQueueFileName ForwardToSIEM

   $ActionQueueMaxDiskSpace 1g

   $ActionQueueSaveOnShutdown on

   $ActionQueueType LinkedList

   $ActionResumeRetryCount -1

   local1.* @<<IP address of the KUMA collector>:<port of the collector>>

   If you want to send events over TCP, the last line should be as follows:

   local1.* @@<<IP address of the KUMA collector>:<port of the collector>>

6. Save your changes.
7. Restart the rsyslog service with the following command:

   sudo systemctl restart rsyslog.service

Configuring the receipt of KICS for Networks events

You can configure the receipt of events from Kaspersky Industrial CyberSecurity for Networks (KICS for Networks) 4.2 in KUMA.

Configuring event receiving consists of the following steps:

1. Creating a KICS for Networks connector for sending events to KUMA.
2. Configuring export of KICS for Networks events to KUMA.
3. Creating and installing a KUMA collector to receive KICS for Networks events.
4. Verifying receipt of KICS for Networks events in the KUMA collector.

   You can verify that KICS for Networks event export is correctly configured in the Searching for related events section of the KUMA Console.

Creating a KICS for Networks connector for sending events to KUMA

To create a connector for sending events in the web interface of KICS for Networks:

1. Log in to the KICS for Networks web interface using an administrator account.
2. Go to the Settings → Connectors section.
3. Click the Add connector button.
4. Specify the following settings:
   1. In the Connector type drop-down list, select SIEM.
   2. In the Connector name field, specify a name for the connector.
   3. In the Server address field, enter the IP address of the KICS for Networks Server.
   4. In the Connector deployment node drop-down list, select the node on which you are installing the connector.

      You can specify any name.

   5. In the User name field, specify the user name for KUMA to use for connecting to the application through the connector. You must specify the name of one of the KICS for Networks users.
   6. In the SIEM server address field, enter the IP address of the KUMA collector server.
   7. In the Port number field, enter the port number of the KUMA collector.
   8. In the Transport protocol drop-down list, select TCP or UDP.
   9. Select the Allow sending audit entries check box.
   10. Select the Allow sending application entries check box.
5. Click the Save button.

   The connector is created. It is displayed in the table of KICS for Networks connectors with the Running status.

The KICS for Networks connector for sending events to KUMA is ready for use.

Configuring export of KICS for Networks events to KUMA

To configure the sending of security events from KICS for Networks to KUMA:

1. Log in to the KICS for Networks web interface using an administrator account.
2. Go to the Settings → Event types section.
3. Select the check boxes for the types of events that you want to send to KUMA.
4. Click Select connectors.
5. This opens a window; in that window, select the connector that you created for sending events to KUMA.
6. Click OK.

Events of selected types will be sent to KUMA. In the Event types table, such events are marked with a check box in the column with the connector name.

Creating a KUMA collector to receive KICS for Networks events

After configuring the event export settings, you must create a collector for KICS for Networks events in the KUMA Console.

For details on creating a KUMA collector, refer to Creating a collector.

When creating a collector in the KUMA Console, you must:

1. At the Transport step, select the transport protocol type matching the type you selected when you created the connector in KICS for Networks at step 4i (TCP or UDP) and the port number matching the port number you specified at step 4h.
2. At the Event parsing step, select the [OOTB] KICS4Net v3.х normalizer.
3. At the Routing step, make sure that the following destinations are added to the collector resource set:
   • storage—used to transmit data to the storage.
   • correlator—used to transmit data to the correlator.

   If destinations have not been added to the collector, you must create them.

4. At the last step of the wizard, a command is displayed in the lower part of the window, which you can use to install the service on the server that you want to receive events. Copy this command and use it when installing the second part of the collector.

Configuring receipt of PT NAD events

You can configure the receipt of PT NAD events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring export of PT NAD events to KUMA.
2. Creating a KUMA collector for receiving PT NAD events.

   To receive PT NAD events using Syslog, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] PT NAD json normalizer.

3. Installing a KUMA collector for receiving PT NAD events.
4. Verifying receipt of PT NAD events in the KUMA collector.

   You can verify that the PT NAD event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring export of PT NAD events to KUMA

Configuring the export of events from PT NAD 11 to KUMA over Syslog proceeds in stages:

1. Configuring the ptdpi-worker@notifier module.
2. Configuring the sending of syslog messages with information about activities, attacks and indicators of compromise.

Configuring the ptdpi-worker@notifier module.

To enable the sending of information about detected information security threats, you must configure the ptdpi-worker@notifier module.

In a multi-server configuration, these instructions must be followed on the primary server.

To configure the ptdpi-worker@notifier module:

1. Open the /opt/ptsecurity/etc/ptdpi.settings.yaml file:

   sudo nano /opt/ptsecurity/etc/ptdpi.settings.yaml

2. In the General settings group of settings, uncomment the 'workers' setting and add 'notifier' to its list of values.

   For example:

   workers: ad alert dns es hosts notifier

3. To the end of the file, append a line of the form: notifier.yaml.nad_web_url: <URL of the PT NAD web interface>

   For example:

   notifier.yaml.nad_web_url: https://ptnad.example.com

   The ptdpi-worker@notifier module uses the specified URL to generate links to session and activity cards when sending messages.

4. Restart the sensor:

   sudo ptdpictl restart-all

The ptdpi-worker@notifier module is configured.

Configuring the sending of syslog messages with information about activities, attacks and indicators of compromise

The settings listed in the following instructions may not be present in the configuration file. If a setting is missing, you must add it to the file.

In a multi-server PT NAD configuration, edit the settings on the primary server.

To configure the sending of syslog messages with information about activities, attacks and indicators of compromise:

1. Open the /opt/ptsecurity/etc/ptdpi.settings.yaml file:

   sudo nano /opt/ptsecurity/etc/ptdpi.settings.yaml

2. By default, PT NAD sends activity information in Russian. To receive information in English, change the value of the notifier.yaml.syslog_notifier.locale setting to "en".

   For example:

   notifier.yaml.syslog_notifier.locale: en

3. In the notifier.yaml.syslog_notifier.addresses setting, add a section with settings for sending events to KUMA.

   The <Connection name> setting can only contain Latin letters, numerals, and the underscore character.

   For the 'address' setting, specify the IP address of the KUMA collector.

   Other settings can be omitted, in which case the default values are used.

   notifier.yaml.syslog_notifier.addresses:

   <Connection name>:

   address: <For sending to a remote server, specify protocol: UDP (default) or TCP, address and port; for local connection, specify Unix domain socket>

   doc_types: [<Comma-separated message types ('alert' for information about attacks, 'detection' for activities, and 'reputation' for information about indicators of compromise). By default, all types of messages are sent>]

   facility: <Numeric value of the subject category>

   ident: <software tag>

   <Connection name>:

   ...

   The following is a sample configuration of sending syslog messages with information about activities, attacks, and indicators of compromise to two remote servers via TCP and UDP without writing to the local log:

   notifier.yaml.syslog_notifier.addresses:

   remote1:

   address: tcp://198.51.100.1:1514

   remote2:

   address: udp://198.51.100.2:2514

4. Save your changes in the /opt/ptsecurity/etc/ptdpi.settings.yaml.
5. Restart the ptdpi-worker@notifier module:

   sudo ptdpictl restart-worker notifier

The sending of events to KUMA via Syslog is configured.

Configuring receipt of events using the MariaDB Audit Plugin

KUMA allows auditing events using the MariaDB Audit Plugin. The plugin supports MySQL 5.7 and MariaDB. The audit plugin does not support MySQL 8. Detailed information about the plugin is available on the official MariaDB website.

We recommend using MariaDB Audit Plugin version 1.2 or later.

Configuring event receiving consists of the following steps:

1. Configuring the MariaDB Audit Plugin to send MySQL events and configuring the Syslog server to send events.
2. Configuring the MariaDB Audit Plugin to send MariaDB events and configuring the Syslog server to send events.
3. Creating a KUMA Collector for MySQL 5.7 and MariaDB Events.

   To receive MySQL 5.7 and MariaDB events using the MariaDB Audit Plugin, in the KUMA Collector Installation Wizard, at the Event parsing step, in the Normalizer field, select [OOTB] MariaDB Audit Plugin syslog.

4. Installing a collector in the KUMA network infrastructure.
5. Verifying receipt of MySQL and MariaDB events by the KUMA collector.

   To verify that the MySQL and MariaDB event source server is configured correctly, you can search for related events.

Configuring the MariaDB Audit Plugin to send MySQL events

The MariaDB Audit Plugin is supported for MySQL 5.7 versions up to 5.7.30 and is bundled with MariaDB.

To configure MySQL 5.7 event reporting using the MariaDB Audit Plugin:

1. Download the MariaDB distribution kit and extract it.

   You can download the MariaDB distribution kit from the official MariaDB website. The operating system of the MariaDB distribution must be the same as the operating system on which MySQL 5.7 is running.

2. Connect to MySQL 5.7 using an account with administrator rights by running the following command:

   mysql -u <username> -p

3. To get the directory where the MySQL 5.7 plugins are located, on the MySQL 5.7 command line, run the following command:

   SHOW GLOBAL VARIABLES LIKE 'plugin_dir'

4. In the directory obtained at step 3, copy the MariaDB Audit Plugin from <directory to which the distribution kit was extracted>/mariadb-server-<version>/lib/plugins/server_audit.so.
5. On the operating system command line, run the following command:

   chmod 755 <directory to which the distribution kit was extracted>server_audit.so

   For example:

   chmod 755 /usr/lib64/mysql/plugin/server_audit.so

6. On the MySQL 5.7 command line, run the following command:

   install plugin server_audit soname 'server_audit.so'

7. Create a backup copy of the /etc/mysql/mysql.conf.d/mysqld.cnf configuration file.
8. In the configuration file /etc/mysql/mysql.conf.d/mysqld.cnf, in the [mysqld] section, add the following lines:

   server_audit_logging=1

   server_audit_events=connect,table,query_ddl,query_dml,query_dcl

   server_audit_output_type=SYSLOG

   server_audit_syslog_facility=LOG_SYSLOG

   If you want to disable event export for certain audit event groups, remove some of the values from the server_audit_events setting. Descriptions of settings are available on the MariaDB Audit Plugin vendor's website.

9. Save changes to the configuration file.
10. Restart the MariaDB service by running one of the following commands:
    • systemctl restart mysqld for a system with systemd initialization.
    • service mysqld restart for a system with init initialization.

MariaDB Audit Plugin for MySQL 5.7 is configured. If necessary, you can run the following commands on the MySQL 5.7 command line:

• show plugins to check the list of current plugins.
• SHOW GLOBAL VARIABLES LIKE 'server_audit%' to check the current audit settings.

Configuring the MariaDB Audit Plugin to send MariaDB Events

The MariaDB Audit Plugin is included in the MariaDB distribution kit starting with versions 5.5.37 and 10.0.10.

To configure MariaDB event export using the MariaDB Audit Plugin:

1. Connect to MariaDB using an account with administrator rights by running the following command:

   mysql -u <username> -p

2. To check if the plugin is present in the directory where operating system plugins are located, run the following command on the MariaDB command line:

   SHOW GLOBAL VARIABLES LIKE 'plugin_dir'

3. On the operating system command line, run the following command:

   ll <directory obtained by the previous command> | grep server_audit.so

   If the command output is empty and the plugin is not present in the directory, you can either copy the MariaDB Audit Plugin to that directory or use a newer version of MariaDB.

4. On the MariaDB command line, run the following command:

   install plugin server_audit soname 'server_audit.so'

5. Create a backup copy of the /etc/mysql/my.cnf configuration file.
6. In the /etc/mysql/my.cnf configuration file, in the [mysqld] section, add the following lines:

   server_audit_logging=1

   server_audit_events=connect,table,query_ddl,query_dml,query_dcl

   server_audit_output_type=SYSLOG

   server_audit_syslog_facility=LOG_SYSLOG

   If you want to disable event export for certain audit event groups, remove some of the values from the server_audit_events setting. Descriptions of settings are available on the MariaDB Audit Plugin vendor's website.

7. Save changes to the configuration file.
8. Restart the MariaDB service by running one of the following commands:
   • systemctl restart mariadb for a system with systemd initialization.
   • service mariadb restart for a system with init initialization.

MariaDB Audit Plugin for MariaDB is configured. If necessary, you can run the following commands on the MariaDB command line:

• show plugins to check the list of current plug-ins.
• SHOW GLOBAL VARIABLES LIKE 'server_audit%' to check the current audit settings.

Configuring a Syslog server to send events

The rsyslog service is used to transmit events from the server to the collector.

To configure the sending of events from the server where MySQL or MariaDB is installed to the collector:

1. Before making any changes, create a backup copy of the /etc/rsyslog.conf configuration file.
2. To send events via UDP, add the following line to the /etc/rsyslog.conf configuration file:

   *.* @<IP address of the KUMA collector>:<port of the KUMA collector>

   For example:

   *.* @192.168.1.5:1514

   If you want to send events over TCP, the line should be as follows:

   *.* @@192.168.1.5:2514

   Save changes to the /etc/rsyslog.conf configuration file.

3. Restart the rsyslog service by executing the following command:

   sudo systemctl restart rsyslog.service

Configuring receipt of Apache Cassandra events

KUMA allows receiving information about Apache Cassandra events.

Configuring event receiving consists of the following steps:

1. Configuring Apache Cassandra event logging in KUMA.
2. Creating a KUMA collector for Apache Cassandra events.

   To receive Apache Cassandra events, in the KUMA Collector Installation Wizard, at the Transport step, select a file type connector; at the Event parsing step, in the Normalizer field, select [OOTB] Apache Cassandra file.

3. Installing a collector in the KUMA network infrastructure.
4. Verifying receipt of Apache Cassandra events in the KUMA collector.

   To verify that the Apache Cassandra event source server is configured correctly, you can search for related events.

Configuring Apache Cassandra event logging in KUMA

To configuring Apache Cassandra event logging in KUMA:

1. Make sure that the server where Apache Cassandra is installed has 5 GB of free disk space.
2. Connect to the Apache Cassandra server using an account with administrator rights.
3. Before making changes, create backup copies of the following configuration files:
   • /etc/cassandra/cassandra.yaml
   • /etc/cassandra/logback.xml
4. Make sure that the settings in the /etc/cassandra/cassandra.yaml configuration file have the following values; make changes if necessary:
   1. in the audit_logging_options section, set the enabled setting to true.
   2. In thelogger section, set the class_name parameter to FileAuditLogger.
5. Add the following lines to the /etc/cassandra/logback.xml configuration file:

   <!-- Audit Logging (FileAuditLogger) rolling file appender to audit.log -->

   <appender name="AUDIT" class="ch.qos.logback.core.rolling.RollingFileAppender">

   <file>${cassandra.logdir}/audit/audit.log</file>

   <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">

   <!-- rollover daily -->

   <fileNamePattern>${cassandra.logdir}/audit/audit.log.%d{yyyy-MM-dd}.%i.zip</fileNamePattern>

   <!-- each file should be at most 50MB, keep 30 days worth of history, but at most 5GB -->

   <maxFileSize>50MB</maxFileSize>

   <maxHistory>30</maxHistory>

   <totalSizeCap>5GB</totalSizeCap>

   </rollingPolicy>

   <encoder>

   <pattern>%-5level [%thread] %date{ISO8601} %F:%L - %replace(%msg){'\n', ' '}%n</pattern>

   </encoder>

   </appender>

   <!-- Audit Logging additivity to redirect audt logging events to audit/audit.log -->

   <logger name="org.apache.cassandra.audit" additivity="false" level="INFO">

   <appender-ref ref="AUDIT"/>

   </logger>

6. Save changes to the configuration file.
7. Restart the Apache Cassandra service using the following commands:
   1. sudo systemctl stop cassandra.service
   2. sudo systemctl start cassandra.service
8. After restarting, check the status of Apache Cassandra using the following command:

   sudo systemctl status cassandra.service

   Make sure that the command output contains the following sequence of characters:

   Active: active (running)

Apache Cassandra event export is configured. Events are located in the /var/log/cassandra/audit/ directory, in the audit.log file (${cassandra.logdir}/audit/audit.log).

Configuring receipt of FreeIPA events

You can configure the receipt of FreeIPA events in KUMA via the Syslog protocol.

Configuring event receiving consists of the following steps:

1. Configuring export of FreeIPA events to KUMA.
2. Creating a KUMA collector for receiving FreeIPA events.

   To receive FreeIPA events, in the KUMA Collector Setup Wizard, at the Event parsing step, in the Normalizer field, select [OOTB] FreeIPA.

3. Installing the KUMA collector in the network infrastructure.
4. Verifying receipt of FreeIPA events by KUMA.

   To verify that the FreeIPA event source server is configured correctly, you can search for related events.

Configuring export of FreeIPA events to KUMA

To configure the export of FreeIPA events to KUMA via the Syslog protocol in JSON format:

1. Connect to the FreeIPA server via SSH using an account with administrator rights.
2. In the /etc/rsyslog.d/ directory, create a file named freeipa-to-siem.conf.
3. Add the following lines to the /etc/rsyslog.d/freeipa-to-siem.conf configuration file:

   template(name="ls_json" type="list" option.json="on")

   { constant(value="{")

   constant(value="\"@timestamp\":\"") property(name="timegenerated" dateFormat="rfc3339")

   constant(value="\",\"@version\":\"1")

   constant(value="\",\"message\":\"") property(name="msg")

   constant(value="\",\"host\":\"") property(name="fromhost")

   constant(value="\",\"host_ip\":\"") property(name="fromhost-ip")

   constant(value="\",\"logsource\":\"") property(name="fromhost")

   constant(value="\",\"severity_label\":\"") property(name="syslogseverity-text")

   constant(value="\",\"severity\":\"") property(name="syslogseverity")

   constant(value="\",\"facility_label\":\"") property(name="syslogfacility-text")

   constant(value="\",\"facility\":\"") property(name="syslogfacility")

   constant(value="\",\"program\":\"") property(name="programname")

   constant(value="\",\"pid\":\"") property(name="procid")

   constant(value="\",\"syslogtag\":\"") property(name="syslogtag")

   constant(value="\"}\n")

   }

   *.* @<IP address of the KUMA collector>:<port of the KUMA collector KUMA>;ls_json

   You can fill in the last line in accordance with the selected protocol:

   *.* @<192.168.1.10>:<1514>;ls_json for sending events over UDP

   *.* @@<192.168.2.11>:<2514>;ls_json for sending events over TCP

4. Add the following lines to the /etc/rsyslog.conf configuration file:

   $IncludeConfig /etc/freeipa-to-siem.conf

   $RepeatedMsgReduction off

5. Save changes to the configuration file.
6. Restart the rsyslog service by executing the following command:

   sudo systemctl restart rsyslog.service

Configuring receipt of VipNet TIAS events

You can configure the receipt of ViPNet TIAS events in KUMA via the Syslog protocol.

Configuring event receiving consists of the following steps:

1. Configuring export of ViPNet TIAS events to KUMA.
2. Creating a KUMA collector for receiving ViPNet TIAS events.

   To receive ViPNet TIAS events using Syslog, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] Syslog-CEF normalizer.

3. Installing a KUMA collector for receiving ViPNet TIAS events.
4. Verifying receipt of ViPNet TIAS events in KUMA.

   You can verify that ViPNet TIAS event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring export of ViPNet TIAS events to KUMA

To configure the export of ViPNet TIAS events to KUMA via the syslog protocol:

1. Connect to the ViPNet TIAS web interface under a user account with administrator rights.
2. Go to the Management – Integrations section.
3. On the Integration page, go to the Syslog tab.
4. In the toolbar of the list of receiving servers, click New server.
5. This opens the new server card; in that card:
   1. In the Server address field, enter the IP address or domain name of the KUMA collector.

      For example, 10.1.2.3 or syslog.siem.ru

   2. In the Port field, specify the inbound port of the KUMA collector. The default port number is 514.
   3. In the Protocol list, select the transport layer protocol that the KUMA collector is listening on. UDP is selected by default.
   4. In the Organization list, use the check boxes to select the organizations of the ViPNet TIAS infrastructure.

      Messages are sent only for incidents detected based on events received from sensors of selected organizations of the infrastructure.

   5. In the Status list, use check boxes to select incident statuses.

      Messages are sent only when selected statuses are assigned to incidents.

   6. In the Severity level list, use check boxes to select the severity levels of the incidents.

      Messages are sent only about incidents with the selected severity levels. By default, only the high severity level is selected in the list.

   7. In the UI language list, select the language in which you want to receive information about incidents in messages. Russian is selected by default.
6. Click Add.
7. In the toolbar of the list, set the Do not send incident information in CEF format toggle switch to enabled.

   As a result, when new incidents are detected or the statuses of previously detected incidents change, depending on the statuses selected during configuration, the corresponding information is sent to the specified addresses of receiving servers via the syslog protocol in CEF format.

8. Click Save changes.

Export of events to the KUMA collector is configured.

Configuring receipt of Nextcloud events

You can configure the receipt of Nextcloud 26.0.4 events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring audit of Nextcloud events.
2. Configuring a Syslog server to send events.

   The rsyslog service is used to transmit events from the server to the collector.

3. Creating a KUMA collector for receiving Nextcloud events.

   To receive Nextcloud events, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] Nextcloud syslog normalizer, and at the Transport step select the tcp or udp connector type.

4. Installing KUMA collector for receiving Nextcloud events
5. Verifying receipt of Nextcloud events in the KUMA collector

   You can verify that the Nextcloud event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring audit of Nextcloud events

To configure the export of Nextcloud events to KUMA:

1. On the server where Nextcloud is installed, create a backup copy of the /home/localuser/www/nextcloud/config/config.php configuration file.
2. Edit the /home/localuser/www/nextcloud/config/config.php Nextcloud configuration file.
3. Edit the settings as follows:

   'log_type' => 'syslog',

   'syslog_tag' => 'Nextcloud',

   'logfile' => '',

   'loglevel' => 0,

   'log.condition' => [

   'apps' => ['admin_audit'],

   ],

4. Restart the Nextcloud service:

   sudo service restart nextcloud

Export of events to the KUMA collector is configured.

Configuring a Syslog server to send Nextcloud events

To configure the sending of events from the server where Nextcloud is installed to the collector:

1. In the /etc/rsyslog.d/ directory, create a Nextcloud-to-siem.conf file with the following content:

   If $programname contains 'Nextcloud' then @<IP address of the collector>:<port of the collector>

   Example: If $programname contains 'Nextcloud' then @192.168.1.5:1514

   If you want to send events via TCP, the contents of the file must be as follows:

   If $programname contains 'Nextcloud' then @<IP address of the collector>:<port of the collector>

2. Save changes to the Nextcloud-to-siem.conf configuration file.
3. Create a backup copy of the /etc/rsyslog.conf file.
4. Add the following lines to the /etc/rsyslog.conf configuration file:

   $IncludeConfig /etc/Nextcloud-to-siem.conf

   $RepeatedMsgReduction off

5. Save your changes.
6. Restart the rsyslog service by executing the following command:

   sudo systemctl restart rsyslog.service

The export of Nextcloud events to the collector is configured.

Configuring receipt of Snort events

You can configure the receipt of Snort 3 events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring logging of Snort events.
2. Creating a KUMA collector for receiving Snort events.

   To receive Snort events, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] Snort 3 json file normalizer, and at the Transport step, select the file connector type.

3. Installing a KUMA collector for receiving Snort events
4. Verifying receipt of Snort events in the KUMA collector

   You can verify that the Snort event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring logging of Snort events

Make sure that the server running Snort has at least 500 MB of free disk space for storing a single Snort event log.
When the log reaches 500 MB, Snort automatically creates a new file with a name that includes the current time in unixtime format.
We recommend monitoring disk space usage.

To configure Snort event logging:

1. Connect to the server where Snort is installed using an account with administrative privileges.
2. Edit the Snort configuration file. To do so, run the following command on the command line:

   sudo vi /usr/local/etc/snort/snort.lua

3. In the configuration file, edit the alert_json block:

   alert_json =

   {

   file = true,

   limit = 500,

   fields = 'seconds action class b64_data dir dst_addr dst_ap dst_port eth_dst eth_len \

   eth_src eth_type gid icmp_code icmp_id icmp_seq icmp_type iface ip_id ip_len msg mpls \

   pkt_gen pkt_len pkt_num priority proto rev rule service sid src_addr src_ap src_port \

   target tcp_ack tcp_flags tcp_len tcp_seq tcp_win tos ttl udp_len vlan timestamp',

   }

4. To complete the configuration, run the following command:

   sudo /usr/local/bin/snort -c /usr/local/etc/snort/snort.lua -s 65535 -k none -l /var/log/snort -i <name of the interface that Snort is listening on> -m 0x1b

As a result, Snort events are logged to /var/log/snort/alert_json.txt.

Configuring receipt of Suricata events

You can configure the receipt of Suricata 7.0.1 events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring export of Suricata events to KUMA
2. Creating a KUMA collector for receiving Suricata events.

   To receive Suricata events, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] Suricata json file normalizer, and at the Transport step, select the file connector type.

3. Installing KUMA collector for receiving Suricata events
4. Verifying receipt of Suricata events in the KUMA collector

   You can verify that the Suricata event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring audit of Suricata events.

To configure Suricata event logging:

1. Connect via SSH to the server that has administrative accounts.
2. Create a backup copy of the /etc/suricata/suricata.yaml file.
3. Set the following values in the eve-log section of the /etc/suricata/suricata.yaml configuration file:

   - eve-log:

   enabled: yes

   filetype: regular #regular|syslog|unix_dgram|unix_stream|redis

   filename: eve.json

4. Save your changes to the /etc/suricata/suricata.yaml configuration file.

As a result, Suricata events are logged to the /usr/local/var/log/suricata/eve.json file.

Suricata does not support limiting the size of the eve.json event file. If necessary, you can manage the log size by using rotation. For example, to configure hourly log rotation, add the following lines to the configuration file:

outputs:

- eve-log:

filename: eve-%Y-%m-%d-%H:%M.json

rotate-interval: hour

Configuring receipt of FreeRADIUS events

You can configure the receipt of FreeRADIUS 3.0.26 events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring audit of FreeRADIUS events.
2. Configuring a Syslog server to send FreeRADIUS events.
3. Creating a KUMA collector for receiving FreeRADIUS events.

   To receive FreeRADIUS events, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] FreeRADIUS syslog normalizer, and at the Transport step, select the tcp or udp connector type.

4. Installing KUMA collector for receiving FreeRADIUS events.
5. Verifying receipt of FreeRADIUS events in the KUMA collector.

   You can verify that the FreeRADIUS event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring audit of FreeRADIUS events

To configure event audit in the FreeRADIUS system:

1. Connect to the server where the FreeRADIUS system is installed using an account with administrative privileges.
2. Create a backup copy of the FreeRADIUS configuration file:

   sudo cp /etc/freeradius/3.0/radiusd.conf /etc/freeradius /3.0/radiusd.conf.bak

3. Open the FreeRADIUS configuration file for editing:

   sudo nano /etc/freeradius/3.0/radiusd.conf

4. In the 'log' section, edit the settings as follows:

   destination = syslog

   syslog_facility = daemon

   stripped_names = no

   auth = yes

   auth_badpass = yes

   auth_goodpass = yes

5. Save the configuration file.

FreeRADIUS event audit is configured.

Configuring a Syslog server to send FreeRADIUS events

The rsyslog service is used to transmit events from the FreeRADIUS server to the KUMA collector.

To configure the sending of events from the server where FreeRADIUS is installed to the collector:

1. In the /etc/rsyslog.d/ directory, create the FreeRADIUS-to-siem.conf file and add the following line to it:

   If $programname contains 'radiusd' then @<IP address of the collector>:<port of the collector>

   If you want to send events via TCP, the contents of the file must be as follows:

   If $programname contains 'radiusd' then @<IP address of the collector>:<port of the collector>

2. Create a backup copy of the /etc/rsyslog.conf file.
3. Add the following lines to the /etc/rsyslog.conf configuration file:

   $IncludeConfig /etc/FreeRADIUS-to-siem.conf

   $RepeatedMsgReduction off

4. Save your changes.
5. Restart the rsyslog service:

   sudo systemctl restart rsyslog.service

The export of events from the FreeRADIUS server to the KUMA collector is configured.

Configuring receipt of VMware vCenter events

You can configure the receipt of VMware vCenter events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring the connection to VMware vCenter.
2. Creating a KUMA collector for receiving VMware vCenter events.

   To receive VMware vCenter events, in the collector installation wizard, at the Transport step, select the vmware connector type. Specify the required settings:

   • The URL at which the VMware API is available, for example, https://vmware-server.com:6440.
   • VMware credentials — a secret that specifies the username and password for connecting to the VMware API.

   At the Event parsing step, select the [OOTB] VMware vCenter API normalizer.

3. Installing a KUMA collector for receiving VMware vCenter events.
4. Verifying receipt of VMware vCenter events in the KUMA collector.

   You can verify that the VMware vCenter event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring the connection to VMware vCenter

To configure a connection to VMware vCenter to receive events:

1. Connect to the VMware vCenter web interface under a user account that has administrative privileges.
2. Go to the Security&Users section and select Users.
3. Create a user account.
4. Go to the Roles section and assign the "Read-only: See details of objects role, but not make changes" role to the created account.

   You will use the credentials of this user account in the secret of the collector.

   For details about creating user accounts, refer to the VMware vCenter documentation.

The connection to VMware vCenter for receiving events is configured.

Configuring receipt of zVirt events

You can configure the receipt of zVirt 3.1 events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring export of zVirt events to KUMA.
2. Creating a KUMA collector for receiving zVirt events.

   To receive zVirt events, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] OrionSoft zVirt syslog normalizer, and at the Transport step, select the tcp or udp connector type.

3. Installing KUMA collector for receiving zVirt events
4. Verifying receipt of zVirt events in the KUMA collector

   You can verify that the zVirt event source server is correctly configured in the Searching for related events section of the KUMA Console.

Configuring export of zVirt events

ZVirt can send events to external systems in Hosted Engine installation mode.

To configure the export of zVirt events to KUMA:

1. In the zVirt web interface, under Resources, select Virtual machines.
2. Select the machine that is running the HostedEngine virtual machine and click Edit.
3. In the Edit virtual machine window, go to the Logging section.
4. Select the Determine Syslog server address check box.
5. In the text box, enter the collector information in the following format: <IP address or FQDN of the KUMA collector>: <port of the KUMA collector>.
6. If you want to use TCP instead of UDP for sending logs, select the Use TCP connection check box.

Event export is configured.

Configuring receipt of Zeek IDS events

You can configure the receipt of Zeek IDS 1.8 events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Conversion of the Zeek IDS event log format.

   The KUMA normalizer supports Zeek IDS logs in the JSON format. To send events to the KUMA normalizer, log files must be converted to the JSON format.

2. Creating a KUMA collector for receiving Zeek IDS events.

   To receive Zeek IDS events, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] ZEEK IDS json file normalizer, and at the Transport step, select the file connector type.

3. Installing KUMA collector for receiving Zeek IDS events
4. Verifying receipt of Zeek IDS events in the KUMA collector

   You can verify that the Zeek IDS event source server is correctly configured in the Searching for related events section of the KUMA Console.

Conversion of the Zeek IDS event log format

By default, Zeek IDS events are logged in files in the /opt/zeek/logs/current directory.

The "[OOTB] ZEEK IDS json file" normalizer supports Zeek IDS logs in the JSON format. To send events to the KUMA normalizer, log files must be converted to the JSON format.

This procedure must be repeated every time before receiving Zeek IDS events.

To convert the Zeek IDS event log format:

1. Connect to the server where Zeek IDS is installed using an account with administrative privileges.
2. Create the directory where JSON event logs must be stored:

   sudo mkdir /opt/zeek/logs/zeek-json

3. Change to this directory:

   sudo cd /opt/zeek/logs/zeek-json

4. Run the command that uses the jq utility to convert the original event log format to the target format:

   jq . -c <path to the log file to be converted to a different format> >> <new file name>.log

   Example: jq . -c /opt/zeek/logs/current/conn.log >> conn.log

As a result of running the command, a new file is created in the /opt/zeek/logs/zeek-json directory if this file did not exist before. If the file was already present in the current directory, new information is appended to the end of the file.

Configuring Windows event reception using Kaspersky Endpoint Security for Windows

In KES for Windows, starting from version 12.6, events can be sent from Windows logs to a KUMA collector. In this way, KUMA can get events from Windows logs (a limited set of EventIDs of Microsoft products is supported) from all hosts with KES for Windows 12.6 without installing KUMA agents on such hosts. To activate the functionality, you need:

• A valid KUMA license
• KSC 14.2 or later
• KES for Windows version 12.6 or later

Configuring event receiving consists of the following steps:

1. Importing the normalizer into KUMA.

   In KUMA, you must configure getting updates through Kaspersky update servers.

   Click Import resources and in the list of normalizers available for installation, select [OOTB] Microsoft Products via KES WIN.

2. Creating a KUMA collector for receiving Windows events.

   To receive Windows events, at the Transport step, select TCP or UDP and specify the port number that the collector must listen on. At the Event parsing step, select the [OOTB] Microsoft Products via KES WIN normalizer. At the Event filtering step, select the [OOTB] Microsoft Products via KES WIN - Event filter for collector filter.

3. Requesting a key from KUMA Technical Support.

   If your license did not include a key for activating the functionality of sending Windows logs to the KUMA collector, send the following message to Technical Support: "We have purchased a KUMA license and are using KES for Windows version 12.6. We want to activate the functionality of sending Windows logs to the KUMA collector. Please provide a key file to activate the functionality." New KUMA users do not need to make a Technical Support request because new users get 2 keys with licenses for KUMA and for activating the KES for Windows functionality.

   In response to your message, you will get a key file.

4. Configuration on the side of KSC and KES for Windows.

   A key file that activates the functionality of sending Windows events to KUMA collectors must be imported into KSC and distributed to KES endpoints in accordance with the instructions. You must also add KUMA server addresses to the KES policy and specify network connection settings.

5. Verifying receipt of Windows events in the KUMA collector

   You can verify that the Windows event source server is correctly configured in the Searching for related events section of the KUMA Console.

   Microsoft product events transmitted by KES for Windows are listed in the following table:

   Event log	Event ID
   DNS Server	150
   DNS Server	770
   MSExchange Management	1
   Security	4781
   Security	6416
   Security	1100
   Security	1102 / 517
   Security	1104
   Security	1108
   Security	4610 / 514
   Security	4611
   Security	4614 / 518
   Security	4616 / 520
   Security	4622
   Security	4624 / 528 / 540
   Security	4625 / 529
   Security	4648 / 552
   Security	4649
   Security	4662
   Security	4663
   Security	4672 / 576
   Security	4696
   Security	4697 / 601
   Security	4698 / 602
   Security	4702
   Security	4704 / 608
   Security	4706
   Security	4713/617
   Security	4715
   Security	4717 / 621
   Security	4719 / 612
   Security	4720 / 624
   Security	4722 / 626
   Security	4723 / 627
   Security	4724 / 628
   Security	4725 / 629
   Security	4726 / 630
   Security	4727
   Security	4728 / 632
   Security	4729 / 633
   Security	4732 / 636
   Security	4733 / 637
   Security	4738 / 642
   Security	4739/643
   Security	4740 / 644
   Security	4741
   Security	4742 / 646
   Security	4756 / 660
   Security	4757 / 661
   Security	4765
   Security	4766
   Security	4767
   Security	4768 / 672
   Security	4769 / 673
   Security	4770
   Security	4771 / 675
   Security	4775
   Security	4776 / 680
   Security	4778 / 682
   Security	4780 / 684
   Security	4794
   Security	4798
   Security	4817
   Security	4876 / 4877
   Security	4882
   Security	4885
   Security	4886
   Security	4887
   Security	4890
   Security	4891
   Security	4898
   Security	4899
   Security	4900
   Security	4902
   Security	4904
   Security	4905
   Security	4928
   Security	4946
   Security	4947
   Security	4948
   Security	4949
   Security	4950
   Security	4964
   Security	5025
   Security	5136
   Security	5137
   Security	5138
   Security	5139
   Security	5141
   Security	5142
   Security	5143
   Security	5144
   Security	5145
   Security	5148
   Security	5155
   Security	5376
   Security	5377
   Security	5632
   Security	5888
   Security	5889
   Security	5890
   Security	676
   System	1
   System	104
   System	1056
   System	12
   System	13
   System	6011
   System	7040
   System	7045
   System, Source Netlogon	5723
   System, Source Netlogon	5805
   Terminal-Services-RemoteConnectionManager	1149
   Terminal-Services-RemoteConnectionManager	1152
   Terminal-Services-RemoteConnectionManager	20523
   Terminal-Services-RemoteConnectionManager	258
   Terminal-Services-RemoteConnectionManager	261
   Windows PowerShell	400
   Windows PowerShell	500
   Windows PowerShell	501
   Windows PowerShell	800
   Application, Source ESENT	301
   Application, Source ESENT	302
   Application, Source ESENT	325
   Application, Source ESENT	326
   Application, Source ESENT	327
   Application, Source ESENT	2001
   Application, Source ESENT	2003
   Application, Source ESENT	2005
   Application, Source ESENT	2006
   Application, Source ESENT	216
   Application	1000
   Application	1002
   Application	1 / 2

Configuring receipt of Codemaster Mirada events

You can configure the receipt of Codemaster Mirada events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring audit of the Codemaster Mirada system.
2. Creating a KUMA collector for receiving Codemaster Mirada events.

   To receive Codemaster Mirada, in the Collector Installation Wizard, at the Event parsing step, select the [OOTB] Codemaster Mirada syslog normalizer, and at the Transport step, select the tcp or udp connector type.

3. Installing a collector in the KUMA network infrastructure.
4. Verifying receipt of Codemaster Mirada events in the KUMA collector

   You can verify that the Codemaster Mirada event source server is correctly configured in the Events section of the KUMA Console.

Configuring audit of the Codemaster Mirada system

The Codemaster Mirada system can send events over the Syslog protocol.

To configure event audit in the Codemaster Mirada system:

1. Connect to the Codemaster Mirada web interface under a user account that has administrative privileges.
2. Go to the Settings → Syslog section.
3. Enable the event transmission service using the toggle switch.
4. Select the type and format of the protocol by clicking the dot-in-a-circle icon.
5. In the Host field, specify the IP address of the KUMA collector.
6. In the Protocol field, specify the UDP or TCP transport protocol.
7. In the Port field, specify the port that the KUMA collector is listening on.

   The default port is 514.

8. In the Format field, specify the RFC 3164 standard.
9. Click Save in the lower part of the page to save the changes.

Configuring receipt of Postfix events

You can configure the receipt of Postfix events in KUMA. Integration is only possible when sending events via syslog using the TCP protocol. The resources described in this article are available for KUMA 3.0 and newer versions.

Configuring event receiving consists of the following steps:

1. Configuring Postfix to send events.
2. Creating a KUMA collector for receiving Postfix events.
3. Verifying receipt of Postfix events in the KUMA collector

   You can verify that the Postfix event source server is correctly configured in the Searching for related events section of the KUMA Console.

The Postfix system generates events in two formats:

• Multi-line events containing information about messages (with a unique ID). These events have the following form:

  <syslog PRI> time host process_name: ID: information from base event 1

  <syslog PRI> time host process_name: id: info from base event 2

• Single-line events containing information about errors (without an ID). These events have the following form:

  <syslog PRI> time host process_name: severity: basic information for parsing

A set of KUMA resources is used to process Postfix events; this set of resources must be applied when creating a collector:

• Normalizer
• Aggregation rule
• Filters for destinations

The collector aggregates multi-line base events based on event ID, normalizes them, and sends the aggregated event to the storage and the correlator.

The aggregated event has the following form:

Service information from the aggregation rule: ID: information from base event 1, information from base event 2, information from base event n

After aggregation, the received event is sent to the same collector where the aggregated event is normalized.

Processing algorithm for Postfix events

Configuring Postfix to send events

By default, audit events of the Postfix system are output to /var/log/maillog or /var/log/mail.

To send events to KUMA:

1. Create a backup copy of the /etc/rsyslog.conf file.
2. Open the /etc/rsyslog.conf file for editing.
3. Add the following line to the end of the /etc/rsyslog.conf file:

   mail.* @@<IP address of the KUMA collector>:<port of the KUMA collector>

4. Save the /etc/rsyslog.conf file.
5. Restart the rsyslog service:

   sudo systemctl restart rsyslog

Configuring a KUMA collector for receiving and processing Postfix events

To configure a KUMA collector for receiving Postfix events:

1. Import the [OOTB] Postfix package from the KUMA repository. The package is available for KUMA 3.0 and newer versions.
2. Create a new collector, and in the Collector Installation Wizard, configure the following:
   1. At the Transport step, in the Type field, select the tcp type, and in the URL field, specify the FQDN or IP address and port of the collector.
   2. At the Event parsing step, click Add event parsing, and in the displayed Basic event parsing window, in the Normalizer drop-down list, select the [OOTB] Postfix syslog normalizer.
   3. At the Event aggregation step, click Add aggregation rule, and in the displayed Event aggregation window, in the Aggregation rule drop-down list, select [OOTB] Postfix. Aggregation rule.
   4. At the Routing step, click Add and in the displayed Create destination window, create three destination points one by one—the same collector with the name "Loop", a storage, and a correlator.
      1. Create a destination named "Loop" with the following parameters.
         • On the Basic settings tab, in the Type drop-down list, select the tcp transport type; in the URL field, specify the FQDN or IP address and port of the collector that you specified before at step 2.1 of these instructions.
         • On the Advanced settings tab, in the Filter drop-down list, select the Postfix. Filter for event aggregation filter.

           This configuration is necessary to send the aggregated event to the same collector for subsequent normalization.

      2. Create a correlator destination:
      3. On the Basic settings tab, in the Type drop-down list, select correlator and fill in the URL field.
      4. On the Advanced settings tab, in the Filter drop-down list, select the Postfix. Aggregated events to storage and correlator filter.
      5. Create a storage destination:
      • On the Basic settings tab, in the Type drop-down list, select storage and fill in the URL field.
      • On the Advanced settings tab, in the Filter drop-down list, select the Postfix. Aggregated events to storage and correlator filter.

        This configuration is necessary to send the aggregated normalized event to storage and the correlator.

3. Click the Create button.

   The collector service is created with the settings specified in the KUMA Console. The command for installing the service on the server is displayed.

4. Copy the collector installation command and run it on the relevant server.

The collector is configured to receive and process Postfix events.

Configuring receipt of CommuniGate Pro events

You can configure the receipt of CommuniGate Pro 6.1 events in KUMA. Integration is only possible when sending events via syslog using the TCP protocol. The resources described in this article are available for KUMA 3.0 and newer versions. Processing of SIP module events is supported (such events contain the "SIPDATA" character sequence).

Configuring event receiving consists of the following steps:

1. Configuring CommuniGate Pro to send events
2. Configuring the KUMA collector for receiving CommuniGate Pro events
3. Verifying receipt of CommuniGate Pro events in the KUMA collector

   You can verify that the CommuniGate Pro event source server is correctly configured in the Searching for related events section of the KUMA Console.

The CommuniGate Pro system generates an audit event as several separate records that look like this:

<event code> timestamp ID direction: information from base event 1

<event code> timestamp ID direction: information from base event 2

<event code> timestamp ID direction: base information n

A set of KUMA resources is used to process CommuniGate Pro events; this set of resources must be applied when creating a collector:

• Normalizer
• Aggregation rule
• Filters for destinations

The collector aggregates multi-line base events based on event ID, normalizes them, and sends the aggregated event to the storage and the correlator.

The aggregated event has the following form:

Service information from the aggregation rule: ID: information from base event 1, information from base event 2, information from base event n

After aggregation, the received event is sent to the same collector where the aggregated event is normalized.

Processing algorithm for CommuniGate Pro events

Configuring CommuniGate Pro to send events

By default, CommuniGate Pro audit events are sent to .log files in the /var/CommuniGate/SystemLogs/ directory.

To send events to KUMA, you need to install the KUMA agent on the CommuniGate Pro server and configure it to read .log in the /var/CommuniGate/SystemLogs/ directory and send them to the KUMA collector over TCP.

To create an agent that will read and send events to KUMA:

1. In the KUMA Console, go to Resources and services → Agents and click Add.
2. This opens the Create agent window; in that window, on the Basic settings tab, in the Name field, specify the agent name.
3. On the Config #1 tab, fill in the following fields:
   1. In the Connector group of settings on the Basic settings tab, set the following values for the connector:
      1. In the Name field, enter a name, for example, "CommuniGate file".
      2. In the Type drop-down list, select file.
      3. In the File path field, enter the following value:

         /var/CommuniGate/SystemLogs/.*.log

   2. In the Destinations group of settings on the Basic settings tab, set the following values for the destination:
      1. In the Name field, enter a name, for example, "CommuniGate TCP collector".
      2. In the Type drop-down list, select tcp.
      3. In the URL field, enter the FQDN or IP address and port of the KUMA collector.
4. Click the Create button.
5. When the agent service is created in KUMA, install the agent on the network infrastructure devices from which you want to send data to the collector.

Configuring a KUMA collector for receiving and processing CommuniGate Pro events

To configure a KUMA collector for receiving CommuniGate Pro events:

1. Import the [OOTB] CommuniGate Pro package from the KUMA repository. The package is available for KUMA 3.0 and newer versions.
2. Create a new collector, and in the Collector Installation Wizard, configure the following:
   1. At the Transport step, in the Type field, select the tcp type, and in the URL field, specify the FQDN or IP address and port of the collector.
   2. At the Event parsing step, click Add event parsing, and in the displayed Basic event parsing window, in the Normalizer drop-down list, select the [OOTB] CommuniGate Pro normalizer.
   3. At the Event aggregation step, click Add aggregation rule, and in the displayed Event aggregation window, in the Aggregation rule drop-down list, select [OOTB] CommuniGate Pro. Aggregation rule.
   4. At the Routing step, click Add and in the displayed Create destination window, create three destination points one by one—the same collector with the name "Loop", a storage, and a correlator.
      1. Create a destination named "Loop" with the following parameters:
         • On the Basic settings tab, in the Type drop-down list, select the tcp transport type; in the URL field, specify the FQDN or IP address and port of the collector that you specified before at step 2.1 of these instructions.
         • On the Advanced settings tab, in the Filter drop-down list, select the [OOTB] CommuniGate Pro. Filter for event aggregation filter.

         This configuration is necessary to send the aggregated event to the same collector for subsequent normalization.

      2. Create a correlator destination:
         • On the Basic settings tab, in the Type drop-down list, select correlator and fill in the URL field.
         • On the Advanced settings tab, in the Filter drop-down list, select the [OOTB] CommuniGate Pro. Aggregated events to storage and correlator filter.
      3. Create a storage destination:
         • On the Basic settings tab, in the Type drop-down list, select storage and fill in the URL field.
         • On the Advanced settings tab, in the Filter drop-down list, select the [OOTB] CommuniGate Pro. Aggregated events to storage and correlator filter.

         This configuration is necessary to send the aggregated normalized event to storage and the correlator.

3. Click the Create button.

   The collector service is created with the settings specified in the KUMA Console. The command for installing the service on the server is displayed.

4. Copy the collector installation command and run it on the relevant server.

The collector is configured to receive and process CommuniGate Pro events.

Configuring receipt of Yandex Cloud events

You can configure the receipt of Yandex Cloud events in KUMA. The normalizer supports processing configuration-level audit events stored in .json files.

Configuring event receiving consists of the following steps:

1. Configuring audit of Yandex Cloud events.
2. Configuring export of Yandex Cloud events.
3. Configuring a KUMA collector for receiving and processing Yandex Cloud events.

   To receive Yandex Cloud events in the KUMA Collector Installation Wizard:

   1. In the KUMA Collector Installation Wizard, at the Transport step, select the connector of the file type.
   2. In the URL field, enter /var/log/yandex-cloud/<audit_trail_id>/*/*/*/*.json, where <audit_trail_id> is the ID of the audit.
   3. At the Event parsing step, in the Normalizer field, select [OOTB] Yandex Cloud.
4. Installing a collector in the KUMA network infrastructure.
5. Verifying receipt of Yandex Cloud events in the KUMA collector

   To verify that the Yandex Cloud event source server is configured correctly, you can search for related events.

Configuring audit of Yandex Cloud events

Configuring event export proceeds in stages:

1. Preparing the environment for working with Yandex Cloud.
2. Creating a bucket for audit logs.
3. Creating an encryption key in the Key Management Service.
4. Enabling bucket encryption.
5. Creating service accounts.
6. Creating a static key.
7. Assigning roles to service accounts.
8. Creating an audit trail.

Preparing the environment for working with Yandex Cloud.

To manage the configuration, you need Yandex Cloud CLI; install and initialize it.

Note: by default, audit is performed in the Yandex Cloud folder specified in the CLI profile. You can specify a different folder using the --folder-name or --folder-id parameter.

To configure the audit, you need an active billing account because a fee is charged for using the Yandex Cloud infrastructure.

To configure Yandex Cloud audit, you need an active billing account:

1. Go to the management console, then log in to Yandex Cloud or register.
2. On the Yandex Cloud Billing page, make sure that you have a billing account connected and that it has the ACTIVE or TRIAL_ACTIVE status. If you do not have a billing account, create one.

If you have an active billing account, you can create or select a Yandex Cloud folder in which your infrastructure will work, on the cloud page.

Creating a bucket for audit logs

To create a bucket:

1. In the management console, go to the folder in which you want to create the bucket, for example, example-folder.
2. Select the Object Storage service.
3. Click Create bucket.
4. On the bucket creation page:
   1. Enter the bucket name in accordance with the naming rules, for example kumabucket.
   2. If necessary, limit the maximum size of the bucket. Size 0 means no limit and is equivalent to the enabled No limit option.
   3. As the access type, select Restricted.
   4. Select the default storage class.
   5. Click Create bucket.

The bucket is created.

Creating an encryption key in the Key Management Service

To create an encryption key:

1. In the management console, go to the example-folder folder.
2. Select the Key Management Service.
3. Click the Create key button and specify the following settings:
   • Name (for example, kuma-kms).
   • Encryption algorithm, AES-256.
   • Keep default values for the rest of the settings.
4. Click Create.

The encryption key is created.

Enabling bucket encryption

To enable bucket encryption:

1. In the management console, go to the bucket you created earlier.
2. In the left pane, select Encryption.
3. In the KMS key field, select the kuma-kms key.
4. Click Save.

Bucket encryption is enabled.

Creating service accounts

To create service accounts (a separate account for the trail and a separate account for the bucket):

1. Create the sa-kuma service account:
   1. In the management console, go to the example-folder folder.
   2. In the upper part of the scree, go to the Service accounts tab.
   3. Click Create service account and enter the name of the service account, for example, sa-kuma, making sure the name complies with the naming rules:
      • length: 3 to 63 characters
      • may contain lower-case letters of the Latin alphabet, numerals, and hyphens
      • the first character must be a letter, the last character may not be a hyphen
   4. Click Create.
2. Create the sa-kuma-bucket service account:
   1. In the management console, go to the example-folder folder.
   2. In the upper part of the scree, go to the Service accounts tab.
   3. Click Create service account and enter the name of the service account, for example, sa-kuma-bucket, making sure the name complies with the naming rules:
      • length: 3 to 63 characters
      • may contain lower-case letters of the Latin alphabet, numerals, and hyphens
      • the first character must be a letter, the last character may not be a hyphen
   4. Click Create.

The service accounts are created.

Creating a static key

You will need the key ID and the private key when mounting the bucket. You can create a key using the management console or the CLI.

To create a key using the management console:

1. In the management console, go to the example-folder folder.
2. In the upper part of the screen, go to the Service accounts tab.
3. Select the sa-kuma-bucket service account and click the row with its name.
4. In the upper panel, click Create new key.
5. Select Create static access key.
6. Enter a description for the key and click Create.
7. Save the ID and the secret key.

The static access key is created. The key value will become unavailable when you close the dialog.

To create a key using the CLI:

1. Create an access key for the sa-kuma-bucket service account:

   yc iam access-key create --service-account-name sa-kuma-bucket

   Result:

   access_key:

   id: aje*******k2u

   service_account_id: aje*******usm

   created_at: "2022-09-22T14:37:51Z"

   key_id: 0n8*******0YQ

   secret: JyT*******zMP1

2. Save the key_id and the key from the 'secret' value. You will not be able to get the key value again.

The access key is created.

Assigning roles to service accounts

To assign the audit-trails.viewer, storage.uploader, and kms.keys.encrypterDecrypter roles to the sa-kuma service account:

1. In the CLI, assign the audit-trails.viewer role to the folder:

   yc resource-manager folder add-access-binding \

   --role audit-trails.viewer \

   --id <folder_id> \

   --service-account-id <service_account_id>

   Where:

   • --role is the assigned role.
   • --id is the ID of the 'example-folder' folder.
   • --service-account-id is the ID of the sa-kuma service account.
2. Assign the storage.uploader role to the folder with the bucket:

   yc resource-manager folder add-access-binding \

   --role storage.uploader \

   --id <folder_id> \

   --service-account-id <service_account_id>

   Where:

   • --role is the assigned role.
   • --id is the ID of the 'example-folder' folder.
   • --service-account-id is the ID of the sa-kuma service account.
3. Assign the kms.keys.encrypterDecrypter role to the kuma-kms encryption key:

   yc kms symmetric-key add-access-binding \

   --role kms.keys.encrypterDecrypter \

   --id <key_id> \

   --service-account-id <service_account_id>

   Where:

   • --role is the assigned role.
   • --id is the ID of the kuma-kms KMS key.
   • --service-account-id is the ID of the sa-kuma service account.

To assign the storage.viewer and kms.keys.encrypterDecrypter roles to the sa-kuma-bucket service account:

1. In the CLI, assign the storage.viewer role to the folder:

   yc resource-manager folder add-access-binding \

   --id <folder_id> \

   --role storage.viewer \

   --service-account-id <service_account_id>

   Where:

   • --id is the ID of the 'example-folder' folder.
   • --role is the assigned role.
   • --service-account-id is the ID of the sa-kuma-bucket service account.
2. Assign the kms.keys.encrypterDecrypter role to the kuma-kms encryption key:

   yc kms symmetric-key add-access-binding \

   --role kms.keys.encrypterDecrypter \

   --id <key_id> \

   --service-account-id <service_account_id>

   Where:

   • --role is the assigned role.
   • --id is the ID of the kuma-kms KMS key.
   • --service-account-id is the ID of the sa-kuma-bucket service account.

Creating an audit trail

To create an audit trail:

1. In the management console, go to the example-folder folder.
2. Select the Audit Trails service.
3. Click Create trail and specify a name for the trail you are creating, for example, kuma-trail.
4. In the Destination section, specify the parameters of the destination object:
   • Destination: Object Storage.
   • Bucket: The name of the bucket, for example kumabucket.
   • Object prefix: Optional parameter used in the full name of the audit log file.

     Use a prefix if you store audit logs and third-party data in the same bucket. Do not use the same prefix for logs and other objects in the bucket because this may cause logs and third-party objects to overwrite each other.

   • Encryption key: specify the kuma-kms encryption key that the bucket is encrypted with.
5. In the Service account section, select sa-kuma.
6. In the Collecting management events section, specify the settings for collecting management events audit logs:
   • Collecting events: Select Enabled.
   • Resource: Select Folder.
   • Folder: Does not require filling, contains the name of the current folder.
7. In the Collecting data events, in the Collecting events field, select Disabled.
8. Click Create.

Configuring export of Yandex Cloud events

The bucket must be mounted on the server on which the KUMA collector will be installed.

To mount the bucket:

1. On the server, create a directory for the 'kuma' user:

   sudo mkdir /home/kuma

2. On the server, create a file with a static access key for the sa-kuma-bucket service account and grant appropriate access permissions to the 'kuma' user:

   sudo bash -c 'echo <access_key_ID>:<secret_access_key> > /home/kuma/.passwd-s3fs'

   sudo chmod 600 /home/kuma/.passwd-s3fs

   sudo chown -R kuma:kuma /home/kuma

3. Install the s3fs package:

   sudo apt install s3fs

4. Create a directory where the bucket must be mounted and grant permissions to the kuma user:

   sudo mkdir /var/log/yandex-cloud/

   sudo chown kuma:kuma /var/log/yandex-cloud/

5. Mount the bucket:

   sudo s3fs kumabucket /var/log/yandex-cloud -o passwd_file=/home/kuma/.passwd-s3fs -o url=https://storage.yandexcloud.net -o use_path_request_style -o uid=$(id -u kuma) -o gid=$(id -g kuma)

   You can configure the bucket to be mounted at operating system startup by adding a line to /etc/fstab, for example:

   s3fs#kumabucket /var/log/yandex-cloud fuse _netdev,uid=<kuma_uid>,gid=<kuma_gid>,use_path_request_style,url=https://storage.yandexcloud.net,passwd_file=/home/kuma/.passwd-s3fs 0 0

   Where:

   <kuma_uid> is the ID of the 'kuma' operating system user.

   <kuma_gid> is the ID of the 'kuma' group of operating system users.

   To find out the kuma_uid and kuma_gid, run the following command in the console:

   id kuma

6. Verify that the bucket is mounted:

   sudo ls /var/log/yandex-cloud/

   If everything is configured correctly, the command returns <audit_trail_id>, where <audit_trail_id> is the audit trail ID.

Export of Yandex Cloud events is configured. Events will be located in directories in .json files:

/var/log/yandex-cloud/{audit_trail_id}/{year}/{month}/{day}/*.json

Configuring receipt of Microsoft 365 events

You can configure the receipt of events from the Microsoft 365 (Office 365) cloud solution in KUMA.

Configuring event receiving consists of the following steps:

1. Configuring access to Office 365 management APIs using standard Microsoft methods

   To receive events in KUMA, grant the necessary set of API permissions:

   Microsoft.Graph

   Directory.Read.All

   Office 365 management API

   ActivityFeed.Read

   ActivityFeed.Read.Dlp

2. Creating a KUMA collector

   To receive Microsoft 365 events, create a collector with the following parameters:

   • At the Transport step, specify the office365 connector type.
   • At the Parsing events step, specify the [OOTB] Microsoft Office 365 json normalizer.
3. Installing a collector in a KUMA network infrastructure
4. Verifying receipt of Windows Microsoft 365 in the KUMA collector

   To verify that the Microsoft 365 event source server is configured correctly, you can search for related events.