IT201800005412A1 - System and method for the creation and verification of behavioral baselines. - Google Patents

Description

"System and method for the creation and verification of behavioral baselines"

DESCRIPTION

The present invention relates to a system and a method for creating and verifying behavioral baselines, particularly, though not exclusively, useful and practical in the field of corporate or infrastructural IT security.

In this description, the term "user" indicates a physical person in flesh and blood, who uses one or more computer systems included in a more less or complex corporate information system and who owns one or more accounts, while with the the term "account" indicates an entity registered and authorized to access one of the computer systems, typically defined by username and password.

In the present description, the expression "behavioral baseline" indicates the behavioral model or profile of at least one entity (hereinafter we will consider users as entities to be observed, even if the present invention can be generalized to consider any generator apparatus as an entity emissions in a broad sense), consisting of the set of actions and operations that the same user or device has performed and therefore would perform in a normal situation (ie in a "basic" situation).

Today, corporate systems and networks are particularly difficult to protect from cyber threats due to a number of factors, including: the ability of attackers to operate from anywhere in the world, the links between the Internet and corporate systems, and the difficulty of reducing vulnerabilities in complex computer networks.

Furthermore, cyber threats to critical infrastructures (such as power plants, airports, hospitals, and so on) are of increasing concern, as such infrastructures are subject to increasing risk due to increasingly sophisticated intrusion attempts. As Information Technology (acronym IT) integrates more and more with the operation of critical infrastructures, consequently the risk of large-scale or high-impact events that could cause damage or disrupt services on which the economy depends. global and the daily lives of millions of people.

In light of the high risk and potential consequences of cyber attacks, strengthening cyber security and resilience has become an important security mission for all businesses and governments.

As for businesses, the rapid detection of cybersecurity threats is critical to preventing compromise of their IT systems and data theft. Many of these data are very important commercial and / or personal information, or even industrial secrets, and are not intended for disclosure or public viewing and any exposure, theft or manipulation of this data could cause economic or reputational damage to the organization and individuals. themselves. A large number of these cyber attacks, as reported by the media, have involved fraud, data breaches, intellectual property or national security.

Enterprises typically use a layered, compartmentalized network topology to separate the internal network from the Internet. Workstations and servers are generally protected from direct access via the Internet or other external networks by a proxy server; Internet traffic is typically terminated in so-called "demilitarized zones" of the corporate network and incoming traffic is filtered through one or more firewalls.

Normally, attackers focus their attacks on elements exposed to the external perimeter of the corporate network, and there are many solutions that ensure perimeter security. However, the boundaries of modern corporate networks are no longer so well defined; the increase in the use of cloud applications and the use of mobile devices have made the corporate network more fluid and dynamic, with boundaries difficult to identify.

Once attackers have breached the perimeter and entered the corporate network, they typically operate under the guise of an internal user, stealing an existing user's account or creating a new one. They use legitimate accounts or trusted systems, and can move freely in the corporate network by exploiting the lack of effective supervision of the internal network.

Currently, various security solutions are known which have the ability to detect potential malicious activity by a user. Most known security solutions use a static and reactive approach, looking for known attack signatures to identify and notify the presence of similar attacks.

However, these well-known solutions, which leverage a signature-based threat detection approach, are not without drawbacks, including the fact that developing signatures for new threats requires in-depth analysis of a system. infected, thus wasting a lot of time and resources, which are still insufficient to deal with rapidly evolving threats. Furthermore, signatures do not adapt to the lightning-fast changes that threat vectors undergo. Finally, signature-based approaches are ineffective for so-called zero-day attacks, which exploit unknown and therefore unavailable vulnerabilities to detect threats.

An evolution of this signature-based threat detection approach is the detection of internal attacks by manually constructing various profiles of "normal" user behavior, detecting deviations from these profiles, and estimating the threat risk of these anomalies.

A common approach is to build a baseline of user behavior (or more frequently of a user account, or of an IP address among those used by the user, thus incurring the limitations described above), in order to "learn "operations that the user normally uses.

Generally a time window of a certain predetermined length is fixed. After the learning phase, systems based on machine learning algorithms consider deviations from this baseline as anomalies.

The drawback of this approach is that the order in which operations are performed within the window is completely neglected. As long as the operations have already been performed in the past, and as long as the frequency is respected within a certain mean and variance, the user's behavior will appear to be consistent with his baseline in the analyzed window.

However, these well-known solutions, which exploit a threat detection approach based on profiles of normal behavior, are not free from drawbacks, including the fact that the construction and configuration of profiles that precisely characterize the behavior normal behavior of a user is very difficult, human behavior being extremely changeable and highly variable.

Additionally, using such profiles for behavioral anomaly detection can produce erroneous results and lead to many false positives that overwhelm cybersecurity analysts. Balancing an overly permissive detection method, at the risk of missing a real threat, and a tightly meshed detection method that floods security analysts with warnings, is a difficult trade-off.

To this we must add the further drawback introduced by the currently widespread custom of using partial information on the user's activities as input data. In particular, it is usually not possible to attribute to the same user the emissions from several of its accounts, with the result of a reduction in the correlation capacity with respect to the totality of its activities. In fact, if you are not aware of the fact that two activities are the work of the same user, it is evident that it is impossible to effectively detect all the possible patterns of fraud.

The aim of the present invention is to overcome the limitations of the prior art described above, devising a system and a method for the creation and verification of behavioral baselines based on activities or sequences of activities carried out by the entities (including both users and devices) that operate within a corporate network, in order to identify any behavioral deviations that could represent harmful activities and cyber threats.

Within this aim, an object of the present invention is to devise a system and a method for creating and verifying behavioral baselines which allow a dynamic, adaptive and proactive cyber threat detection method, in order to counteract the external and internal threats in constant evolution and unknown a priori.

Another object of the present invention is to devise a system and a method for creating and verifying behavioral baselines which allow a method for detecting behavioral anomalies which is not guided by pre-established signatures or policies, but which adapts to the behavior entities and the use of company information systems.

A further object of the present invention is to conceive a system and a method for creating and verifying behavioral baselines which minimize false positives, thus increasing the effectiveness of the response actions to an attack or a cyber threat.

Still another object of the present invention is to devise a system and a method for creating and verifying behavioral baselines which are not limited to carrying out correlations on the activities of the accounts, but which carry out correlations on the activities of the individual physical user, regardless of the number of accounts assigned to the same.

Not least object of the present invention is to provide a system and a method for creating and verifying behavioral baselines which are highly reliable, relatively simple to produce, and at competitive costs if compared to the known art.

This task, as well as these and other purposes which will appear better later, are achieved by a system for the creation and verification of behavioral baselines, comprising a central processing device comprising a control unit and means of storage of enriched data, connected and in communication with a plurality of target apparatuses and with an Identity & Access Management or IAM apparatus, characterized by the fact that said central processing device comprises:

- a Markov module, configured to construct a matrix of Markov transitions suitable for tracing the transition from a first activity to a second activity temporally subsequent, both said activities being defined by enriched data and carried out by an entity on said target apparatuses;

a baseline module, configured to calculate a plurality of individual z-score values, one for each single activity and entity pair, and a plurality of collective z-score values, one for each single activity and time window pair;

- a historical anomaly verification module configured to evaluate the presence of an anomaly in the behavior of said entity with respect to an individual space, or with respect to the history of the past activities of said entity, on the basis of said plurality of individual z-score values ; And

a peer anomaly verification module, configured to evaluate the presence of a behavior anomaly of said entity with respect to a collective space, or with respect to the current activities of other similar peer entities, on the basis of said plurality of collective zscore values.

The intended aim and objects are also achieved by a method for the creation and verification of behavioral baselines, by means of a central processing device comprising a control unit and enriched data storage means, connected and in communication with a plurality of apparatuses. target and with an Identity & Access Management or IAM apparatus, including the steps that consist of:

- constructing a matrix of Markov transitions capable of tracing the transition from a first activity to a second activity temporally subsequent, by means of a Markov module included in said central processing device, both said activities being defined by said enriched data and carried out by a entities on said target devices;

- calculate a plurality of individual z-score values, one for each single activity and entity pair, and a plurality of collective z-score values, one for each single activity and time window pair, by means of a baseline module included in said central processing;

- assess the presence of an anomaly in the behavior of said entity with respect to an individual space, or with respect to the history of the past activities of said entity, on the basis of said plurality of individual z-score values, by means of an anomaly on history verification module included in said central processing device; And

assess the presence of an anomaly in the behavior of said entity with respect to a collective space, or with respect to the current activities of other similar peer entities, on the basis of said plurality of collective z-score values, through an anomaly verification module on the peer included in said central processing device.

Further characteristics and advantages of the invention will become clearer from the description of a preferred but not exclusive embodiment of the system and method for creating and verifying behavioral baselines according to the invention, illustrated by way of non-limiting example with the aid of the attached drawings, in which:

Figure 1 is a block diagram which schematically illustrates an embodiment of the system for creating and verifying behavioral baselines, according to the present invention;

Figure 2 is a flow chart which schematically illustrates an embodiment of the method for creating and verifying behavioral baselines, according to the present invention.

With reference to Figure 1, the system for creating and verifying behavioral baselines according to the invention, globally indicated with the reference number 10, comprises a central processing device 12, in short, central processor 12, connected and in communication with a plurality of target apparatuses 36 and with an Identity & Access Management apparatus 38, in short IAM apparatus 38, for example through a LAN local telematic communication network.

The target devices 36 are processors (for example of the server type), electronic devices, network devices, configured through software applications or the like, included in a more or less complex information system, capable of detecting, directly or indirectly, the presence of attackers and cyber attacks, and which therefore can be sources of emissions that it is interesting to collect as input data.

The IAM 38 device (from the English Identity and Access Management) is an apparatus configured to manage user accounts and the authorizations of these accounts within an information system, such as the one in which the central computer 12 and the target devices 36.

In particular, the IAM 38 device centrally manages the user accounts (typically represented by a username for each account), the security credentials (typically represented by a password or access key associated with the username of the account) and the authorizations that they check that account holders can access all and only the resources they are responsible for.

The central processor 12 comprises a control unit 14, a raw event collection module 16, an IAM status collection module 18 (from English Identity and Access Management), a data enrichment module 20, enriched data storage means 22, a Markov module 24, a baseline module 26, an anomaly verification module on history 28, and an anomaly verification module on peer 30.

The control unit 14 is the main functional element of the central computer 12, and for this reason it is connected and in communication with the other elements included in the central computer 12.

The control unit 14 of the central computer 12 is equipped with suitable computing and interfacing capabilities with the other elements of the central computer 12, and it is configured to command, control and coordinate the operation of the elements of the central computer 12. with which it is connected and in communication.

The raw event collection module 16 of the central processor 12 is configured to collect the raw data (ie "raw", not normalized) on the events recorded by the target devices 36 connected to the central processor 12, considering them as emissions from those same target devices 36. The raw event collection module 16 is further configured to normalize this event data by merging similar information under the same semantic name to make them groupable.

In practice, each activity of one of the target devices 36 corresponds to an emission. For example, among the emissions of the target devices 36 it will be possible to find the log file lines of SAP systems, DBMS Audit events, lines of the Apache httpd audit file, syslog events, and so on.

The IAM status collection module 18 of the central computer 12 is configured to collect data on the current status recorded by the IAM 38 apparatus, which manages the user accounts and the authorizations of these accounts. By doing so, an updated mapping of all user accounts on target devices 36 is obtained from the IAM 38.

The data enrichment module 20 of the central processor 12 is configured to cross-reference the raw event data from the raw event collection module 16 and the IAM status data from the IAM status collection module 18, identifying and grouping the raw events associated with a specific physical user, or more generally of an entity, regardless of the number of accounts owned by the same user.

Raw events always contain information about the user who generated the issue. Depending on the target apparatus 36, this information about the issuing user may include a source IP address, a hostname, a username, or a combination of this information. In particular, the username can always be traced back to a user thanks to the always updated mapping taken from the IAM 38 device.

By integrating all this information, the data enrichment module 20 goes back to the user who operates by means of a certain username, who is using a certain IP address or who is traced through a certain hostname.

Enriching the available data before analysis maximizes the correlation capacity. Usually a user, to access the computer systems, makes a login, an operation through which he is identified by the same system. Login takes place through the use of personal credentials, typically a username and password. The login is therefore the operation that allows the user to access his account on the computer system. This account, distinguished by a unique username, may have been configured by the system administrator to access all the functions offered by the system, or it may in turn be an administration account, or may have only a subset of the functions offered by the system. system.

However, it is common for a user to have several accounts spread across the various corporate IT systems. It is also possible that a user has more than one account on the same computer system, and therefore has the possibility of using the same system with different credentials (i.e. different usernames) and therefore different levels of authorization.

Computer systems, in particular corporate ones, often keep a log file or in any case a register in which they record the operations carried out by users on the system. At best, the user is tracked by means of the username with which he authenticated. As mentioned above, however, some systems simply report the hostname or IP address of the device used by the user.

The family of computer systems that track the actions of the physical user by means of his username is the best case scenario, since if you want to trace the physical user, starting from the log file or from the system activity log, the way to go it is relatively simple. In fact, it must be traced back to the account holder whose username was confirmed in the log file.

These systems, taken individually, therefore keep track of the actions performed by the accounts, and cannot trace the user who is operating with that account. As mentioned above, this information is present (see IAM 38 apparatus), but it is not the responsibility of the single system.

For example, in the case of the user having two accounts on the same system, the account operations would appear in the log file as a transcript of events associated with two different usernames. The fact that behind both usernames, and therefore behind both accounts, there is actually the same physical user operating is not directly deductible.

As mentioned above, further information on the assignment or ownership of the account is required to trace the information that both accounts belong to the same physical user. This information is contained in the IAM 38 device, and consists in assigning the various usernames to the respective physical users.

Therefore, the data enrichment module 20 is configured to cross account / user information, preferably in real time, in order to "enrich" the data relating to the activities of the accounts with the "context" information related to the user, and then use them in the data correlation phase.

This data enrichment operation, to be carried out before the analysis, drastically increases the quality of the data on which we work to identify anomalies, security incidents and finally patterns of fraud. The enrichment allows in fact to correctly cross all the events attributable to the same physical user, regardless of how many different accounts among those available to him he has used. This reconstructs a complete user context and maximizes the ability to correlate events produced by the user within the corporate infrastructure.

In the following, therefore, when we talk about operations carried out by a user, or activities carried out by a user, what is meant is precisely to have previously brought all the accounts of a user back to his real and unique identity.

As mentioned above, there are some computer systems that operate differently, not based on the account. This family of computer systems, in which we find, for example, devices and probes that deal with security at the networking level, report in the log file or in the activity log the hostname or IP address of the device through which the user is connected to the company network.

In a corporate context, however, it is possible to trace the assignee of the devices connected to the corporate network thanks to the existence of an asset management policy and some enforcement that limit the possibility of connection by means of unknown devices. We can therefore, once again, think of replacing the physical user with the IP address he used, as well as the hostname of his device. On the other hand, however, a physical user could use different hostnames or different IP addresses, even at the same time. Once again, being able to perform the resolution in real time, thus assigning the events related to the devices to the respective users before the analysis greatly improves the ability to perform correlations and detect anomalous behaviors in an effective way.

Let's consider the example of a user using three IP addresses at the same time. Events generated by these three IP addresses should be considered as sequential operations by the same user. If, on the other hand, we limit ourselves to the simple analysis of the events of individual IP addresses, and we resort to user identification only in case of anomalous behavior of a certain IP address, it is evident that a good part of the information is left out. In fact, any anomalous behavior that can only be found by adding the events of the three IP addresses belonging to the same user would go unnoticed if the IP addresses were considered individually.

Also in this case, therefore, we want to focus on the greater potential offered by carrying out this intersection of information between IP address / user or hostname / user upstream of the analysis, and not downstream of the same.

Users, in using company systems, therefore leave traces in log files and logs. As we have seen, however, the user with his name and surname does not appear in the log files, nor can there be a globally unique identifier. In the log files we find only references to an account, or to a username that the user used on that system. Or, in the case of probes and network devices, we will find references about the IP address or the hostname from which the user connected.

All companies maintain these logs of events, as there are precise regulations that require these logs to be collected and maintained for a number of years, in order to facilitate audits and forensic analysis (HIPAA, Sarbanes-Oxley, PCI-DSS, FISMA ). Otherwise, the company would incur compliance violations with respect to the aforementioned regulations.

These data are absolutely heterogeneous, since there is no common standard for multiple business systems. The activities, that is the events determined by the user's actions on the system, are tracked in a personalized and different way from system to system. However, there are some points in common, for example in almost all cases we will find, within the single entry relating to the single recorded event:

- a date relating to the event / activity;

- an entity that generated the event, or to which the activity refers (identified differently depending on the system, it could be a username, a hostname or an IP address);

an action, a description of the event generated, the activity carried out, an operation in a set of possible operations that can be carried out, or a recipient who suffers the event.

In any case, since there is a date, or more generally since the log files and the logs ordered according to a temporal criterion, it is always possible to carry out an analysis of the events following the order in which they were generated by the user's activity. .

The enriched data storage means 22 of the central computer 12, such as for example a database stored on suitably sized memory supports, are configured to store the data relating to each user and produced by the data enrichment module 20 according to the procedure described above.

By way of example, the enriched data storage means 22 can store data relating to the user John Doe, to the accounts associated with the same user identified by the usernames j.doe@acme.org and johnny@acme.org, and to the activities carried out by same user in the various computer systems.

The Markov module 24 of the central processor 12 is configured to construct a Markov chain, or rather a matrix of Markov transitions, capable of tracing the passage from one emission to the next, i.e. from one activity to the temporally subsequent one, both activities being defined by the enriched data and carried out by a specific physical user on the target devices 36. Clearly, depending on how many emissions are considered simultaneously, there will be a different dimension of the matrix.

The objective of the construction of the Markov transition matrix is to create an operational context within which it is possible to identify anomalous behaviors with respect to previously observed behaviors, that is to identify new activities or sequences of activities that deviate significantly from a normality defined by activities or sequences of activities observed during an initial period called learning or learning.

The data used by the Markov module 24 for the construction of the Markov transition matrix are defined emissions, corresponding to the enriched data stored in the enriched data storage means 22 of the central processor 12.

A corporate IT infrastructure (centralized in a single datacenter, geographically distributed in different locations, cloud-based or hybrid) includes electronic entities, which can be physical or virtual, interconnected by means of one or more communication protocols. Authorized users interact with these entities by means of some specific entities, i.e. end-user devices. Typical examples of entities are servers (local, remote, physical or virtualized), databases, network and security devices, workstations, smartphones, printers, IP cameras, and any other device that can be interacted with. 'infrastructure.

An emission is the single record of information concerning an entity, and can be produced by the entity itself or by another of the entities connected to the infrastructure. An emission is temporally characterized by a precise date (typically with precision in the order of seconds or milliseconds). An emission contains within it at least one reference to an entity as a "source", and at least one "event" or "action", or a more or less rigorous description of the event, measurement or observation at the time indicated. Depending on the context, the entity referred to as the "source" may be the subject performing the described action, or the object of the reported observation.

Typical examples of repositories, present in the company infrastructures, containing the emissions of the entities that make up the infrastructure are: log files, system logs, audit tables, syslog collector, WMI collector and Netflow collector.

In particular, the operation of the Markov module 24 is as follows. Suppose we have a certain number of U users who perform some tasks in a precise time sequence. Suppose we have users indexed by u = 1 ... U, activities a = 1 ... A, and time windows f = 1 ... F. These activities can be any sequence of events, surveys or measurements concerning the user. In general they are related to the user's emissions, and are considered in chronological order.

The Markov transition matrix describes a chronologically ordered sequence of user activities within each time window. Note that the term activity used in a generic way: an activity could mean having observed a certain emission, having observed two of them in a row, or having observed a particular sequence of complex emissions at will, to which you want to associate a specific activity.

The Markov transition matrix is organized in a three-index tensor A whose element Avaf defines how many times the user u performs activity a in the window f. Therefore, with the activities thus defined, we focus on the frequencies of the activities.

The time windows f are long Δt (for example one day). The learning period during which normal behaviors are defined is long T = FΔt (for example one year).

The activity to be monitored is each passage from one issue to the next. That is, given a sequence of events observed by looking at the emissions of a certain entity (for example a user) within a day, the Markov transition matrix is organized in such a way that the tensor A contains the frequencies with which the users u, each window f, pass from one issue to the next, thus carrying out activity a. If T is the total number of emissions observed, then we will have that, at most, A can be equal to T <2>, if all the ordered pairs of possible emissions are performed during the learning period.

During the learning period, the Markov module 24 constructs the three-index tensor Λ, whose element Auaf defines how many times the user u performs the activity a (i.e. passes from a certain emission and to another e ') in the window indexed by f. These frequencies of activities will constitute the benchmark against which any anomaly will subsequently occur.

The baseline module 26 of the central computer 12 is configured to analyze the steps between the activities carried out by a specific physical user, or more generally of an entity, by means of known machine learning techniques, starting from from the Markov transition matrix for each user u, for each time window f (for example one day). In particular, the baseline module 26 is configured to calculate a plurality of individual z-score values, one for each single activity and entity pair (such as a user), and a plurality of collective z-score values, one for each single activity pair and time window. In practice, the z-score values represent the probability that an activity or a sequence of activities of a specific physical user, or more generally of an entity, constitutes an anomaly of behavior. Therefore, this provides a quantitative index on the observed series of emissions.

This learning approach avoids throwing away, as happens in traditional analyzes, a lot of information useful for identifying the user, in particular relating to the presence of repeated chronological patterns. In other words, instead of just "learning" that the user usually carries out the operations "foo", "bar" and "foobar" during a certain time window, for example the baseline module 26 learns that the user always does "bar" once after executing "foo", and then does "foobar" once after executing "bar", ie it plays the pattern "foo", "bar", "foobar" in this precise order.

In this way an attacker who executed, always in the same time interval, "bar", "foo", "foobar" would appear in line with the baseline according to traditional approaches, while the present approach would be able to identify it as anomalous.

In conclusion, correctly recording the order in which the user carries out the operations, allows to build a probabilistic model capable of quantifying the probability that a certain pattern may or may not belong to the user. This is regardless of the probable presence of single known elements. In fact, the same operations (for example, the only authorized ones) could be performed using unexplored or very little used patterns, highlighting an anomaly where the operations do not change, but only the order of execution.

In particular, the operation of the baseline module 26 is as follows. Preliminarily, it should be noted that anomalous behaviors can be such with respect to a normality that can be defined in two ways: with respect to the past of the same user or with respect to the present of other users. Therefore, it is possible to use two distinct benchmarks: an individual one, comparing the user with himself in the past windows, and a collective one, comparing the user with the other users at a fixed time.

In fact, although the use of clustering and anomaly detection algorithms can help to skim the false alarms, limiting itself to taking into consideration only the user's "personal history" to outline an anomalous behavior, one would always run the risk of a "false positive". For this reason, the extension of the analysis field is also foreseen horizontally, with respect to other users, as well as vertically, on the past history of the analyzed user. In fact, using the data of users "similar" to the one taken in analysis, the baseline module 26 is able to calculate a z score value. On the basis of this zscore value, a certain user behavior may or may not be considered "normal" compared to the behavior of colleagues, in the same time window.

We start by comparing the user with his past, and then fix u = u *. For each activity a, i.e. for each ordered pair of emissions (e, e '), we can calculate the average and standard deviation of the frequencies of the observed activities, according to the following formulas, respectively:

These two quantities respectively express normality, i.e. on average how much the user u * performed activity a, and the unit of measurement of the distance from this normality that is tolerable in order to consider a deviation from this behavior as a reasonable statistical fluctuation.

In a completely analogous way, it is possible to compare the user with the other users, thus evaluating any anomalies not with respect to the past of user u *, but with respect to the behavior of other users, thus fixing a certain window f *.

By going to mediate no longer with a fixed user and varying the windows, but with a fixed window and varying the user, it is possible to obtain an analysis no longer of the individual space but of the collective space, in which not the same user is confronted each with his own past but users between them. The mean and standard deviation of the observed activity frequencies are calculated according to the following formulas, respectively:

Now suppose we observe in the test period a certain frequency ψ for the activity α of user u * in the time window f *. Assuming a Gaussian frequency distribution we can calculate how unlikely it is to observe φ with respect to the normality measures previously introduced. In particular, the zscore can be calculated with respect to the individual space and with respect to the collective space, according to the following formulas, respectively:

Under the assumptions of the Central Limit Theorem the variables z tend to a Gaussian as F or U increases, respectively. For sufficiently large F or U we can therefore associate to every z a probability for every φ. This probability is a measure of the single frequency anomaly observed during the test phase.

Note that the above is generalizable to emission sequences longer than two, at the cost of increasing the size of the tensor along the size of the assets, i.e. increasing A.

The module for checking the anomaly on history 28 of the central computer 12 is configured to evaluate the presence of a possible anomaly in the behavior of a user u, or more generally of an entity, with respect to the individual space, or rather with respect to the history of past activities of user u, based on the individual z-score previously calculated by the baseline module 26.

The module for checking the anomaly on peer 30 of the central computer 12 is configured to evaluate the presence of a possible anomaly in the behavior of a user u, or more generally of an entity, with respect to the collective space, that is, with respect to current activities of the other similar users called peers, on the basis of the collective z-score previously calculated by the baseline module 26.

In one embodiment, in the context of evaluating the presence of an anomaly, the anomaly on history verification module 28 and the peer anomaly verification module 30 use known clustering and anomaly detection techniques, such as the algorithm Rodriguez-Laio or ABOD (Angle-Based Oulier Detection), which in this context can be used in order to highlight possible anomalies in these z-scores.

By way of example, suppose that the baseline module 26 has calculated, for the reference time window F *, and after having learned the behavior of a user U * over a sufficiently long previous period, a sufficiently long z-score value raised in modulus to represent an anomaly. We therefore assume that we have received the report of a behavior that differs significantly from that considered normal by the anomaly verification form on history 28. At this point we can highlight and report that the user U * has carried out one or more activities, at inside the window F *, such as to make its behavior anomalous with respect to its usual way of operating.

Now suppose to use for learning the behavior of all users "similar" to U *, which took place only in the F * window. We therefore concentrate on the behavior of the group within the F * window only, evaluating the behavior of our user U * as a function of that of his own group, rather than through his past as done previously.

Also in this case the behavior of the user U * can be evaluated, but this time the baseline consists of the behavior of all the other users with the same window. These users were chosen only among peers, possibly through a dedicated clustering algorithm, so a certain homogeneity of behavior is expected with respect to selecting all users. The result of the anomaly detection algorithm will therefore indicate how anomalous the behavior of the user U * is for the period F * compared to what his peers did in the same period.

Since the user U *, in the example we are considering, has already been reported as anomalous with respect to his past, now we can confirm this anomaly also with respect to the group, or not.

If the user U * should appear relatively anomalous for the group as well, this could be a confirmation of the fact that the series of activities that led the user U * to be pointed out as anomalous with respect to his own past, in the same way it has not found a match even in the group of its peers. Therefore, we can exclude that a new system, a new procedure or an update of an existing company workflow has entered the field that has suddenly changed the way in which some of the activities within the company are carried out. If this were the case, in fact, certainly this change would also have been found in some other peer of the user U *, and therefore the user U * would not have been anomalous even with respect to the group.

On the contrary, if the user U * should appear relatively aligned with the group, this could be a confirmation of the fact that we are faced with a "disruption" of the information system, of the company procedures or of the operating procedures that have had repercussions on the performance. of work on systems, causing widespread "baseline changes". It is also unlikely that multiple users have agreed to all commit a fraudulent action at the same time.

In this sense, the output of the analysis on the collective baseline can have a noise reduction action compared to what was detected by the analysis on the individual baseline, in particular with a substantial reduction of false positives.

With reference to Figure 2, the operation of an embodiment of the system for creating and verifying behavioral baselines, or an embodiment of the method for creating and verifying behavioral baselines, according to the invention is described below.

Initially, at step 70, the raw event collection module 16 of the central processor 12 collects and normalizes the raw or "raw" data on the events recorded by the target devices 36 connected to the central processor 12, considering them as emissions from those same target devices 36.

At step 72, preferably simultaneously with step 70, the IAM status collection module 18 of the central computer 12 collects data on the current status recorded by the IAM apparatus 38, which manages the user accounts and the authorizations of these accounts. By doing so, an updated mapping of all user accounts on target devices 36 is obtained from device ΙAΜ 38.

At step 74, the data enrichment module 20 of the central processor 12 crosses the raw event data collected at step 70 and the IAM status data collected at step 72, identifying and grouping the raw events associated with a specific user, or more in general of an entity, regardless of the number of accounts owned by the same user.

Raw events always contain information about the user who generated the issue. Depending on the target apparatus 36, this information about the "author" of the broadcast may include a source IP address, a hostname, a username, or a combination of this information. In particular, the username can always be traced back to a user thanks to the always updated mapping taken from the IAM 38 device.

By integrating all this information referred to in step 74, the data enrichment module 20 goes back to the user who operates by means of a certain username, who is using a certain IP address or who is traced through a certain hostname.

At step 76, the Markov module 24 of the central processor 12 constructs a Markov chain, or rather a matrix of Markov transitions, capable of tracing the passage from one emission to the next, i.e. from one activity to the temporally subsequent one. , both activities being defined by the enriched data and carried out by a specific physical user on the target devices 36. Clearly, depending on how many emissions are considered simultaneously, there will be a different dimension of the matrix.

The data used by the Markov module 24 for the construction of the Markov transition matrix are defined emissions, corresponding to the enriched data stored in the enriched data storage means 22 of the central processor 12.

The operation of the Markov module 24 has already been described in the present description, and reference is made to the corresponding paragraphs for more detail.

At step 78, the baseline module 26 analyzes the steps between the activities carried out by a specific physical user, or more generally of an entity, using known techniques of machine learning), starting from the matrix of Markov transitions for each user u, for each time window f (for example one day). In particular, the baseline module 26 is configured to calculate a plurality of individual z-score values, one for each single activity and entity pair (such as a user, for example), and a plurality of collective zscore values, one for each single pair. activity and time window. In practice, the z-score values represent the probability that an activity or a sequence of activities of a specific physical user, or more generally of an entity, constitutes an anomaly of behavior. Therefore, this provides a quantitative index on the observed series of emissions.

The operation of the baseline module 26 has already been described in the present description, and reference is made to the corresponding paragraphs for more detail.

At step 80, the anomaly on history verification module 28 evaluates the presence of a possible anomaly in the behavior of a user u, or more generally of an entity, with respect to the individual space, or rather with respect to the history of the past activities of the user u, based on the individual z-score previously calculated in step 78.

If the value of the individual z-score exceeds a predefined threshold, the behavior of user u is to be considered anomalous with respect to the history of the past activities of user u.

At step 82, the anomaly on history verification module 28 evaluates the presence of a possible behavior anomaly of a user u, or more generally of an entity, with respect to the collective space, or with respect to the current activities of other similar users said peers, on the basis of the collective z-score previously calculated in step 78.

If the value of the collective z-score exceeds a predefined threshold, the behavior of user u is to be considered anomalous with respect to the current activities of the peers.

In one embodiment, in the context of evaluating the presence of an anomaly, the anomaly check module on history 28 and the anomaly check module on peer 30 use known clustering and anomaly detection techniques, such as Rodriguez Laio or ABOD (Angle-Based Oulier Detection), which highlight the anomalies in these z-scores.

A user, or more generally an entity, could be anomalous or not with respect to its past behavior, downstream of the analysis referred to in step 78. In the event of an anomaly, an anomaly index would also be associated with it. Furthermore, the user could be the only anomalous in the time window taken into consideration, or there could be others within the group of his peers (users similar to him). This generates four possible outcomes, depending on how the assessment results in steps 80 and 82 are combined.

In the case of the first outcome 84, the user's activity is aligned with its past and also with respect to the peers (also non-anomalous) in the current window. Therefore, in this case, the activity appears absolutely normal and in line with the expected result.

In the case of the second outcome 85, the user's activity is aligned with its past, but it is anomalous with respect to the peers (which are instead anomalous) in the current window. Therefore, in this case, many users have changed their usual behavior, but it is unlikely that many users are simultaneously engaging in fraudulent activity. More likely, however, that it is a change of procedures or an update of the application that has caused a widespread change in the operation of the use of the target devices 36, or of a specific target device 36. The selected user, who he is the only one who is not anomalous, he probably did not adapt to the change imposed on others. It is possible to use this information in order to improve the active and prompt participation of users in changes of procedures, and therefore safety.

In the case of the third outcome 86, the user's activity is anomalous with respect to its past, but aligned with the peers (also anomalous) in the current window. Therefore, in this case, many users have changed their usual behavior. However, reporting the user anomaly could result in a false positive, as it is unlikely that many similar users are simultaneously engaging in fraudulent activity. On the other hand, it is more likely that it is a change of procedures or an update of the application that has caused a widespread change in the operation of the use of the target devices 36, or of a specific target device 36. With the third outcome 86, the user's anomaly is considered mitigated by virtue of a noise reduction.

Finally, in the case of the fourth outcome 87, the user's activity is anomalous with respect to its past and also with respect to its peers (which are not anomalous) in the current window. Therefore, the observed user performed abnormal activities compared to what he himself usually performs, while similar users did not modify their activity. This is the scenario that most likely deserves to be investigated and reported, as it could be fraudulent or otherwise dangerous behavior for the computer system.

In practice it has been found that the invention fully achieves the intended aim and objects. In particular, we have seen how the system and method for the creation and verification of behavioral baselines thus conceived allows to overcome the qualitative limits of the known art, as they allow to create and verify behavioral baselines based on activities or sequences of activities. carried out by entities (including both users and equipment) operating within a corporate network, in order to identify any behavioral deviations that could represent harmful activities and cyber threats.

An advantage of the system and method for creating and verifying behavioral baselines according to the present invention consists in the fact that they allow a dynamic, adaptive and proactive cyber threat detection method, in order to counteract external and internal threats continuously. evolution and unknown a priori.

Another advantage of the system and method for creating and verifying behavioral baselines according to the present invention consists in the fact that they allow a method for detecting behavioral anomalies that is not guided by pre-established signatures or policies, but which adapts to the behavior of entities and the use of company information systems.

A further advantage of the system and method for creating and verifying behavioral baselines according to the present invention consists in the fact that they minimize false positives, thus increasing the effectiveness of the response actions to an attack or a cyber threat.

Furthermore, the advantage of the system and of the method for creating and verifying behavioral baselines according to the present invention consists in the fact that they are not limited to carrying out correlations on the activities of the accounts, but carry out correlations on the activities of the individual physical user, regardless of the number of accounts assigned to the same.

Although the system and method for creating and verifying behavioral baselines according to the invention have been conceived in particular to increase the IT security of corporate or infrastructure systems and networks, they can still be used, more generally, to increase IT security. of systems and networks of any medium or large entity.

The invention thus conceived is susceptible of numerous modifications and variations, all of which are within the scope of the inventive concept. Furthermore, all the details can be replaced by other technically equivalent elements.

In practice, the materials employed, so long as they are compatible with the specific use, as well as the contingent shapes and dimensions, may be any according to requirements and to the state of the art.

In conclusion, the scope of the claims must not be limited by the illustrations or preferred embodiments illustrated in the description in the form of examples, but rather the claims must encompass all of the patentable novelty features that reside in the present invention, including all the characteristics that would be treated as equivalent by the person skilled in the art.

Claims (12)

1. System (10) for creating and verifying behavioral baselines, comprising a central processing device (12) comprising a control unit (14) and enriched data storage means (22), connected and communicating with a plurality of target apparatuses (36) and with an Identity & Access Management or IAM apparatus (38), characterized in that said central processing device (12) comprises: - a Markov module (24), configured to construct a matrix of Markov transitions capable of tracing the transition from a first activity to a second activity temporally subsequent, both said activities being defined by enriched data and carried out by an entity on said devices target (36); - a baseline module (26), configured to calculate a plurality of individual z-score values, one for each single activity and entity pair, and a plurality of collective z-score values, one for each single activity and time window pair; - a historical anomaly verification module (28) configured to assess the presence of an anomaly in the behavior of said entity with respect to an individual space, or with respect to the history of the past activities of said entity, on the basis of said plurality of z values - individual scores; And - a peer anomaly verification module (30), configured to evaluate the presence of an anomaly in the behavior of said entity with respect to a collective space, or with respect to the current activities of other similar peer entities, on the basis of said plurality of values collective zscore. 2. System (10) for the creation and verification of behavioral baselines according to claim 1, characterized in that said individual z-score value is calculated according to the formula: where is it : 3. System (10) for the creation and verification of behavioral baselines according to claim 1 or 2, characterized in that said collective z-score value is calculated according to the formula: where is it System (10) for the creation and verification of behavioral baselines according to any one of the preceding claims, characterized in that said central processing device (12) further comprises a raw event collection module (16) configured to collect and normalize raw data on the events recorded by said target devices (36). 5. System (10) for the creation and verification of behavioral baselines according to any one of the preceding claims, characterized in that said central processing device (12) further comprises an IAM status collection module (18) configured to collect data on the current status registered by said IAM apparatus (38), obtaining an updated mapping of all the accounts of said entity on said target apparatuses (36). System (10) for the creation and verification of behavioral baselines according to any one of the preceding claims, characterized in that said central processing device (12) further comprises a data enrichment module (20) configured to cross said raw data on events, collected by said raw event collection module (16), and said IAM status data, collected by said IAM status collection module (18), identifying and grouping raw events associated with said entity regardless of the number of accounts of which that entity is the owner. 7. Method for creating and verifying behavioral baselines, by means of a central processing device (12) comprising a control unit (14) and enriched data storage means (22), connected and in communication with a plurality of apparatuses target (36) and with an Identity & Access Management or IAM (38) apparatus, comprising the steps which consist in: - construct (76) a matrix of Markov transitions capable of tracing the transition from a first activity to a second temporally subsequent activity, by means of a Markov module (24) included in said central processing device (12), both said activities being defined from said data enriched and carried out by an entity on said target devices (36); - calculate (78) a plurality of individual zscore values, one for each single activity and entity pair, and a plurality of collective zscore values, one for each single activity and time window pair, by means of a baseline module (26) included in said central processing device (12); - assess (80) the presence of a behavioral anomaly of said entity with respect to an individual space, or with respect to the history of the past activities of said entity, on the basis of said plurality of individual z-score values, by means of a verification module anomaly on history (28) included in said central processing device (12); And - assess (82) the presence of an anomaly in the behavior of said entity with respect to a collective space, or with respect to the current activities of other similar peer entities, on the basis of said plurality of collective z-score values, through a verification module anomaly on peer (30) included in said central processing device (12). 8. Method for creating and verifying behavioral baselines according to claim 7, characterized in that said individual zscore value is calculated according to the formula: where is it : 9. Method for the creation and verification of behavioral baselines according to claim 7 or 8, characterized in that said collective z-score value is calculated according to the formula: where is it 10. Method for creating and verifying behavioral baselines according to any one of claims 7 to 9, characterized in that it comprises the step which consists in crossing (74) said event data, collected by said raw event collection module (16), and said IAM status data, collected by said IAM status collection module (18), through a data enrichment module (20) included in said central processing device (12), identifying and grouping events associated with said entity regardless of the number of accounts that entity owns. 11. Method for the creation and verification of behavioral baselines according to any one of claims 7 to 10, characterized by the fact of understanding the step which consists in collecting and normalizing (70) raw data on the events recorded by said target apparatuses (36) , through a raw event collection module (16) included in said central processing device (12). 12. Method for creating and verifying behavioral baselines according to any one of claims 7 to 11, characterized in that it comprises the step which consists in collecting (72) data on the current state recorded by said IAM apparatus (38), by means of an IAM status collection module (18) included in said central processing device (12), obtaining an updated mapping of all the accounts of said entity on said target apparatuses (36).