Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
support@rusiem.com
https://rusiem.com
RuSIEM vs SOC
(Security Operation Center)
2018
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
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
Notification by e-mail
• Users, groups and any external e-mail addresses
• Indicated individually in each correlation rule
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
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
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
SOC
Customers
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
SOC
Customers
Remote offices
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
Contacts:
Web: https://www.rusiem.com
Telegram: https://t.me/rusiem
Facebook: https://www.facebook.com/rvsiem
Info@support: support@rusiem.com
THANK YOU FOR ATTENTION
13

More Related Content

RuSIEM vs SOC (En)

  • 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
  • 12. Contacts: Web: https://www.rusiem.com Telegram: https://t.me/rusiem Facebook: https://www.facebook.com/rvsiem Info@support: support@rusiem.com THANK YOU FOR ATTENTION 13