Evolution of Logging and Enrichment Needs [Оголяемся технологически. MaxPatrol SIEM]
This is a series of articles about how technologies for effective cybersecurity are arranged from the inside. Using MaxPatrol SIEM as an example, we will tell you about the pipeline, the specifics of selecting sources for the knowledge base, about enrichment, correlation, normalization of events: in general, about everything that is under the hood of our SIEM.
The evolution of log processing needs and capabilities in SIEM systems does not stand still. And today, Ivan Prokhorov, head of the MaxPatrol SIEM product, and Petr Kovchunov, who writes the expertise for this product, will analyze our response to this challenge.
When we designed our product, we clearly understood that the need for simple log analysis or detection generation is not all that is needed for security. Having directly rejected the idea of making “another SIEM”, we dug deeper and at the architectural level built into the product functions that allow the solution to be organically and seamlessly implemented into the company’s information security system and provide it with practical results.
Since this is the first article in our series, it would be logical to start with a brief dive into the past and talk about the evolution of log and alert processing needs in SIEM systems. This historical excursion will help us understand how companies gradually realized the importance of analyzing this data and how the idea of it changed over time.
Logs about logs, or a brief excursion into history
Initially, the need to solve basic problems of consolidation, long-term storage and management of logs to find problem areas in information systems led to the emergence of log management class systems (if you want to learn more about this, you can listen to the whole story on our webinarbut here we will limit ourselves to a brief reference).
Gradually, it became clear that such tools could actually help identify security-related issues: for example, finding and consolidating information about failed login attempts or account lockouts.
Thus, based on log management class solutions, the first SEM and SIM systems appeared, which provided basic data processing tools for solving information security problems (basic detections, enrichment) and could be used by both information security and IT departments.
But these first SIEM systems did not solve the problem of high-quality real-time detection of incidents within a given infrastructure and increasing transparency for the operator of information security events occurring in the infrastructure.
This is how a useful SIEM appeared – a solution with expertise and attack detection technologies. These are solutions that work exclusively “on detection”. The very tools that allow employees of the information security and SOC departments to ensure monitoring and management of information security events.
Solutions of this class are difficult to use and often have a high entry threshold. And integrations with external systems, allowing to expand the functionality of SIEM and increase the efficiency of the operator, are limited by the complexity of customization for information security processes and low productivity. One such example is the analysis of the flow of events collected from Windows, using the enrichment of events with GeoIP data and subsequent correlation of the “suspicious login” type.
What should an effective SIEM be like?
Information security specialists gradually became aware of their needs, and the methodology for building protection itself changed significantly. Now, having a product that allows you to detect and analyze events is only part of the success.
The following questions came to the fore:
understanding the infrastructure in which information security needs to be built;
connections “data source – data control – data analysis – detection”;
high-quality, complete detection and subsequent response;
methodological construction and provision of information security.
In addition to the above, in our opinion, a high-quality SIEM should maximally and effectively ensure practical effectiveness in terms of ensuring information security through monitoring logs and alerts and analyzing the infrastructure. The entry threshold should depend on the operator's qualifications (that is, we are talking about a certain adaptability). A high-quality SIEM should provide visibility of what is happening in the IT infrastructure, ensure control over the completeness and quality of information collection.
An effective SIEM must contain the context required by the operator, i.e. methodological and expert assistance for each incident: why the system reacted to it, what measures need to be taken and how to mitigate possible risks. In addition, such a SIEM should be able to be organically integrated into other security systems, for example, integrated with EDR class solutions or act as a meta-product sensor, such as ours MaxPatrol O2.
Together with my colleagues, we tried to implement all of this in our MaxPatrol SIEM, which we now propose to discuss in more detail.
How events are processed
I suggest taking a look under the hood of MaxPatrol SIEM and seeing what's going on there and what unique solutions we've applied in our development. The diagram is quite high-level, but it's good enough to get an idea.
The diagram shows the event processing pipeline in MaxPatrol SIEM. Let's pay attention to several aspects. First of all, we have the ability to organize the collection of both agentless and agent traffic. This is especially important in terms of the fact that data collection is separated from the process of its processing.
The second point I would like to emphasize is the connection with assets (read – resources on which the company's work depends) and asset-centricity, which is laid down at the architectural level and built into our pipeline. Why is this done? Thanks to such architecture, we enrich asset data with information from analyzed events, enrich events with asset data, increase the transparency of what is happening and see how the attack is developing and where the connection between assets and information security events is – this way you can detect a threat much faster and respond to it.
In addition, we note the feedback that is present in the diagram. It shows that we can send already correlated events for additional enrichment and use information from external sources. For example, information from threat intelligence systems with a set of indicators of compromise, data on assets or logins and whitelists to minimize false positives. This increases the effectiveness of the analysts who use MaxPatrol SIEM.
So, we have talked about the event processing pipeline in general terms and now we will examine in more detail the stages of normalization, enrichment and connection of sources.
Event Normalization and Object-Oriented Field Schema
Normalization is the first stage that any event will face after SIEM detection. The fact is that all incident messages are received by the system in different formats and are designed according to different standards. In order to conduct an analysis, they are usually brought to a common format and appearance, which is called normalization. How is this process different from what other solutions have?
One of the main features is that the normalization rules are separated from the collection process. No matter how the incident got to MaxPatrol SIEM, if it matches the rules, it will be normalized. And no matter how many such sources there are in your infrastructure, they will all be processed.
The next feature is the object scheme of event fields. It allows, using normalization formulas, to place data in absolutely any format, from any source, with varying degrees of “completeness”. Moreover, incidents are not simply placed, but placed in a form convenient for the analyst. As it seems to us, transparency and clarity for the user distinguish our model from the popular CEF (Common Event Format). For example, by the name object.process.name you can already understand that we are talking about the name of the object process for this event.
What you have in front of you is, in fact, the same object-oriented field scheme: a data set that represents information about any event in the system that our SIEM monitors. It is grouped into object blocks, for example, it has a block about a subject, where the concept of a subject is defined, what it is, and its attributes. These attributes, in turn, have nested attributes.
And this is what a filled-in field diagram of a normalized event looks like. As you can see, the fields are sorted by semantic features: we can look at the beginning of an event, quickly identify four key fields — subject, action, object, status — and understand what happened. If we look at all events from beginning to end, we get a complete picture of the incident.
Object-oriented model or CEF?
Since we've touched on this topic, let's try to understand it in more detail. Of course, we can say that the CEF format is enough for basic tasks, but what does an object-oriented event field scheme give? The main advantage is that it reduces response time, because it does not have a huge number of fields with just a message ID, like cs1 in CEF, which does not say anything by itself. And to understand what kind of incident you are dealing with, you need to look at the label (cs1Label), the actions and their specification. Since we are directly responsible for connecting sources, we can say with confidence that in the case of CEF, this takes a huge amount of time. On the other hand, looking at the named data scheme, you immediately understand what is in the field and why.
One of the key advantages of this scheme, in addition to its organization, is the large number of Enum fields. This means that we have a list of predefined values: for example, the “status” field has three predefined values - “success”, “failure” and “in progress”. If we want to write a rule, it is enough to select the desired value from the ready-made options. And even when writing in the eXtraction and Processing (XP) language, we get a kind of analogue of cubes – predefined values. The more such standard “cubes” we have, the simpler and more unified the entire process of event processing becomes, including search, post-processing, analytics and writing code.
SIEM and Content Writing
There are three ways to write code in our knowledge base.
XP language. We write in our own language, the XP language. This is our internal DSL, which allows us to write all the SIEM code, from normalization to enrichment, correlation, aggregation, table lists — everything that we have involved in the event processing process. We use this method when we need to fine-tune the SIEM. For example, when it comes to XP macros, i.e. predefined functions that can be used countless times without the risk that editing or copy-pasting part of the data will disrupt the entire process.
Special plugin for Visual Studio Code. If you prefer to work in Visual Studio Code, we have a separate plugin that allows you to quickly commit changes, and a beautiful application with a graphical shell PTSIEMSDK GUIin which you can write and debug code.
Graphics editor. The third method is a schedule, which allows you to quickly assemble code that you can run and it will work. This method is best suited for creating high-level content, rather than for fine-tuning the system.
Information security incidents and how to deal with them
Another feature of MaxPatrol SIEM is its omnivorousness, the ability to work with events of absolutely any format. If the source was able to transfer data to the system, then SIEM will normalize and process it in any case. For example:
Text string. Events in the format of arbitrary text strings like Syslog or TEXT, which will be parsed using tokens. You won't even have to react to regular expressions.
Tabular databases. We also support tabular format events. The TABULAR keyword allows integration with absolutely any data collected by a SQL query from the database.
JSON. The JSON format is used for integration with systems that can pass event information via API.
Event Log. A separate EventLog format is designed for integration with complex multi-level Windows logs. It allows for easier analysis and parsing of events sent by Microsoft products.
XML. The format is designed for integration with legacy systems. It is suitable for companies that have not yet switched to logging in the more “trendy” LOG or JSON format. It gives us that very backward compatibility: the more systems our SIEM can support, the better.
You may ask, what to do if events containing JSON come via syslog? In our experience, such a situation occurs with “enviable” regularity, and there are several common cases.
This happens, for example, when the system architecture has a forwarder — a node that receives messages from different sources. It converts them into syslog format and sends them to SIEM — as a result, events arrive as a text string with a payload of a different format in the middle.
A common case is “communication” with cloud APIs. Only there everything is usually the other way around: JSON comes to SIEM, inside of which another structure is embedded, for example, a string that describes the status or response of the module.
A more difficult case is when multi-level structures are nested inside each other. For example, a single huge JSON is received, inside which are smaller events that contain fragments of data for separate parsing.
In all these examples, we need the whole information in one event, and we can nest incidents and subformulas inside each other, like a Russian doll. This, in our opinion, is the advantage in productivity and efficiency compared to other SIEMs. The nested formula does not exist in the context of all the expert normalization rules from the knowledge base, but only within the current rule. This means that we do not need to write new normalization formulas and take on additional workload.
Enrichment
Of course, simply monitoring normalized events is a difficult and time-consuming task. Another problem arises: sometimes the source itself can send events that lack context.
Imagine that you work with the 1C system, which sends you alerts. You receive a notification about an event that a certain Windows user has logged into 1C. You have a Windows username and a 1C login, but for all subsequent actions, 1C does not log the Windows username. This is where the enrichment mechanism helps us see the full picture.
Real-time response is also triggered here. Every time a user logs into 1C, say under the name “administrator”, the data about his Windows account is recorded in a table list and linked to the 1C account. Until a new login occurs and the context changes in real time, all actions on behalf of the “administrator” will belong to him. This way we will be able to understand who and from what machine created a payment document and, for example, track a remote login.
Enrichments can also implement other functions. For example, enrichment rules can work with our database. They can accumulate statistics and, for example, when rules for detecting scanning attempts or brute force attacks are triggered, this data will be included in a special table list.
In addition, enrichment rules allow us to exclude false positives. It is not always possible to write a correlation rule that would always trigger only on illegitimate activity. There is a huge layer of specific solutions that trigger monitoring systems.
That's why we implemented a mechanism automatic whitelistingwhich allows you to analyze triggering and accumulate “experience”. That is, if the same type of messages come from one node frequently and regularly, then over time they stop being registered and causing the correlation rules to be triggered. At the same time, if an intruder tries to interfere with the process and obviously changes it, the SIEM will sound the alarm. We covered this topic in detail in the webinar, where we analyzed the process of responding to false positives of MaxPatrol SIEM rules, technical aspects of implementing the mechanism for working with exceptions, and also talked about the allocation and subsequent use of compromise identifiers. Watch link.
Event chains
Another option for using enrichment rules is to build process chains. Usually, an event does not appear out of nowhere, it has some parent process. This connection helps in investigating incidents. For example, the console launch itself is not something strange for the operating system, but if the console is launched after opening a .docx document, then this is already a reason to be wary.
That is why MaxPatrol SIEM has a mechanism for forming process chains, which checks at each process start whether there is data about this process with the corresponding identifier and “parent” in the table list. If the process is not there, it adds it there and adds it to the existing chains. This is how SIEM forms a chain of process starts and places it in a separate field object or subject process chain.
We have analyzed how this approach works in practice. in this webinarwhere we looked at specific examples of our work with real cyberattacks.
Conclusion
We are convinced that an effective SIEM system starts with ensuring the completeness and quality of event data collection. This way, the analyst can save time and get full normalization, enrichment, and generation of detections of known and unknown anomalies. An effective SIEM system is based not only on static detection of known attacks, but also on detection of unknown attacks and anomalies. This is a system that can suggest actions to be taken after detecting an incident. But that's not all. What other product features make SIEM an effective solution? We will talk about this in our next articles.
Ivan Prokhorov
Head of Product MaxPatrol SIEM, Positive Technologies
Petr Kovchunov
Head of MaxPatrol SIEM Knowledge Base Team, Positive Technologies
