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 involves the following steps:

1. Installation of KUMA collector in the network infrastructure.
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 web interface.

Installing KUMA collector for receiving Auditd events

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. In the /etc/rsyslog.d folder, create the audit.conf file with the following content:

   $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>

   If you want to send events over TCP, instead of the last line in the file insert the following line:
   *.* @@<KUMA collector IP address>:<KUMA collector port>.

3. Save the changes to the audit.conf file.
4. 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 web interface, 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 involves the following steps:

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 web interface. 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.

Configuring Kaspersky Anti Targeted Attack Platform integration with KUMA

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 web interface.

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

When creating a collector in the KUMA web interface, 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 Kaspersky Security Center event receiving in CEF format

KUMA allows you to receive and export events in the CEF format from Kaspersky Security Center Administration Server to the KUMA SIEM system.

Configuring the receipt of Kaspersky Security Center events in the CEF format involves the following steps:

1. Configuring the forwarding of Kaspersky Security Center events.
2. Configuring the KUMA Collector.
3. Installing the KUMA collector in the network infrastructure.
4. Verifying receipt of Kaspersky Security Center events in the CEF format in the KUMA collector

   You can verify if the events from Kaspersky Security Center Administration Server in the CEF format were correctly exported to the KUMA SIEM system by using the KUMA web interface to search for related events.

   To display Kaspersky Security Center 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 export of Kaspersky Security Center events in CEF format

Kaspersky Security Center allows you to configure the settings for exporting events in the CEF format to a SIEM system.

The function of exporting Kaspersky Security Center events in the CEF format to SIEM systems is available with Kaspersky Endpoint Security for Business Advanced license or above.

To configure export of events from Kaspersky Security Center Administration Server to the KUMA SIEM system:

1. In Kaspersky Security Center console tree, select the Administration server node.
2. In the workspace of the node, select the Events tab.
3. Click the Configure notifications and event export link and select Configure export to SIEM system from the drop-down list.

   The Properties: Events window opens. By default the Events export section is displayed.

4. In the Events export section, select the Automatically export events to SIEM system database check box.
5. In the SIEM system drop-down list select ArcSight (CEF format).
6. In the corresponding fields, specify the address of the KUMA SIEM system server and the port for connecting to the server. Select TCP/IP as the protocol.

   You can click Export archive and specify the starting date from which pre-existing KUMA events are to be exported to the SIEM system database. By default, Kaspersky Security Center exports events starting from the current date.

7. Click OK.

As a result, the Kaspersky Security Center Administration Server automatically exports all events to the KUMA SIEM system.

Configuring export of Kaspersky Security Center events to the KUMA SIEM system

Configuring KUMA collector for collecting Kaspersky Security Center events

After configuring the export of events in the CEF format from Kaspersky Security Center Administration Server, configure the collector in the KUMA web interface.

To configure the KUMA Collector for Kaspersky Security Center events:

1. In the KUMA web interface, 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 Kaspersky Security Center 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 Kaspersky Security Center events

After configuring the collector for collecting Kaspersky Security Center 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 Kaspersky Security Center event from MS SQL

KUMA allows you to receive information about Kaspersky Security Center events from an MS SQL database.

Before configuring, make sure that you have created the KUMA collector for Kaspersky Security Center events from MS SQL.

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

To receive Kaspersky Security Center 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 web interface.

Creating an account in the MS SQL database

To receive Kaspersky Security Center 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 Kaspersky Security Center 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 Kaspersky Security Center database.

   The default Kaspersky Security Center 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 Kaspersky Security Center 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 web interface. This resource is used to store credentials for connecting to MS SQL.

To create a KUMA secret:

1. In the KUMA web interface, 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 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 Kaspersky Security Center is installed.
      • database_name is the name of the Kaspersky Security Center 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 web interface, 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 Kaspersky Security Center events from an MS SQL database

After configuring the event export settings, you must create a collector in the KUMA web interface for Kaspersky Security Center events received from MS SQL.

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

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

To receive Kaspersky Security Center events from MS SQL, at the Event parsing step, select the [OOTB] KSC from SQL normalizer.

Installing the KUMA Collector for receiving Kaspersky Security Center events from the MS SQL database

After configuring the collector for receiving Kaspersky Security Center 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 web interface 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. In the opened Basic event parsing window, in the Normalizer field, select [OOTB] Windows Extended v.1.0 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 events from Windows devices, in the KUMA Collector Installation Wizard, at the Event parsing step, in the Normalizer field, select [OOTB] Windows Extended v.1.0.

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 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 web interface.

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 web interface.

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 web interface.

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

      the icon.

      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 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 web interface.

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 web interface.

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. Configuring export of KLMS 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 web interface.

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 web interface.

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 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 web interface.

Configuring export of PT NAD events to KUMA

Configuring the export of events from PT NAD 11 to KUMA over Syslog involves the following steps:

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 plugins.
• 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 the logger section, set the class_name setting 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 web interface.

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 Sendmail events

You can configure the receipt of Sendmail mail agent events in the KUMA SIEM system.

Configuring event receiving consists of the following steps:

1. Configuring Sendmail logging.
2. Configuring the event source server.
3. Creating a KUMA collector.

   To receive Sendmail events, use the following values in the Collector Installation Wizard:

   • At the Event parsing step, select the [OOTB] Sendmail syslog normalizer.
   • At the Transport step, select the tcp or udp connector type.
4. Installing KUMA collector.
5. Verifying receipt of Sendmail events in the KUMA collector

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

Configuring Sendmail logging

By default, events of the Sendmail system are logged to syslog.

To make sure that logging is configured correctly:

1. Connect via SSH to the server on which the Sendmail system is installed.
2. Run the following command:

   cat /etc/rsyslog.d/50-default.conf

   The command should return the following string:

   mail.* -/var/log/mail.log

If logging is configured correctly, you can proceed to configuring the export of Sendmail events.

Configuring export of Sendmail events

Events are sent from the Sendmail mail agent server to the KUMA collector using the rsyslog service.

To configure transmission of Sendmail events to the collector:

1. Connect to the server where Sendmail is installed using an account with administrative privileges.
2. In the /etc/rsyslog.d/ directory, create the Sendmail-to-siem.conf file and add the following line to it:

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

   Example: If $programname contains 'sendmail' 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 'sendmail' then @@<<IP address of the collector>:<port of the collector>>

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/Sendmail-to-siem.conf

   $RepeatedMsgReduction off

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

   sudo systemctl restart rsyslog.service

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 web interface.

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 web interface.

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 web interface.

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 web interface.

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 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 web interface.

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 web interface.

New Topic (202)

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.