Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RuSIEM overview (english version)

377 views

Published on

RuSIEM - security information and event management

Published in: Software
  • Be the first to comment

RuSIEM overview (english version)

  1. 1. Co-Founder, CEO Olesya Shelestova oshelestova@rusiem.com RuSIEM February 2017 You have many events and chaos—we have something that will help you
  2. 2. Our Team • Development grows from 2014 • Team members have extensive experience in developing • Product architects have experience in development other than SIEM • RUSIEM’s technology is based on practical experience and use of SIEM/LM • Our product already has a functional. Already it is working stably. • RUSIEM has already been used successfully story in many Enterprise companies in world • We are residents of Skolkovo 3
  3. 3. • Your company has a lot of devices, databases, different systems • Many various vendors • Many errors • Big chaos • Nobody knows what is really happening? 4
  4. 4. 5 Why you need a control: • System downtime, data loss and leakage have a negative impact on business • In some cases, you can prevent an incident in the early stages • Assessment of compliance with the standards required in real time, rather than after the fact • You must bring the facts to investigate the causes of the incidents if the event logs will be lost Raising awareness about what is going on and obtaining control over it
  5. 5. There are two approaches of use SIEM: 1. You have a problem with the control of something. For example, antifraud, control privileged user actions, monitoring visits to the office employees or even the assessment of the causes of failures of your customers on the site 2. In your infrastructure a lot of heterogeneous devices and software. You need to solve the problems associated with both their operability, attacks, performance and vulnerability to them. 6
  6. 6. Wherein: • Monitoring should be automatic • Operators must be notified immediately in the event of critical incidents • The system must be controlled and customized • There should be details about what happened 7
  7. 7. • Almost any software and hardware in the event logs inform about what was happening to her. It may be failures, the sequence of user actions, vulnerability, denial of service, etc. • If able to analyze these events - you can automatically evaluate the state systems, the influence of external factors on their work. • The person can not be estimated from the large number of events themselves, and their relationships to various factors • The program algorithms can not only see the status of a single system, but also to work together thousands of such systems in relation 8
  8. 8. SIEM: Purpose • Real time events monitoring of the infrastructure and business systems • Understand what is going on in the all levels (network, OS, business processes, databases, transactions) • Incidents fixing • Fast respond to emerging incidents • Ensure the evidence base for lawsuits • Collect and provide investigation basis of possible incidents • Software, hardware, user accounts and privileges inventory • Standard compliance, policy compliance 9
  9. 9. Variety of Incidents types • Unauthorized access • Information security threats (spam/malware/data leak/anti-fraud/etc) • Abuses and use of official authority • Software, network and hardware failures • Violation availability of services • Financial frauds • Installation and use of the software control • Detection of changes in the network infrastructure, software environment • User actions control at the database level • Any other 10
  10. 10. Common SIEM scheme 11 User actions Network Hardware Applications RAW Events Normalize Real-time processing Save, Search, Report Active checks
  11. 11. The Input Is… • Absolutely any event • It may be obtained from active checks, inquiries, passive technique and other source • Operating system, transaction, access control systems, business systems, databases, network infrastructure, applications and etc. 12
  12. 12. SIEM • Translates events in the uniform format (parsers) • Enriches the event additional data • Correlates millions of events looking for malfunctions, anomalies, bursts—and overlaps with the described threats • Immediately sends alerts to operators about detected threats and anomalies • Performs proactive measures to minimize the risks as a result of threats • Saves events for analysis and lawsuits 13
  13. 13. Components 1) Log management, LM. 2) SIEM, ESС—Enterprise Security Console. 3) Analytics, ESS—Enterprise Security System. 4) Network sensor—NS. 5) Agent for Windows OS. 14
  14. 14. Components 15 LM Events receiving Normalization Symptoms model Enrichment operations SIEM Contains LM Correlation Incident management (ITIL) Proactive actions Analytics Feeds: ip, hash, fqdn, email, url Baseline © Symptoms operations © Statistics Compliance Asset management Network sensor Data exfiltration Protocol decode Flow Agent Local events pickup Remote events pickup with many sources Hasher © Universal connectors Local event storage QoS
  15. 15. 16 Event sources RuSIEM: all-in-one/LM/SIEM Server with agent Web console Topology Example
  16. 16. Region office Central office Remote office locations LM SIEM LM
  17. 17. 18 LM ESC ESS NS MQ MQ LM/ESC Scaling With MQ
  18. 18. 19 Sources LMSIEMLM Sources Agent MQ Analytics H1-H3 Scaling
  19. 19. Installation Variety • 1 LM, minimal • 1 SIEM, minimal • 2 or more LM servers + 1 SIEM • Array of SIEM servers + a lot of LM • 1 SIEM server + Analytics • SIEM + Analytics + Network sensor 20 Restrictions: • Analytics could not be installed without SIEM • SIEM/Analytics/Network sensor must have different servers
  20. 20. Data Scaling 21 • Different dataset per server node in a single cluster • A single request to all the nodes or to specific one • Ability to place Web console on any node • Physical separation of the data node is possible • Fast correlation without copying all data between nodes • Connecting event sources as one node or different ones MQ Source group-1 Source group-2
  21. 21. Single Data Cluster 22 MQ Source group-1 Source group-2 • A single set of data • Database replication with native tools • Possibility to limit replication • Ability to work with events on a dedicated node to increase speed of search queries
  22. 22. Hybrid Location of the Data 23 • Single and/or different set of data • Correlation with different place locations of the server node® • Possibility of console location on any of the nodes Data-set 1 Data-set 2 Data-set 3 MQ
  23. 23. Data Layer Scaling 24 Events data KB, incidents Analytics Correlations counters and triggers • We can scale any data layer • Cluster with a different set of data or full copies node • Size of the database has no limits • Cluster provides minimal response and maximum performance
  24. 24. RuSIEM Agent • Out-off-box. Supported all MS Windows OS from Windows 2003+ version • Requires .Net 4.0+ • Installs either on endpoints or as a central collector • Collects one agent locally or remotely from a multitude of sources at once, including multi-format sources • Universal connectors: • File log (txt, csv, w3c) • Ftp/sftp/ftps • MySQL • Oracle • MS SQL • Hash process map • WMI query • SDEE • Windows Event Log—with any journal 25
  25. 25. Features of SIEM Agent • Fully manageable from a single management server web console • Modular architecture • Supports DHCP and ARP-proxy • Agent and modules updates from the management server • Transfer agent logs to the management server and save locally • Use pre-defined accounts in the console for each source • Continuous collection on secure local storage in case of connection loss with the server • Adjustable parameters for survey sources • Encryption and secure event local storage • Encrypting communication channel between agent and server • Managing server and logger may be different 26
  26. 26. Correlation • One event correlation • By the number of events • Complex logical condition • Sequence of events/conditions • Accounting incidents • Using symptoms • Using arrays containing values list • Ability to run commands with incident parameters transfer: proactive actions. Example: run block.sh [src][ip], where src.ip – trigger incident • Time ranges of operation rules • Limiting incident zone of visibility for other personal/user groups • Setting priorities/theme and descriptions of the incident/assignment to users and groups 27
  27. 27. Receive & Send Events to Other Systems • Sending notifications by e-mail incidents • Sending normalized/raw events • Sending events by the condition/pattern • TLS encryption channel to send and receive events • Translating any event source format to CEF for other systems • Receiving syslog plain/CEF/Json • Supports all formats of RFC syslog 28
  28. 28. What is Analytics? • Classic SIEM have the same set of mechanisms (normalization, correlation, etc) • But detection of threats to write a rule of correlation. No rules - no automatic detection of threats • For analysts of other vendors offer dedicated power data centers • Local particular hardware facilities at the customer not enough • Transfer events to the date centers often have difficulty because of data privacy • In the case of anonymization of data - are lost sense of analysts 29
  29. 29. Analytics • Our component analysts set a dedicated server(s) and has a custom artificial intelligence mechanisms • We were able to adapt the intelligence mechanism to work on a limited hardware • And it works! 30 • Baseline on selected key fields in analytics rules • Symptoms aggregation by host/user/etc • Feeds • Assets • Statistics • Difficult calculations
  30. 30. How it works? • Our Storm applications work in real-time with normalized events • Different applications receive the data set from events and analyzed • At detection of anomalies generated and sent to the event correlation • Correlation rules are used to clarify and minimize false positives 31
  31. 31. Analytics example • The anomalies and incidents were accompanied by a surge of specific events. For example, if users can not place an order on the site as a result of errors or delivery time of the ordered goods - is likely to be a splash of orders or the number of unformed server errors as compared to other days of the week. For example, it is not typical for the rest of Tuesday / Saturday or other day of weeks. • Our analysts component using Baseline keep track of this anomaly, send event to the correlation and create incident 32
  32. 32. Analytics example • Suppose that we know nothing about the threat. It happened something with hardware or software, and gave rise to some errors in the event log • The analyst set a rule for tracking errors in the context of hosts • Splash events not typical for that host or events are not described in the correlation or symptoms and generate incident about this anomaly • The source of information about the anomaly can be not only events from that host, but also data from other systems (black box method) or network traffic 33
  33. 33. Box VS Customization • Division into system and user essence • Predefined reports, dashboards, symptoms, correlation rules, search query examples • Ability to change correlation rules, reports, and other entities without writing code • Individual representation for each user • Connecting new sources from 3 hours to 3 days 34
  34. 34. Web interface • All server management is performed and agents from the Web console over common browsers (Chrome/Opera/etc). • Optimized for mobile devices • Language: Russian, English (we may add other language) • Https secure • Role-based separation access based on roles from are preset or created by the user with access rights • LDAP pass-through authentication or internal 35
  35. 35. System Update • Online/offline update without internet connection • Component wise update option • Servers do not transmit any customer data • Support updates through a proxy or sslstrip • Update: • Feeds – every hour; • Correlation rules and symptoms - every day with forced emergency update; • Binary and configuration update – daily / weekly. 36
  36. 36. What Makes Us Different From Other SIEM • No need to transmit all events from remote offices for correlation • Flexible, unique correlation rules, symptoms allow an analyst to detect even new unknown threats earlier • No separation of online and archived sample that allows you to store important events for longer period • Symptomatic model allows us to operate more flexibly with events even for novice operators • Analytics in the composition of the product allows you to detect threats even without writing correlation rules • High performance and no limits for storage, EPS and scaling …and other system capabilities based on practical experience and applying SIEM 37
  37. 37. Current status • Our product already has a functional. Already it is working stably. • Our product is installed at the a plurality of customer in and successfully used (banks, oil and gas industry, online shops, service provider, SOC, telecomm) • We are constantly working to improve and product development, the addition of new tools, connecting new sources and collection methods 38
  38. 38. Performance • Over 30 000 EPS per one virtual node • Over 90 000 EPS per server for hardware appliance • There are no scalability limitations to EPS/storage 39 Minimal hardware required resource 2 000 – 5 000 EPS 5 000 – 10 000 10 000 – 30 000 30 000 – 90 000 CPU, kernel count 2-4 4-6 8-14 14+ CPU count 1-2 2+ 2-4 4+ CPU, MHz 2+ 2+ 2.4+ 3.2+ RAM, GB 16 24-32 64-128 64-128+ HDD, speed 7200+ 7200+ 7200+ 7200+ HDD, mode Stand-alone, SAS/SATA Stand-alone, SAS/SATA or raid mirror- mode Raid 5+ Raid 5+ performance, SSD for system disk HDD, size for OS 100 GB 100 GB 150 GB 200 GB HDD, size for data 300+ GB 600+ GB 1TB+ 3TB+
  39. 39. Knowledge base In are preset by default installation: • More 2000 symptoms (and frequently replenished) • 300+ correlation rules • 50+ typical reports • 300+ types of sources events parsers 40 • Through the graphic designer of the new rules, reports, and symptoms of the user can create their own without the need for code writing • Our team of analysts in real time monitors the current threat and adds rules to detect them • We help our customers with the projects implemented, connecting the event sources and the definition of threats typical for them
  40. 40. 2017 Roadmap • MSSP, managed secure service provider • SOC-oriented • Separation of access according to role-model to a set of events • Infrastructure Inventory: passive and active checks, asset management • Building vulnerability management process, integration with scanners • Centralized management of all components • Filling the Knowledge Base • Development of threat detection mechanisms in the early stages • Development of the policy/standard compliance—PCI, SOX and other • Evolution of approaches to assess the impact of threats to business processes 41
  41. 41. Contacts Web site: https://www.rusiem.com (only Russian at this moment) Facebook: https://www.facebook.com/rusiem E-mail: support@rusiem.com Olesya Shelestova, CEO, co-founder: oshelestova@rusiem.com (skype, e-mail) Maxim Stepchenkov, co-founder: m.stepchenkov@it-task.ru Thank You! 42

×