Kaspersky Unified Monitoring and Analysis Platform
- About Kaspersky Unified Monitoring and Analysis Platform
- Program architecture
- Installing and removing KUMA
- Program licensing
- About the End User License Agreement
- About the license
- About the license certificate
- About the license key
- About the key file
- Adding a license key to the program web interface
- Viewing information about an added license key in the program web interface
- Removing a license key in the program web interface
- Integration with other solutions
- Integration with Kaspersky Security Center
- Integration with Kaspersky CyberTrace
- Integration with Kaspersky Threat Intelligence Portal
- Integration with R-Vision Incident Response Platform
- Integration with Active Directory
- Integration with RuCERT
- KUMA resources
- KUMA services
- Analytics
- Working with tenants
- Working with incidents
- About the incidents table
- Saving and selecting incident filter configuration
- Deleting incident filter configurations
- Viewing detailed incident data
- Incident creation
- Incident processing
- Changing incidents
- Automatic linking of alerts to incidents
- Categories and types of incidents
- Exporting incidents to RuCERT
- Working with alerts
- Working with events
- Retroscan
- Managing assets
- Managing KUMA
- Contacting Technical Support
- REST API
- REST API authorization
- Standard error
- Operations
- View list of active lists on the correlator
- Import entries to an active list
- Searching alerts
- Closing alerts
- Searching assets
- Import assets
- Deleting assets
- Searching events
- Viewing information about the cluster
- Resource search
- Loading resource file
- Viewing the contents of a resource file
- Import of resources
- Export resources
- Downloading the resource file
- Search for services
- Tenant search
- View token bearer information
- Appendices
- Commands for components manual starting and installing
- Normalized event data model
- Correlation event fields
- Audit event fields
- Event fields with general information
- User was successfully logged in or failed to log in
- User login successfully changed
- User role was successfully changed
- Other data of the user was successfully changed
- User successfully logged out
- User password was successfully changed
- User was successfully created
- User access token was successfully changed
- Service was successfully created
- Service was successfully deleted
- Service was successfully reloaded
- Service was successfully restarted
- Service was successfully started
- Service was successfully paired
- Service status was changed
- Storage index was deleted by user
- Storage partition was deleted automatically due to expiration
- Active list was successfully cleared or operation failed
- Active list item was successfully deleted or operation was unsuccessful
- Active list was successfully imported or operation failed
- Active list was exported successfully
- Resource was successfully added
- Resource was successfully deleted
- Resource was successfully updated
- Asset was successfully created
- Asset was deleted successfully
- Asset category was successfully added
- Asset category was deleted successfully
- Settings were successfully updated
- Information about third-party code
- Trademark notices
Storage
A KUMA storage is used to store normalized events so that they can be quickly and continually accessed from KUMA for the purpose of extracting analytical data. Access speed and continuity are ensured through the use of the ClickHouse technology. This means that a storage is a ClickHouse cluster bound to a KUMA storage service.
Storage components: clusters, shards, replicas, and keepers.
A cluster is a logical group of machines that possess all accumulated normalized KUMA events. It consists of one or more logical shards.
A shard is a logical group of machines that possess a specific portion of all normalized events accumulated in the cluster. It consists of one or more replicas. Increasing the number of shards lets you do the following:
- Accumulate more events by increasing the total number of servers and disk space.
- Absorb a larger stream of events by distributing the load associated with an influx of new events.
- Reduce the time taken to search for events by distributing search areas among multiple machines.
A replica is a machine that is a member of the logical shard and possesses a copy of the data of this shard. If there are multiple replicas, there are multiple copies (data is replicated). Increasing the number of replicas lets you do the following:
- Improve fault tolerance.
- Distribute the total load related to data searches among multiple machines (although it's best to increase the number of shards for this purpose).
A keeper is an optional role of a replica that involves the replica's participation in coordinating data replication throughout the entire cluster. There must be at least one replica with this role for the entire cluster. It is recommended to have 3 keeper replicas. The number of replicas involved in coordinating replication must be an odd number.
When choosing a ClickHouse cluster configuration, consider the specific event storage requirements of your organization. For more information, please refer to the ClickHouse documentation.
In repositories, you can create spaces. The spaces enable to create a data structure in the cluster and, for example, store the events of a certain type together.