Out of the box: alienable correlation mechanism

Eva Belyaeva, Security Vision

Introduction

In this article, I would like to tell you how you can solve a standard information security problem in a non-standard way, by borrowing a mechanism from another solution.

Probably, for most information security specialists, the words "correlation rules" and "correlation engine" are firmly associated with such a class of solutions as SIEM. Probably, this is because this is where they are used. Here I would like to show you that there are such tasks in information security that can be solved not only in the usual way, but also using the logic of correlation rules.

Applying rules outside of SIEM

Reusing well-known mechanisms can be compared to the developer's approach - it happens that we really like a certain library or method in the language, and we strive to solve any emerging problem with this method. Sometimes this is effective, sometimes not so much, but here are 7 examples of using correlation rules outside of SIEM where it really worked.

We have already successfully applied some of these solutions in our products and actively use them.

What is the correlation rule, if simplified?

First, let's agree on what exactly we mean by this and try to depersonalize this term. Rules are not only about incidents and security events, it's more about the fact that we have a set of properties and attributes that we can connect with a simple or complex logical condition in order to then draw a conclusion. The conclusions can be anything: to make or not to make a decision, to launch a process, to escalate a request, and much more.

The essence of the alienable logic of correlation rules is that we have the opportunity to make some conclusion based on properties and conditions.

We found the following clusters of application of correlation rules where they really helped us:

• ACS TP: search and confirmation of impact on the system.

• SOC: scoring for UEBA and macrocorrelation.

• SSDLC: Rules for Certifying and Managing the Secure Development Process.

• SGRC: risk forecasting, autocompliance, calculation of IRR and criteria for launching recovery plans.

When we first depersonalized and applied the "alienated" mechanism of correlation rules, it was as if a piece of the puzzle fell into place. However, in the process of solving these problems, it was not easy to come to this and it was far from obvious.

Let's look at these clusters in more detail using examples.

ACS TP: application in industry

The application of rules in industry is associated with monitoring the production process and identifying violations in it. These can be both objective failure factors and the search for some external influence. In this case, such checks can be applied and configured in traditional SCADA systems, but in general these systems can be different, including those not related to each other.

What problems does the application of rules solve? Here they are:

• Building a data flow on the stability of production assets where it is impossible to install information security tools.

• Obtaining conclusions about the fact of influence through indirect signs of work stoppage.

• Adding correlation rules to SCADA with the ability to transfer engine control to the technologist.

In this case, a single correlation engine can provide a single console in which you can uniformly create rules for monitoring the production process, link different flows both with each other and with flows of information security and IT systems.

To make it easier, let's give two examples:

Refrigerators and cargo transportation – let's imagine that discrete data collection on temperature conditions is carried out from them. In case of a violation of the conditions in X minutes, an alert is generated Y times, based on the result of which it will be possible to adjust the driver's route, create a ticket, etc.

The second example - let's say there is a raw material storage system; in this case, we receive data streams on temperature and humidity from it. Firstly, we can already receive alerts if this data goes beyond the permissible limits. If we can link this data with the information stream from the ACS or video surveillance, we will be able to rank these triggers by criticality when recording alerts from related systems, launch automated response, etc.

The point here will be to give the technologist the ability to control the search for errors in the technological process in a single window mode.

SOC: scoring for UEBA

Using correlation rules to calculate scoring threshold exceedances was our very first attempt at reusing this logic somewhere outside of SIEM.

We have a boxed UEBA solution, the purpose of which is to find behavioral anomalies for users or devices. What is interesting is that this product was initially used and presented as a solution to a completely different problem - it was necessary to compensate for SIEM and its "imperfect" correlation rules, because an anomaly cannot be simply calculated in advance.

Why did we add rules here? The thing is that we had to solve not the problem of how to identify an incident or a suspicion of one, our problem was rather mathematical.

Within UEBA, we accumulate various alerts for each object. Once enough alerts have accumulated over a given period of time, when the threshold is reached, we can already generate a traditional incident based on this data.

We had to modify our correlation rules engine because a simple rule – X times in Y minutes – was not enough. Each alert has its own specific weight, and we need to calculate not the number, but the sum of the weights. As a result, the rule turned out to be as follows: if the sum of the weights X in Y minutes exceeds the threshold, then we generate an incident.

SOC: macrocorrelations

Let's continue solving problems related to incidents. Correlation rules can also be successfully applied in SOAR, because we have found several needs there:

• Building additional links and searching for similar incidents. The point is that rules can not only identify an alert or an incident, they can correlate two entities with each other - that is, we can understand, for example, how similar two incidents are to each other. Usually, analysts do this task by reviewing incidents manually; it is also impossible to hardcode signs of similarity somewhere in advance, because the flow can be as diverse as you like: the infrastructure, the composition of the information security system, and the incidents being detected change. The correlation engine allows you to centrally connect incidents from one point, manage the logic of matching attributes, while simultaneously providing the ability to flexibly change everything, be it a time range or the attribute itself: a domain, an account, or their context: groups of servers and users.

• Search for attacks and aggregation of several incidents into a single KillChain chain. In addition to similar incidents, it is also possible to identify incidents that are sequentially related: that is, identified incidents of one attack can, for example, be arranged in the order of MITRE techniques/tactics, giving the analyst more context for the investigation. Thus, we get a new object to work on, and we can also find markers of the behavior of attackers.

The whole point of using correlation rules in SOAR is that we apply the engine to already identified incidents; our goal is to relate them, enrich them with new information, and determine their criticality.

SSDLC: Secure Development

Let's turn our attention to a related area - secure development.

First, let's talk about a rather narrowly specialized example - certification. Anyone who has tried to automate this process on their own understands how difficult it can be both at the very beginning of development and during application. If we talk specifically about dynamic testing, there is a regulatory body that tells us how to do it correctly and what parameters to pay attention to. In order to receive a certificate, you just need to provide evidence that the testing was necessary and sufficient.

Let's say you have a fuzzing farm where fuzzer instances are running, and at some point you need to stop them when conditions are reached. What could these conditions be? Let's consider the most basic one - X hours without new paths for triggering. It would seem, what do correlation rules have to do with it? But when you have a lot of instances and a very large data flow, doing it manually is - to put it mildly - difficult. It can be automated, but this will be a decentralized approach, and the conditions may change over time. To simplify your task and add the ability to flexibly manage this, you can do it, on the contrary, centrally, through correlation rules, to which you can add new conditions or adjust old ones.

Another example is monitoring the build and deployment pipeline. We can write correlation rules that will analyze the scope of changes made to additionally run checks for unit tests or manual testing.

By monitoring errors in the build or deployment process, violations and deviations from time frames, we can identify signs of external influence on the pipeline and create an alert for subsequent verification of the process. In a similar way, an attack on the supply chain can be detected.

As you can see, we are moving from a small specific problem to a global approach and working with the process itself.

SGRC: calculation of KIR

How are key risk indicators calculated? We can calculate them based on information received from related systems. Let's say your organization calculates KRIs based on information from incident, asset, and vulnerability management systems.

If your organization has a lot of subsidiaries, affiliates, subsidiaries, or not many people who process this data, it is difficult to assess the impact of this data flow on KIRs in real time. But what if we ourselves contact these related systems for information? For example, we will receive incidents and their types, scanned servers and vulnerabilities on them, and from assets - whether there are new devices.

Based on this, by applying the correlation rule, we can both calculate the KIR and check whether we have exceeded the previously set threshold value.

While working on our products, we asked ourselves the same question: how could we make life easier for the customer and is it even possible to include a formula in the boxed solution that would help track changes in the KIR. Then we simply realized that we already have the tool - it is enough to simply reuse the correlation rules.

SGRC: Risk Forecasting

Let's go even further. The IRI is only one link in the chain of what constitutes the overall risk level in an organization. In addition to risk indicators, the overall level can be affected by business processes, systems and their components. In this case, we can move from calculating indicators to forecasting - as soon as the IRI or the criticality of a system changes, we can immediately say in which direction the overall risk level will change.

SGRC: autocompliance

For us, automatic compliance is a process of automated, continuous data collection and continuous calculation of indicators, as a result of which the customer receives the degree of its compliance with external or internal standards not once a quarter during the next audit, but in real time.

In this case, the application of the correlation engine can be performed in two directions:

• Creating alerts when specific indicators or their combination are exceeded allows you to promptly correct the situation before the actual audit.

• Consistency check. Since data can be entered both automatically and manually, there are often cases of errors or incorrect information being entered. Correlation rules will allow you to check the indicators, determine whether they conflict with each other and whether the assessment is correct. A classic example is when the continuity assessment and RTO, RPO and other indicators for components should not differ significantly from the assessment, which, for example, is given for the information system as a whole.

SGRC: Business Continuity

Continuing with the continuity theme, let's talk about another business challenge. What about recovery plans and launching tasks for it?

Let's say you have some kind of emergency. At the same time, you have several plans that outline what actions to take and by whom. How do you know when to start working on this plan and how to choose it from several? And an additional condition is to automate all of this.

Sometimes every minute counts if the system is very critical. Here, too, correlation rules can help us. Imagine that your organization has a website running on a server; and at some point, you receive an alert that this server is unavailable for some reason. What should you do? There are several recovery plans for this server: contacting the provider in case of connection failures, or maybe you need to move to another data center. Usually, making this decision takes a lot of time and coordination.

To solve this problem, it is enough to tie in a correlation engine, specifying the conditions for automatic selection and launch of a plan: for example, accounting for the time of unavailability, searching for requests from the IT department for preventive maintenance. Perhaps an hour is not very critical for you, but three is already a lot.

Conclusions

We spent a lot of time researching the problems we described earlier. Although they can be solved in other ways, in our case the most effective was to reuse what we had already developed.

Try to look at a problem that has not been solved for a long time or requires large expenses from a different angle. Perhaps , the application rules correlations Same to you will help.