Contents
Normalizers
Normalizer resources are used to convert raw events of various formats so that they conform to the KUMA event data model. This turns them into normalized events that can be processed by other KUMA resources and services.
A normalizer resource consists of the main normalizer and optional extra normalizers. Data is transmitted through a tree-like structure of normalizers depending on the defined conditions, which lets you configure complex logic for processing events.
A normalizer resource is created in several steps:
- Creating the main normalizer
The main normalizer is created by using the Add event parsing button. Entry of normalizer settings is finished by clicking OK.
The main normalizer that you created will be displayed as a dark circle. Clicking on the circle will open the normalizer options for editing. When you hover over the circle, a plus sign is displayed. Click it to add more normalizers.
- Creating conditions for using an extra normalizer
Clicking on the normalizer plus sign opens the Add normalizer to normalization scheme window in which you can specify the conditions that will cause data to be forwarded to the new normalizer.
- Creating an extra normalizer
When the previous step is finished, a window will open for creating an extra normalizer. Entry of normalizer settings is finished by clicking OK.
The extra normalizer you created is displayed as a dark block that indicates the conditions under which this normalizer will be used (see step 2). The conditions can be changed by moving your mouse cursor over the extra normalizer and clicking the button showing the pencil image.
If you hover the mouse pointer over the extra normalizer, a plus button appears, which you can use to create a new extra normalizer. To delete a normalizer, use the button with the trash icon.
If you need to create more normalizers, repeat steps 2 and 3.
- Completing creation of a normalizer resource
Normalizer resource creation is finished by clicking the Save button.
Normalizer settings
The normalizer window contains two tabs: Normalization scheme and Enrichment.
Normalization scheme
This tab is used to specify the main settings of the normalizer and to define the rules for converting events into KUMA format.
Available settings:
- Name (required)—the name of the normalizer. Must contain from 1 to 128 Unicode characters. The name of the main normalizer will be used as the name of the normalizer resource.
- Tenant (required)—name of the tenant that owns the resource.
This setting is not available for extra normalizers.
- Parsing method (required)—drop-down list for selecting the type of incoming events. Depending on your choice, you can use the preconfigured rules for matching event fields or set your own rules. When you select some parsing methods, additional parameter fields required for filling in may become available.
Available parsing methods:
- Keep raw log (required)—in this drop-down list, you can indicate whether you need to store the original raw event in the newly created normalized event. Available values:
- Never—do not save the raw event This is the default setting.
- Only errors—save the raw event in the
Raw
field of the normalized event if errors occurred when parsing it. This value is convenient to use when debugging a service: in this case, every time an event has a non-emptyRaw
field, you know there was a problem.If fields containing the names
*Address
or*Date*
do not comply with normalization rules, these fields are ignored. No normalization error will occur, and the values of the fields will not show up in theRaw
field of the normalized event even if Keep raw log → Only errors was indicated. - Always—always save the raw event in the
Raw
field of the normalized event.
This setting is not available for extra normalizers.
- Save extra fields (required)—in this drop-down list, you can choose whether you need to save fields of the original event in the normalized event if no mapping rules have been configured for them (see below). The data is stored in the Extra event field. By default, fields are not saved.
- Description—up to 256 Unicode characters describing the resource.
This setting is not available for extra normalizers.
- Event examples—in this field, you can provide an example of data that you want to process. Event examples can also be loaded from a TSV, CSV, or TXT file by using the Load from file button.
- Mapping settings block—here you can configure mapping of original event fields to fields of the event in KUMA format:
- Source—column for the names of the original event fields that you want to convert into KUMA event fields.
Clicking the
button next to the field names in the Source column opens the Conversion window, in which you can use the Add conversion button to create rules for modifying the original data before they are written to the KUMA event fields.
- KUMA field—drop-down list for selecting the required fields of KUMA events. You can search for fields by entering their names in the field.
- Label—in this column, you can add a unique custom label to event fields that begin with DeviceCustom*.
New table rows can be added by using the Add row button. Rows can be deleted individually using the
button or all at once using the Clear all button.
If you have loaded data into the Event examples field, the table will have an Examples column containing examples of values carried over from the raw event field to the KUMA event field.
- Source—column for the names of the original event fields that you want to convert into KUMA event fields.
Enrichment
This tab is used to add additional data to fields of a normalized event by using enrichment rules similar to the rules in enrichment rule resources. These enrichment rules are stored in the normalizer resource where they were created. There can be more than one enrichment rule. Enrichments are created by using the Add enrichment button.
Settings available in the enrichment rule settings block:
- Source kind (required)—drop-down list for selecting the type of enrichment. Depending on the selected type, you may see advanced settings that will also need to be completed.
Available Enrichment rule source types:
- Target field (required)—drop-down list for selecting the KUMA event field that should receive the data.
Condition for forwarding data to an extra normalizer
The Add normalizer to normalization scheme window is used to specify the conditions under which the data will be sent to an extra normalizer.
Available settings:
- Fields to pass into normalizer—used to indicate event fields in case you want to send only events with specific fields to the extra normalizer. Leave the field empty if you want to send all data to the extra normalizer.
- Use normalizer for events with specific event field values—used to indicate event fields if you want the extra normalizer to receive only events in which specific values are assigned to certain fields. The value is specified in the Condition value field.
The data processed by these conditions can be preconverted by clicking the
button. This opens the Conversion window, in which you can use the Add conversion button to create rules for modifying the original data before it is written to the KUMA event fields.
Preset normalizers
The normalizers listed in the table below are included in the KUMA kit.
Normalizer name |
Source of events |
Type |
Comment |
[Example] Apache Access Syslog (Common or Combined Log Format) |
Apache access.log in Common or Combined Log format), with Syslog header |
syslog |
|
[Example] Apache Access file (Common or Combined Log Format) |
Apache access.log in Common or Combined Log format) |
regexp |
Reading file |
[Example] BIND Syslog |
BIND server DNS logs, with Syslog header |
syslog |
|
[Example] BIND file |
BIND server DNS logs |
regexp |
Reading file |
[Example] Bastion SKDPU-GW |
IT Bastion SKDPU system |
syslog |
|
[Example] CEF |
Events in CEF format from arbitrary sources |
cef |
|
[Example] Checkpoint Syslog CEF by CheckPoint |
Checkpoint, normalization based on the vendor's CEF event representation diagram |
syslog |
|
[Example] Checkpoint Syslog basic |
Custom mapping of Checkpoint fields, normalization depending on the type of asset |
syslog |
|
[Example] Cisco Basic |
Cisco ASA base set of events |
syslog |
|
[Example] Cisco ASA Extended v 0.1 |
Cisco ASA base extended set of events |
syslog |
|
[Example] Cisco WSA AccessFile |
Cisco WSA proxy server, access.log file |
regexp |
Reading file |
[Example] Continent DB AlertLog |
Hardware and software encryption system Continent, DB query, AlertLog table |
sql |
|
[Example] Continent DB PacketLog |
Hardware and software encryption system Continent, DB query, PacketLog table |
sql |
|
[Example] Continent DB ServerAccessLog |
Hardware and software encryption system Continent, DB query, ServerAccessLog table |
sql |
|
[Example] Continent DB SystemLog |
Hardware and software encryption system Continent, DB query, SystemLog table |
sql |
|
[Example] CyberTrace |
Kaspersky CyberTrace events |
regexp |
|
[Example] DNS Windows |
Windows DNS server logs |
regexp |
Reading file |
[Example] Dovecot Syslog |
dovecpt server POP3/IMAP logs |
syslog |
|
[Example] Exchange CSV |
Exchange server MTA logs |
csv |
Reading file |
[Example] Fortimail |
Fortimail mail system logs |
regexp |
Only KUMA v 1.5 |
[Example] IIS Log File Format |
Microsoft IIS logs |
regexp |
Reading file |
[Example] IPFIX |
IPFIX format Netflow events |
ipfix |
|
[Example] InfoWatch Traffic Monitor |
DLP system Traffic Monitor by Infowatch |
sql |
|
[Example] KATA |
Kaspersky Anti Targeted Attack |
cef |
|
[Example] KICS4Net v2.x |
Kaspersky Industrial Cyber Security v 2.x |
cef |
|
[Example] KICS4Net v3.x |
Kaspersky Industrial Cyber Security v 3.x |
syslog |
|
[Example] KSC |
Kaspersky Security Center |
cef |
Passive receiving of events from KSC: KUMA is listening to the port, KSC is sending events |
[Example] KSC from SQL |
Kaspersky Security Center |
sql |
Active receiving of events from KSC: KUMA receives events from the KSC DB |
[Example] KSMG |
Kaspersky Security Mail Gateway |
syslog |
|
[Example] Linux audit and iptables Syslog |
Linux events |
syslog |
|
[Example] Linux audit.log file |
Linux events |
regexp |
Reading file |
[Example] Syslog |
Events in Syslog format from arbitrary sources |
syslog |
|
[Example] Syslog-CEF |
Events in CEF format from arbitrary sources, with Syslog header |
syslog |
|
[Example] VipNet Coordinator Syslog |
VipNet Coordinator logs |
syslog |
|
[Example] Windows Basic |
Basic set of Windows Security events |
xml |
|
[Example] Windows Extended v.0.1 |
Extended set of Windows events |
xml |
|
[Example] pfSense Syslog |
pfSence events |
syslog |
|
[Example] pfSense w/o hostname |
Custom pfSence event normalizer (invalid Syslog header format) |
regexp |
|
[Example][Syslog] Continent IPS/IDS & TLS |
Continent intrusion detection system, TSL |
syslog |
Receiving from Syslog |
[Example][regexp] Continent IPS/IDS & TLS |
Continent intrusion detection system, TSL |
regexp |
Reading file |
[Example] NetFlow v5 |
Netflow v5 events |
netflow5 |
|
[Example] NetFlow v9 |
Netflow v9 events |
netflow9 |
|
[Example] MS DHCP file |
Windows DHCP server logs |
csv |
Reading file |
[Example] Nginx regexp |
Nginx log |
regexp |
|
[Example] PA-NGFW (Syslog-CSV) |
Palo Alto logs in CSV format |
csv |
The preferred option for sending logs is CEF format. Logs may only be sent in CSV if sending in CEF is not possible |
[Example] PT WAF |
Web Application Firewall by Positive Technologies |
syslog |
|
[Example] Squid access Syslog |
access.log logs of the Squid proxy server |
syslog |
|
[Example] Squid access.log file |
access.log logs of the Squid proxy server |
regexp |
Reading file |
[Example] Unbound Syslog |
DNS server logs unbount |
syslog |
|