Skip to main content
Loading...

What is RuSIEM Analytics

RuSIEM Analytics is a module installed for the commercial version of RuSIEM. The module is separately licensed. The hardware requirements for the operation of the module are twice as large as for the commercial version of RuSIEM.


Added sections in the interface with the analytics module

The following sections are added in the web interface:

  • Отслеживание аутентификации
  • Vulnerabilities
  • Compliance
  • Analytics
  • Assets
  • Intelligence feeds

In addition, there are additional features in other sections of the interface, in correlation, in reports, on dashboards.

For example, it is possible to do complex complex reports, such as "All the src.ip addresses that more than 1000 ports below 1024 for 24 hours". For dashboards - it is possible to build statistics using analytics.


Authentication Tracking

Surely you received at least once an alert from Google, Dropbox and other services that you logon from such an IP address, browser? We have implemented similar but with a focus on commercial consumers and customizable for any case.

For example, it is possible to create a rule with an indication of a key, a symptom of logon and logoff from the system, a bundle of comparison attributes.

For example, it is possible to create any rule that will track the logons, logoff for any of your system. In the comparison attributes you add, you add the name of the client application, the name of the application server, src.ip, the name of the user. If a user suddenly enters from another IP address or application on this server or another new user enters this src.ip, an incident will be generated, an alert will be sent to the operators about the incident. Signs of entry is possible to determine any.

Statistics are kept on active sessions and in the history of what happened.


Vulnerabilities

This section is a reference and contains a list of all known vulnerabilities. You can view vulnerabilities in detail, search by phrases, by CVE / CVSS, sort and view CVE. Updated several times a day. Access to update - as part of technical support. Vulnerabilities are used in assets.


Compliance

This section is intended to organize Standard Compliance and Policy Compliance. There is a predefined standard PCI DSS 3.1 containing technical controls for auditing. The user can create his own standard, specify controls in it, specify the scope and build a report in the reports section. The report for the selected period for each technical control indicates compliance or non-compliance.


Analytics

Analytics in the RuSIEM Analytics module has several sub-modules.

The first, user-driven, is based on DL (Data Learning) and is called Baseline.

For Baseline, rules are specified that contain:

  • observed keychain (from 1 to 21)
  • whether or not to use historical data
  • period of historical data (usually 21 days)
  • period of accumulation of historical data (day or hour)
  • whether or not to use the uniqueness of the day (Tuesdays compared with Tuesdays, Wednesdays with Wednesdays or not)
  • permissible deviation rate

Now we will model the following situation. User111 deletes about 20 files on Mondays daily, about 40 on Thursdays. We create a rule that contains a unique combination of src.user.name + symptoms.id, set the delta to 40% and specify the accounting for the uniqueness of the day of the week. Baseline begins to take into account the number of unique ligaments src.user.name + symptoms.id by day of the week. All users and other symptoms.id get here, including starting services, entrances, launching applications and others. Suddenly, the user user111 or user444 does not delete 20-30 files as usual, but 200 per hour. The analyst sees this deviation, forms the event and sends it to the correlation. The correlation, taking into account possible clarifications in the rules, forms an incident, where the keys are src.user.name + symptoms.id (only the value will be approximately “user111 + delete_files”). In this case, this rule analytics will also look for other unique bundles in this context. For example, "Admin + unsuccessful login", "Admin + configuration changes" and so on. Thus, by creating a distribution with unique keys, we cover a fairly large amount of cases. And no matter what happens. This can be frequent crash of applications, the number of sent emails, the number of access denied attempts, and much more! There is no need to invent millions of cases when it can be described by a dozen other rules. After all, if a virus happens, an attack, failures - a small, but still a surge in the number of events is formed.

With the help of the rule with the keys "http.status.code + symptoms.id" it is possible to monitor, for example, the number of errors, the availability of the site, attempts to enter a forbidden resource, the status of the proxy server and much more. With the keys "hostname + symptoms.id" - from the number of unsuccessful attempts to the number of orders on the site.

The number of rules is not limited. The number of observed keys in the rule is up to 21. For correct operation of the module, the accumulated sample of 3 weeks is recommended.

For Baseline in the Analytics section there are also widgets for working with the module. They can carry any indicators for analyzing trends.

The ML module (Machine learning) works in automatic mode, without interaction and settings from the operator. The module works according to the Symptomatics (R) and looks according to the algorithms laid down by the aggregates of the weights of symptoms in the context of objects (hosts, users, services, etc.). The module has its own training individual sample, accumulated during the work of the module. In case of accumulation of critical weight in the context of an object (frequent repetition of a critical event, a flurry of critical or non-critical, prolonged repetition, multiple distribution), an event is generated and an incident is formed through the correlation process.

It is also possible to connect a custom PMML (Predictive Model Markup Language) model for the ML module.


Assets

Assets - section of IT assets. The asset structure is predefined, but can be changed by the user. Filled in real time from events. These are Windows / * nix events, traffic events, from monitoring systems and others. Events from an asset can bring information about installed software, patches, OS versions, services, and processes. Events from network traffic - which applications are used, browsers, including portable software, as well as information about the ports and protocols used. Scanners like nmap - information about open ports, services. Arp scanners - about hardware. All data comes in the form of events on the analytics module and forms assets in real time.

For example, in Windows Application log / System log information about installed software, patches is recorded and events are sent in real time to analytics. If such software is already in the list on the asset, its last detection time is updated. If not, this software is added to the asset, version.

A user connects via a network to a remote server via ssh - the network application sees this, sends information about the software used for the connection and information about the remote service.

To increase information about the asset and the environment in RuSIEM there are tools:

  • WmiSoftStat agent module that collects, both locally and from a variety of specified hosts without an agent-based method, information about installed software and Windows patches
  • HashLog agent module that collects information locally about processes and their hash sums
  • nmap scan on specified range and with parameters
  • arp_scan collecting data about devices connected to the network
  • a network sensor that collects information about: network connections, certificates, DNS requests and responses, http requests, DPI for some of the main protocols used, information about files transferred over the network, and so on.

It is possible to connect any "talking" source that brings useful data. Of course, such events can be operated on the level of the sample and the correlation rules and reports.

In addition to filling assets, there are a number of processes:

  • Vulnerability detection according to assets with a vulnerability base in real time. In the case of finding a vulnerability - the essence of the identity and the incident is formed
  • feed check
  • new asset alert
  • bonding assets

To limit the number of assets - set the boundaries of the infrastructure. And for identification, the criteria for identifying assets are set. In the system settings are set parameters of the obsolescence of assets.

For fast and convenient work with assets, there are static groups that allow multi-nesting and dynamic groups with formation conditions. For example, it is possible to create a dynamic group with a condition on the open port 22 or with the presence of a specific TeamViewer service and this group will always contain the current list of assets by criterion.


Intelligence feeds

The feeds (intelligence feeds) contain ip, url, fqdn, sha1, md5 threats and potentially dangerous objects: malware, exploits, phishing, file share, tor exit node, proxy and others. The event feeds are reconciled in real time in the analytics module. In case of coincidence, an event is formed and an incident is formed through a clarification in the correlation rule. Lists are updated automatically as part of technical support.

You can add custom values one by one or in bulk. Import of third-party feeds is possible.

Only the main features of the analytics module are described superficially. Opportunities are constantly expanding. Any questions? Contact us support@rusiem.com