RuSIEM provides security information and event management capabilities that can serve as a security operation center (SOC). It allows forwarding of syslog events, notification via email, and triggering of scripts based on correlation rules. RuSIEM has a hierarchical structure that allows distributed event collection, correlation, and storage across multiple nodes that can be remotely managed from a single console. It also offers an "only SOC" option where customer sites install collectors and storage nodes that are managed solely by the SOC for access to incidents and events.
2. Existing methods in the current versions
• Forwarding events by Syslog (TLS) to all, by filter or criticality
• Notification by e-mail according to the correlation rule
• Formation and sending of events when triggered the correlation rule
• Running the script and the script in correlation
• The hierarchical structure of RuSIEM
• The "only SOC" option with the installation of collectors or storage
nodes on the Customer's side with management of SOC operators
• Access to incidents, events via RuSIEM API
3
3. Forwarding events by Syslog
• Plain text or Syslog TLS
• All or by filter (field, host, source, criticality, etc.)
• Filtered events with RuSIEM symptomatic ®
• Format: RAW, normalized, CEF
4
4. Notification by e-mail
• Users, groups and any external e-mail addresses
• Indicated individually in each correlation rule
5
5. Formation and sending of events when
triggered correlation rule
• The text of the event is indicated individually in each correlation rule
• By default, notifications are used for system users (by group / user /
role)
6
6. Run script / script in correlation
• Local execution of the script / command individually specified for the
correlation rule
• Content of the script - any of your content
• When the correlation rule is triggered
• The transfer of variables with correlation is supported (for example, $
host, $ src.ip, $ user.name)
7
7. The hierarchical structure of RuSIEM
• Distributed event search without consolidating events into a single
repository
• Distributed correlation without consolidation of events
• Using a multi-level model with different storage periods, its own
correlation rules
• Linked and unrelated levels of the model
• Remote management of nodes from a single console
8
9. Option "only SOC"
• The Customer only installs nodes to collect and(or) store events
• Control is carried out only from SOC
• Access to client node management can be restricted to SOC
personnel and only access to events is provided
10
11. Access to incidents, events via API
• Managing the settings of the node remotely from a single console
• Manage any settings remotely
• Full management of incidents, symptoms, correlation rules remotely
• Authentication and authorization through tokens and role model
12