Method for monitoring and analyzing accesses to computer systems

Abstract

A method (20) for monitoring and analyzing accesses to computer systems, in particular cloud systems, the method (20) being executed by a computer (10), comprising the steps of: - collecting (21) a plurality of access logs of each user to a computer system (13), each access log comprising the following original information: timestamp, username, and IP address; - generating a history (24) of the access logs of each user to the computer system (13) in at least one history database; - checking (25) whether the IP address of each access log of each user to the computer system (13) is involved in potentially malicious activities; - checking (26) whether the IP address of each access log of each user to the computer system (13) is associated with anonymization systems and / or services; - verifying (28) whether the IP address of each access log of each user to the computer system (13) represents an anomaly, on the basis of the results of the previous checks; and - if the outcome of the verifying step (28) is positive, issuing (36) a report regarding the detected anomaly, indicating the type of the anomaly. )

Description

[0001] METHOD FOR MONITORING AND ANALYZING ACCESSES TO COMPUTER SYSTEMS

[0002] The present invention relates to a method for monitoring and analyzing accesses to computer systems, in particular computer systems of the cloud type (in short, cloud systems).

[0003] Nowadays, in ICT security (also known as "cyber security"), threats to accesses (also known as authentications or logins) of users to computer systems are constantly on the increase. For this reason, ensuring secure access to the sensitive data of users stored in computer systems has become a priority for organizations, for example companies, especially with the widespread use of cloud systems.

[0004] Currently, to prevent these ICT security threats, i.e. to prevent unauthorized (or illicit) accesses, SIEM (Security Information and Event Management) systems are known. SIEM systems are complex computer systems that integrate the functionality offered by two different types of ICT security systems, i.e. SIM (Security Information Management) systems and SEM (Security Event Management) systems, in order to combine the provision of reports relating to collected logged data and analysis of the events executed in real time.

[0005] A SIM system automates the process of collecting and managing logs, not in real time. In particular, the logged data are collected and sent to a centralized server, typically by agents or forwarders installed on the various devices of the monitored network or system. The use of long-term storage space on the centralized server, together with analysis of the logged data, make it possible for the SIM system to generate and provide custom reports.

[0006] By contrast, a SEM system executes the real-time monitoring and management of events that occur within the monitored network or system, and also correlates and aggregates those events with each other. The SEM system has a centralized console dedicated to monitoring events, reporting events, and handling the automatic response (if any) to determined events.However, these conventional SIEM systems are not devoid of drawbacks, in that they have some significant limitations in the detection and prevention of unauthorized (or illicit) accesses.

[0007] A first drawback of conventional SIEM systems consists in that they perform a reactive detection of unauthorized (or illicit) accesses, since these SIEM systems are designed to detect anomalies, i.e. unusual behaviors, based on predefined detection rules.

[0008] A second drawback of conventional SIEM systems consists in that the anomalies they detect are often decontextualized, making it difficult for ICT security analysts to understand the reason why a specific event was considered anomalous.

[0009] A third drawback of conventional SIEM systems consists in that they are complex to configure, since their configuration and the maintenance of the corresponding detection rules requires significant effort on the part of the ICT security administrators.

[0010] A fourth drawback of conventional SIEM systems consists in that they have limited scalability, since some SIEM systems have difficulty in managing great volumes of logs in real time, owing mainly to the increase in logs collected by and originating from cloud systems.

[0011] The aim of the present invention is to overcome the limitations of the known art described above, by devising a method for monitoring and analyzing accesses to computer systems, in particular cloud systems, that makes it possible to obtain effects, in particular in terms of efficacy and efficiency, that are superior to those obtainable with known solutions and / or comparable effects at lower cost and with higher performance levels.

[0012] Within this aim, an aim of the present invention is to conceive a method for monitoring and analyzing accesses to computer systems that makes it possible to combat the principal threats to user accesses to computer systems through the study of anomalies, i.e. unusual behaviors, with respect to usual access models of users.Typically, these ICT threats include targeted attacks where ill-intentioned individuals succeed in obtaining the access credentials of users, these access credentials then being used by unauthorized parties to access computer systems, for example cloud systems.

[0013] Another object of the present invention is to devise a method for monitoring and analyzing accesses to computer systems that makes it possible to offer protection that is proactive (and not only reactive) and scalable against threats to user accesses to computer systems.

[0014] Another object of the present invention is to conceive a method for monitoring and analyzing accesses to computer systems that makes it possible to report anomalies, i.e. unusual behaviors, in a complete and contextualized manner, basically with a high informational content.

[0015] Another object of the present invention is to devise a method for monitoring and analyzing accesses to computer systems that becomes increasingly capable in predicting and / or detecting unauthorized (or illicit) accesses and / or the compromising of access credentials, and therefore of accounts and of the corresponding sensitive data, of users of computer systems, by learning continuously from historical data and in real time.

[0016] Another object of the present invention is to devise a method for monitoring and analyzing accesses to computer systems that makes it possible to improve the capacity of organizations, for example companies, to defend themselves against unauthorized (or illicit) accesses and / or from the compromising of access credentials, and therefore of accounts and of the corresponding sensitive data, of users of computer systems.

[0017] Not least an object of the present invention is to provide a method for monitoring and analyzing accesses to computer systems that is highly reliable, easily and practically implemented, and economically competitive when compared to the known art.

[0018] This aim and these and other objects which will become better apparent hereinafter are achieved by a method for monitoring and analyzingaccesses to computer systems, in particular cloud systems, according to claim 1.

[0019] Further characteristics and advantages of the present invention will become clearer from the description of a preferred, but not exclusive, embodiment of the method for monitoring and analyzing accesses to computer systems, in particular cloud systems, according to the invention, illustrated by way of non-limiting example with the aid of the accompanying drawings wherein:

[0020] Figures 1A and IB are a flowchart that schematically shows an embodiment of the method for monitoring and analyzing accesses to computer systems according to the present invention;

[0021] Figure 2 is a block diagram that schematically shows an embodiment of the computer that executes the method for monitoring and analyzing accesses to computer systems according to the present invention;

[0022] Figures 3 and 4 are block diagrams that schematically show respective embodiments of the functional connections of the computer that executes the method for monitoring and analyzing accesses to computer systems according to the present invention, with other systems and / or devices.

[0023] In general, the method for monitoring and analyzing accesses to computer systems, in particular cloud systems, according to the present invention uses non- supervised machine learning techniques, in particular clustering and rules of association (as will be seen below in the description), to analyze the accesses of users to computer systems, so as to identify deviations from the usual behavior models, and therefore anomalies, that may correspond to respective security violations, in particular to unauthorized (or illicit) accesses and consequent compromising of access credentials, and therefore of accounts and of the corresponding sensitive data, of the users of the computer systems.

[0024] With reference to Figures 1A and IB, the method for monitoring and analyzing accesses to computer systems according to the present invention,generally designated by the reference numeral 20, comprises substantially the steps described below.

[0025] Initially, in step 21, the access logs of each user to a computer system 13, in particular to a cloud system, for example Microsoft Azure or Google Workspace, are collected. It should be noted that computer systems 13, in particular cloud systems, make their API (Application Programming Interface) available in order to allow collection of the access logs of their users.

[0026] With reference to Figure 3, in an embodiment, the computer 10 that executes the method according to the invention is functionally connected to the computer system 13. Preferably, the computer 10 that executes the method according to the invention is connected to and in communication with the computer system 13 via a telematic communication network 16, such as for example the internet.

[0027] In this embodiment, the access logs of the users are collected by the computer 10 directly from the source, i.e. from the computer system 13, without passing through any SIEM system.

[0028] With reference to Figure 4, in another embodiment, the computer 10 that executes the method according to the invention is functionally connected to a SIEM system 17, and the SIEM system 17 is functionally connected to the computer system 13. Preferably, the computer 10 that executes the method according to the invention is connected to and in communication with the SIEM system 17 via a telematic communication network 16, such as for example the internet, and the SIEM system 17 is connected to and in communication with the computer system 13 via a telematic communication network 16, such as for example the internet.

[0029] In this embodiment, the SIEM system 17 collects the access logs of the users from the computer system 13, i.e. from the source of those access logs, and then the SIEM system 17 sends these access logs to the computer 10, for example periodically or following an interrogation or query. In otherwords, the computer 10 can receive the access logs following an interrogation or query sent by that computer 10 to the SIEM system 17.

[0030] The SIEM system 17 can have a connector or add-on configured to connect to the computer system 13, and to collect the respective access logs. Similarly, agents or forwarders can be installed on various devices of the computer system 13, for example on virtual machines in the cloud system, and configured to collect the respective access logs and send them to the SIEM system 17.

[0031] Advantageously, in step 22, the access logs of each user to the computer system 13, which were collected in the previous step 21, are normalized.

[0032] In general, normalization is a known computer process geared at mitigating systematic problems and / or defects in a data set, in this case log data, and in particular data of access logs. Basically, normalization of access logs consists of a modification of the data of the logs from the point of view of the form or the format (and not from the point of view of the information content, which by contrast remains unchanged), for the purpose of rendering these data mutually uniform.

[0033] Each access log comprises at least the following original access information: timestamp, username, and IP address.

[0034] Advantageously, in step 23, the access logs of each user to the computer system 13, collected in the previous step 21 and advantageously normalized in the previous step 22, are enriched, by means of at least one enrichment database 14, typically external and commercial.

[0035] In particular, in the above enrichment, each access log, expanding the respective original access information, is associated with one or more additional items of access information selected from the group consisting of: geographic information, time-related information, and IP address information.

[0036] For example, the geographic access information can comprise thefollowing data: country, continent, administration area(s) (i.e. region and / or province), and / or geographic coordinates (i.e. latitude and longitude, preferably accompanied by an accuracy radius).

[0037] For example, the time-related access information can comprise the following data: local time, local day of the week, and / or time band (i.e. during working hours or outside working hours).

[0038] For example, the IP address access information can comprise the following data: autonomous system number (ASN), and / or registrant.

[0039] In routing protocols, an autonomous system (AS) is a very big network or a group of networks with a single routing criterion, i.e. an AS is a group of routers and networks under the control of a single and well-defined administrative authority. Therefore, the ASN is a number that uniquely identifies the AS.

[0040] The at least one enrichment database 14 comprising the additional information (geographic, time-related and / or IP address-related), on which the step of enrichment 23 of the access logs described above is based, can be functionally connected to the computer 10 that executes the method according to the invention. Preferably, the computer 10 that executes the method according to the invention is connected to and in communication with the enrichment database 14 via a telematic communication network 16, such as for example the internet.

[0041] The purpose of the step of normalization 22 and of the step of enrichment 23, described above, is to have the data of the access logs in a standard form or format, mutually consistent and with a high informational content.

[0042] Advantageously, before the step of historicizing 24 (i.e. generating a history of) the access logs, a salted hashing operation is performed on the username of each access log, so as to ensure the anonymity of the access. For example, this salted hashing operation can be executed after the step of collecting 21, or after the step of normalization 22, or after the step ofenrichment 23.

[0043] In cryptography, a "salt" is a random sequence or string of alphanumeric characters used together with a data item (typically a password, but in this case a username) as input to a unidirectional function (in this case a hashing function) in order to make that data item (in this case the username) more secure.

[0044] The "hash with salt" function is a known cryptographic function that generates a hash value from a sequence or string of alphanumeric characters comprising a data item (in this case the username) and a salt. The hash with salt function is more secure than a cryptographic function such as, for example, the MD5 hash function. In fact, for the same input data, the MD5 hash function always generates the same hash value as output. Therefore, if an ill-intentioned individual should find this hash value in a stolen database, they could reconstruct the input data. But the hash with salt function makes it possible to increase the security of the input data by first combining it with a salt. In this manner, the result of the hash with salt function, i.e. the hash value, is not always the same for the same input data, and instead depends on the data-and-salt pair.

[0045] Following steps 21, 22 and 23 described above, each access log can comprise a plurality of data items selected from the group consisting of: timestamp;

[0046] username;

[0047] IP address;

[0048] latitude;

[0049] longitude;

[0050] accuracy radius;

[0051] autonomous system number (ASN);

[0052] registrant;

[0053] local time;

[0054] local day of the week (for example, from Monday [0] to Sunday [6]);country or state;

[0055] continent;

[0056] administration area 1 (or region);

[0057] administration area 2 (or province); and

[0058] user agent.

[0059] For example, the above data items in a access log can have the following values:

[0060] timestamp: 2024-01-2907:35:01.9+00;

[0061] username: **♦*,*♦**;

[0062] IP address: 194.243.103.54;

[0063] latitude: 457.765;

[0064] longitude: 120.489;

[0065] accuracy radius: 50 km;

[0066] autonomous system number (ASN): 3269;

[0067] registrant: Telecom Italia;

[0068] local time: 8;

[0069] local day of the week: 0;

[0070] country or state: Italy or IT;

[0071] continent, Europe or EU;

[0072] administration area 1 (or region): Veneto;

[0073] administration area 2 (or province): Province of Treviso; and

[0074] user agent: Mozilla / 5.0 (Windows NT 10.0).

[0075] In step 24, a history is generated of the access logs of each user to the computer system 13, which were collected in the previous step 21, advantageously normalized in the previous step 22 and advantageously enriched in previous step 23, and is stored in at least one history database (not shown). The computer 10 that executes the method according to the invention can comprise the history database.

[0076] Preferably, the access logs are historicized / stored (in tabular form) in arelational database, for example the relational database known as PostgreSQL which is open source and is widely known for its robustness, flexibility and compatibility.

[0077] Preferably, the access logs are further historicized / stored (in vector form) in a vector database, for example the vector database known as Elastic, so as to render them displayable, for example, on a geographic map using a data display dashboard, for example the data display dashboard known as Kibana, which makes it possible to analyze and display access logs, statistics and / or metrics in real time, with the creation of customizable dashboards.

[0078] Advantageously, the steps from 21 to 24 described above are executed periodically, for example every 5 minutes, so that the information and / or the data of the access logs of each user to the computer system 13 are as up-to-date as possible.

[0079] Once the step 24 of historicizing (i.e. generating a history of) the access logs is concluded, analysis begins of the access logs in order to detect anomalies, i.e. unusual behaviors.

[0080] In a first phase (i.e. a first group of steps, in particular comprising one or more of the steps from 25 to 28), the access logs, and therefore the activity of the respective users, are subjected to static-type checks of the characteristics of the IP address from which the access was executed, by way of at least one information source for IP addresses 15, typically external and commercial. This first phase can be termed the "static phase".

[0081] The at least one information source for IP addresses 15, on which the static checks of the characteristics of the IP address are based, in steps 25, 26 and 27 described below, can be functionally connected to the computer 10 that executes the method according to the invention. Preferably, the computer 10 that executes the method according to the invention is connected to and in communication with the information source for IP addresses 15 via a telematic communication network 16, such as forexample the internet.

[0082] In step 25, for each access log (i.e. one access log at a time), the method checks whether the IP address of the access log is involved in potentially malicious activities, by using (i.e. by querying) a first information source for IP addresses 15, in particular an information source on the reputation of IP addresses (basically an IP blacklist), for example the information source known as AbuselPDB which is an online platform that allows users to report and check suspect IP addresses, each one of which is assigned a risk score on a scale from 0 (nil risk) to 100 (total risk).

[0083] In step 26, for each access log (i.e. one access log at a time), the method checks whether the IP address of the access logs is associated with (i.e. used by) anonymization systems and / or services, for example virtual private networks (VPNs), proxies and / or bots, by using (i.e. by querying) a second information source for IP addresses 15, in particular an information source on the anonymization of IP addresses, for example the information source known as Spur.us which is a web service that provides access to information updated daily about millions of IP addresses in use by anonymization systems and / or services.

[0084] Advantageously, in step 27, for each access log (i.e. one access log at a time), the method checks whether the IP address of the access log is associated with (i.e. belongs to) an autonomous system number (ASN) that is involved in potentially malicious activities, by using (i.e. querying) a third information source for IP addresses 15, in particular an information source on the reputation of autonomous system numbers (basically an ASN blacklist), for example an information source comprising the autonomous system numbers of internet service companies that offer advanced solutions such as for example high-speed connectivity, cloud and hosting services, i.e. internet services that could be used by an attacker to conceal their identity.

[0085] The static checks of the characteristics of the IP address, in steps 25, 26 and 27 described above, can be executed in parallel (i.e. simultaneously),as shown in Figure 1 A, or in series (i.e. one after the other).

[0086] In step 28, for each access log (i.e. one access log at a time), the method verifies whether the IP address of the access log is suspect in that it represents an anomaly, i.e. if the outcome of at least one of the static checks on the characteristics of the IP address, in steps 25, 26 and 27 described above, is positive.

[0087] If the outcome of the verification in step 28 is positive, i.e. if the IP address of the access log is suspect, then the method proceeds to step 36, described below, since the access is deemed anomalous.

[0088] By contrast, if the outcome of the verification in step 28 is negative, i.e. if the IP address of the access log is not suspect, then the method can proceed to step 29 or later, described further below.

[0089] In step 36, a report or an alert is issued regarding the detected anomaly, preferably indicating the type of anomaly i.e. the related anomaly scenario. The report or alert is sent to the organization to which the user belongs, for example by email.

[0090] In particular, following the check in step 25, if the IP address is involved in potentially malicious activities (for example it has a risk score higher than 25, according to AbuselPDB), then in step 36, a report or alert can be issued for a "blacklisted IP address" anomaly scenario.

[0091] In particular, following the check in step 26, if the IP address is associated with anonymization systems and / or services (for example it is present in the lists of Spur.us), then in step 36, a report or an alert can be issued for an "anonymous IP address" anomaly scenario. Advantageously, this report or alert comprises the information and / or the data corresponding to the provider of the VPN, proxy and / or bot.

[0092] In particular, following the check in step 27, if the IP address is associated with an autonomous system number involved in potentially malicious activities, then in step 36, a report or alert can be issued for a "blacklisted Autonomous System Number" ("blacklisted ASN") anomalyscenario.

[0093] In an embodiment, for each one of the static checks in the previous steps 25, 26 and 27, and therefore for each static scenario, a maximum of one report or one alert is issued per day, as it is not possible to detect a common pattern between one access and the next.

[0094] Advantageously, if the static checks in the previous steps 25, 26 and 27 do not detect anomalies in the IP address of the access log, and therefore if the outcome of the verification in step 28 is negative, then the method proceeds to a second phase (i.e. a second group of steps, in particular comprising one or more of the steps from 29 to 35), where the access logs, and therefore the activity of the respective users, are subjected to dynamictype, or behavioral, checks of the characteristics of the access point and / or of the user who performed the access. This second phase can be termed the "dynamic phase". This second phase or "dynamic phase" is subsequent to the first phase or "static phase".

[0095] Advantageously, a preliminary verification is executed, in step 29 described below, before proceeding to this second phase comprising the dynamic checks. This preliminary verification allows to know if it is actually possible to execute such dynamic checks; in particular, it makes it possible to verify whether the number of access logs of the user is sufficient for them to represent, all together, a reliable history of accesses by that user (since, clearly, too small a number of access logs of a user would not adequately represent the access history of the user).

[0096] Advantageously, in step 29, for each user (i.e. one user at a time) of access logs, the method verifies whether the number of access logs available is greater than or equal to a MinLogs (minimum logs) parameter, which is the minimum number of access logs necessary to have a reliable history of the accesses of the user. The value of the MinLogs parameter can be predefined, or set by a system administrator or the like. For example, the MinLogs parameter can have a value of 20.If the outcome of the assessment in step 29 is negative, i.e. if the number of available access logs is insufficient (i.e. less than the MinLogs parameter), such that they cannot represent, all together, a reliable history of the user, then the method according to the invention can be concluded since the access is deemed legitimate.

[0097] By contrast, if the outcome of the assessment in step 29 is positive, i.e. if the number of available access logs is sufficient (i.e. greater than or equal to the MinLogs parameter), such that they can represent, all together, a reliable history of the user, then the method can proceed to step 30, described below.

[0098] Advantageously, in step 30, for each user (i.e. one user at a time) of access logs, the method defines at least one geographic cluster which comprises at least a part of the set of access points of the user, or rather of the set of geographic positions of the access points of the user, and which represents a geographic area from which the user habitually executes access to the computer system 13. Basically, each user is associated with one or more habitual geographical areas using a data analysis technique, in particular a clustering algorithm, which groups geographical points in clusters based on their spatial proximity.

[0099] Advantageously, the clustering algorithm is the known DBSCAN (Density -Based Spatial Clustering of Applications with Noise) algorithm, which is used in general to define clusters by grouping points in a data set, in this case a set of access points used by the user, or rather a set of geographic positions of the access points used by the user. A cluster defined by the DBSCAN algorithm is called a dense cluster because this algorithm uses a definition of cluster based on density. Differently from centroid-based clustering algorithms, such as for example the K-Means algorithm, the DBSCAN algorithm is capable of identifying clusters of arbitrary shape and of handling noise points (outliers).

[0100] The DBSCAN algorithm works using two parameters: £ or eps(epsilon), and MinPts (minimum points).

[0101] The £ parameter is the maximum search radius for including points in the cluster. In more detail, the £ parameter is the search radius that defines the maximum distance there can be between points for them to be considered close to each other, i.e. belonging to the same cluster. The value of the £ parameter can be predefined, or set by a system administrator or the like. For example, the £ parameter can have a value of 200 km.

[0102] The MinPts parameter (or requirement) is the minimum necessary number of points to form a cluster. In more detail, the MinPts parameter (or requirement) is the minimum number of points that must exist within the radius £ for a point to be considered part of a cluster. Basically, the MinPts parameter (or requirement) is the necessary and sufficient condition for a cluster to exist. The value of the MinPts parameter can be predefined, or set by a system administrator or the like. For example, the MinPts parameter can have a value of 2.

[0103] The operation of the DBSCAN algorithm is based on core points, border points and noise points. A point, in this case an access point used by the user, is considered a core point if it has at least MinPts points (including itself) within the radius £. Then, a border point is a point that is not a core point, in that it does not have the required MinPts, but it is within the radius £ from a core point. Finally, a noise point (outlier) is a point that is neither a core point nor a border point, in that it does not have the required MinPts and it is located outside the radius £ from a core point.

[0104] The DBSCAN algorithm begins by arbitrarily selecting an initial, unvisited point in the data set, in this case in the set of access points used by the user. If the selected point is a core point, a new cluster is defined with the core point as the center and all points that are densely reachable within the radius £ are added to the cluster. For each densely reachable point, if it is also a core point, the process is repeated in order to find further densely reachable points and add them to the cluster. If a point does not have therequired MinPts but it is located within the radius £ from a core point, it is labeled a border point and added to the cluster. If a point does not have the required MinPts and it is located beyond the radius £ from a core point, it is labeled as a noise point (outlier). This process continues with the next unvisited point in the data set until all the points have been visited.

[0105] Advantageously, the DBSCAN algorithm can manage the radius of error, which sometimes can reach 500 km for example, associated with the geolocation of the IP addresses, and therefore of the access points used by the users. In fact, the DBSCAN algorithm can calculate the distance of a point from a border point comprised in the nearest geographic cluster, and if this distance is smaller than the radius of error then the point is considered densely reachable and therefore it is added to the nearest geographic cluster, as it belongs to the latter.

[0106] Advantageously, in step 31, for each access log (i.e. one access log at a time), the method evaluates whether the point, or rather the geographical position of the point, from which the access was executed is comprised in (i.e. belongs to) the geographic cluster of the user defined in the previous step 30, so detecting when the access that was executed originates from geographical areas that are anomalous for the user, i.e. outside the geographic cluster.

[0107] If the outcome of the evaluation in step 31 is positive, i.e. if the access point used by the user is comprised in the geographic cluster, the method according to the invention can be concluded since the access is deemed legitimate.

[0108] But if the outcome of the evaluation in step 31 is negative, i.e. if the access point used by the user is not comprised in the geographic cluster, and therefore outside the habitual geographic area of the user, then the method can proceed to step 32 or step 33 described below (and / or optionally step 36) since the access is deemed anomalous.

[0109] Advantageously, if the evaluation in step 31 detects that the accesspoint, or rather the geographical position of the access point, is not comprised in any geographic cluster, and therefore not in any habitual geographic area of the user, and therefore if the outcome of the evaluation in step 31 is negative, the method can proceed to one or more further deterministic dynamic checks, which on the basis of the parameters of the access log and / or of the recent and past history of access logs, evaluate whether the access executed by the user is sufficiently anomalous that it should be brought to official attention via the emission of a report or an alert, as well as undertaking containment actions such as for example revoking the sessions initiated using the anomalous access and / or forcing the change of the access credentials of the user.

[0110] Advantageously, in step 32, for each access log (i.e. one access log at a time), the method evaluates whether the point, or rather the geographical position of the point, from which the access was executed is in a country classified as an extended country, i.e. a country that covers a very great surface area, such as for example India, Russia, Canada, Brazil and China, so great as to forestall a conclusion that an access from within the same country, but from distant regions, can be deemed legitimate.

[0111] If the outcome of the evaluation in step 32 is positive, i.e. if the access point used by the user is in an extended country, then the method can proceed to step 34 described below (and / or optionally step 36).

[0112] But if the outcome of the evaluation in step 32 is negative, i.e. if the access point used by the user is in a normal country, i.e. not in an extended country, then the method can proceed to step 33 described below (and / or optionally step 36).

[0113] Advantageously, in step 33, for each access log (i.e. one access log at a time), the method evaluates whether the point, or rather the geographical position of the point, from which the access was executed is in a reference country of the user, i.e. a country from which the user habitually executes access, this reference country being detected on the basis of the access logsof that user.

[0114] If the outcome of the evaluation in step 33 is positive, i.e. if the access point used by the user is in the reference country of that user, the method according to the invention can be concluded since the access is deemed legitimate.

[0115] But if the outcome of the evaluation in step 33 is negative, i.e. if the access point used by the user is in a foreign country, i.e. outside the reference country, then the method can proceed to step 34 described below (and / or optionally step 36).

[0116] Advantageously, in step 34, for each access log (i.e. one access log at a time), the method evaluates whether the user who executed the access is a traveling user, i.e. a user who has executed access from more than two different countries, this characteristic of the user (i.e. the fact of being a traveling user) being detected on the basis of the access logs of that user. In particular, it is possible to determine whether the user is a traveling user on the basis of the countries from which that user has executed access in the last N months (for example 3 months, which typically corresponds to the period for which access logs are kept for each user).

[0117] If the outcome of the evaluation in step 34 is positive, i.e. if the user is a traveling user, the method can be concluded since the access is deemed legitimate. Basically, access from outside the geographic cluster of the user and from outside the reference country, or from inside the reference country but from an extended country, can be deemed legitimate if the user habitually moves around and is therefore a traveling user, with the access from a new country being justified as a legitimate transfer.

[0118] Alternatively, if the outcome of the evaluation in step 34 is positive, i.e. if the user is a traveling user, then the method can proceed to step 35 described below (and / or optionally step 36).

[0119] Conversely, if the outcome of the evaluation in step 34 is negative, i.e. if the user is not a traveling user, the method can proceed to step 36described below since the access is deemed anomalous.

[0120] Advantageously, in step 35, for each access log (i.e. one access log at a time), the method evaluates whether the user who executed the access has made a journey or trip or transfer that is impossible, and therefore unrealistic, this characteristic of the trip (i.e. the fact that it is an impossible journey) of the user being detected on the basis of the access logs of that user, in particular by means of a check of the trip times of that user. In particular, it is possible to determine whether the user has made an impossible journey when access is executed from two or more geographically distant access points (i.e. positions) in too short a time period for it to be physically possible to travel between those positions.

[0121] For example, if a user accesses their company account from New York at 10:00 in the morning and from Tokyo at 11:00 in the morning on the same day, given the distance between the two countries and the short time between one access and the other, it is physically impossible for the same user to have actually traveled from one city to the other (for example considering a maximum travel speed of 600 km / h).

[0122] If the outcome of the evaluation in step 35 is positive, i.e. if the user has made a journey that is impossible, and therefore unrealistic, the method can proceed to 36 described below, since the access is deemed anomalous.

[0123] But if the outcome of the evaluation in step 35 is negative, i.e. if the user has made a journey that is possible, and therefore realistic, the method can be concluded since the access is deemed legitimate.

[0124] As mentioned, in step 36, a report or an alert is issued regarding the detected anomaly, preferably indicating the type of anomaly i.e. the related anomaly scenario.

[0125] In particular, following the checks in steps 32, 33 and 34, if the access point is in a normal country, i.e. not in an extended country, and if the access point is in a foreign country, i.e. outside the reference country, and if the user is not a traveling user, then in step 36, a report or alert can be issuedfor a "non-traveling user" anomaly scenario.

[0126] In particular, following the checks in steps 32 and 34, if the access point is in an extended country, and if the user is not a traveling user, then in step 36, a report or alert can be issued for a "non-traveling user in extended country" anomaly scenario.

[0127] In particular, following the check in step 35, if the user has made a journey that is impossible, and therefore unrealistic, then in step 36 a report or alert can be issued for an "impossible journey" anomaly scenario.

[0128] Advantageously, the issuing of a report or an alert in step 36, after the detection of an anomalous access in any of the checks in the previous steps, requires no human intervention, being based on automatically completing a specific model or template for each scenario.

[0129] For example, this report or alert can comprise a message according to the following model or template:

[0130] "Hello, we have detected a non-habitual access by user **** **** from the IP address xx.xx.xx.xx, geolocated in Italy.

[0131] The user has not executed an access from this geographic area in the last three months.

[0132] If the access is not recognized, we recommend resetting the access credentials of all the accounts associated with this user, revoking every session, and verifying that no further anomalous actions have been executed on this account."

[0133] Preferably, the report or alert can be enriched with a geographic map on which the anomalous access point and the habitual access points of the user are shown, and on which for example the anomalous access point is represented by a red mark and the habitual access points of the user are represented by respective green marks.

[0134] Preferably, the user and / or the organization to which the user belongs can override the anomaly detected if the access that was deemed anomalous is in fact valid or legitimate, for example because it was due to a trip ortransfer made by the user. In this case, preferably, this access, or rather the access point, or rather the geographical position of the access point, is not reported for the subsequent N days (for example 10 days) in order to allow a new cluster to be built if the user executes a plurality of accesses from that geographic area.

[0135] The present invention also relates to a data processing device or system, in short a computer, generally designated by the reference numeral 10, which comprises means 11, 12 configured to execute the steps described above of the method for monitoring and analyzing accesses to computer systems according to the invention. In particular, the computer 10 comprises a processor 11 and a memory 12.

[0136] As mentioned, the computer 10 can be functionally connected to computer systems 13 or to a SIEM system 17. As mentioned, the computer 10 can be functionally connected to at least one enrichment database 14. As mentioned, the computer 10 can be functionally connected to at least one information source for IP addresses 15.

[0137] The present invention also relates to a computer program comprising instructions which, when the program is run by a computer 10, cause the computer 10 to execute the steps described above of the method for monitoring and analyzing accesses to computer systems according to the invention.

[0138] The present invention also relates to a computer-readable memory medium comprising instructions which, when the instructions are executed by a computer 10, cause the computer 10 to execute the steps described above of the method for monitoring and analyzing accesses to computer systems according to the invention.

[0139] In practice it has been found that the present invention fully achieves the set aim and objects. In particular, it has been seen that the method for monitoring and analyzing accesses to computer systems, in particular cloud systems, thus conceived makes it possible to overcome the qualitativelimitations of the known art, in that it makes it possible to obtain better effects, in particular in terms of efficacy and efficiency, than those that can be obtained with conventional solutions and / or similar effects at lower cost and with higher performance levels.

[0140] An advantage of the method for monitoring and analyzing accesses to computer systems according to the present invention consists in that it makes it possible to combat the principal threats to user accesses to computer systems through the study of anomalies, i.e. unusual behaviors, with respect to customary access models of users.

[0141] Another advantage of the method for monitoring and analyzing accesses to computer systems according to the present invention consists in that it makes it possible to offer protection that is proactive (and not only reactive) and scalable against threats to user accesses to computer systems.

[0142] A further advantage of the method for monitoring and analyzing accesses to computer systems according to the present invention consists in that it makes it possible to report anomalies, i.e. unusual behaviors, in a complete and contextualized manner, basically with a high informational content.

[0143] In fact, by virtue of the method according to the invention, the output returned, specifically the report or alert issued, is described in detail, or in the jargon, "explicable". In fact, the report or alert issued states whether an access is anomalous and, especially, why the access is deemed as such. This information is essential both for the analyst responsible for supervising the system / process and for the organization to which the user belongs.

[0144] Another advantage of the method for monitoring and analyzing accesses to computer systems according to the present invention consists in that it becomes increasingly capable in predicting and / or detecting unauthorized (or illicit) accesses and / or the compromising of access credentials, and therefore of accounts and of the corresponding sensitive data, of users of computer systems, by learning continuously from historicaldata and in real time.

[0145] Another advantage of the method for monitoring and analyzing accesses to computer systems according to the present invention consists in that it makes it possible to improve the capacity of organizations, for example companies, to defend themselves against unauthorized (or illicit) accesses and / or from the compromising of access credentials, and therefore of accounts, of users of computer systems.

[0146] Although the method according to the invention has been conceived in particular for the monitoring and analysis of accesses to computer systems of the cloud type, it can also be used, more generally, for the monitoring and analysis of accesses to computer systems of any type.

[0147] The invention, thus conceived, is susceptible of numerous modifications and variations, all of which are within the scope of the appended claims.

[0148] Except where indicated otherwise, the various embodiments described above can be combined in order to provide further and / or alternative embodiments. In addition, the present description covers combinations of variations and preferred embodiments that are not explicitly described.

[0149] Moreover, all the details may be substituted by other, technically equivalent elements.

[0150] In practice the materials employed, provided they are compatible with the specific use, and the contingent dimensions and shapes, may be any according to requirements and to the state of the art.

[0151] The disclosures in Italian Patent Application No. 102025000005463 from which this application claims priority are incorporated herein by reference.

[0152] In conclusion, the scope of protection of the claims shall not be limited by the figures or by the preferred embodiments illustrated in the description by way of examples, but rather the claims shall comprise all the patentable characteristics of novelty that reside in the present invention,including all the characteristics that would be considered as equivalent by the person skilled in the art.

Claims

CLAIMS1. A method (20) for monitoring and analyzing accesses to computer systems, in particular cloud systems, said method (20) being executed by a computer (10), comprising the steps of:collecting (21) a plurality of access logs of each user to a computer system (13), each access log comprising the following original information: timestamp, username, and IP address;generating a history (24) of said access logs of each user to said computer system (13) in at least one history database;checking (25) whether said IP address of each access log of each user to said computer system (13) is involved in potentially malicious activities, by querying a first information source for IP addresses (15);checking (26) whether said IP address of each access log of each user to said computer system (13) is associated with anonymization systems and / or services, by querying a second information source for IP addresses (15);verifying (28) whether said IP address of each access log of each user to said computer system (13) represents an anomaly, on the basis of the results of the previous checks; andif the outcome of the verifying step (28) is positive, issuing (36) a report regarding said detected anomaly, indicating the type of said anomaly.

2. The method (20) according to claim 1, further comprising the step of normalizing (22) said access logs of each user to said computer system (13).

3. The method (20) according to claim 1 or 2, further comprising the step of enriching (23) said access logs of each user to said computer system (13), by means of at least one enrichment database (14), associating each access log with one or more additional items of information selected from the group consisting of: geographic information, time-related information, and IP address information.

4. The method (20) according to any one of the preceding claims, further comprising the step of performing a salted hashing of said username of each access log of each user to said computer system (13), prior to said step of generating a history (24).

5. The method (20) according to any one of the preceding claims, further comprising the step of checking (27) whether said IP address of each access log of each user to said computer system (13) is associated with an autonomous system number, ASN, that is involved in potentially malicious activities, by querying a third information source for IP addresses (15).

6. The method (20) according to any one of the preceding claims, further comprising, if the outcome of the step of verifying (28) is negative, the step of verifying (29) whether the number of access logs of each user is equal to or greater than a minimum number of access logs necessary to have a reliable history of said user's accesses.

7. The method (20) according to any one of the preceding claims, further comprising, if the outcome of the step of verifying (28) is negative or the outcome of the step of verifying (29) is positive, the step of defining (30) at least one geographic cluster for each user, said geographic cluster comprising at least one part of the set of access points of said user and representing a geographic area from which said user habitually accesses said computer system (13).

8. The method (20) according to claim 7, wherein said geographic cluster is defined by the Density-Based Spatial Clustering of Applications with Noise, DBSCAN, clustering algorithm.

9. The method (20) according to claim 7 or 8, further comprising the step of evaluating (31) whether the access point of each access log of each user to said computer system (13) is comprised within said geographic cluster.

10. The method (20) according to claim 9, further comprising, if the outcome of the evaluation step (31) is negative, the step of evaluating (32)whether the access point of each access log of each user to said computer system (13) is located in a country classified as an extended country.

11. The method (20) according to claim 9 or 10, further comprising, if the outcome of the evaluation step (31) or of the evaluation step (32) is negative, the step of evaluating (33) whether the access point of each access log of each user to said computer system (13) is located in a reference country of said user, i.e. a country from which said user habitually accesses said computer system (13), said reference country being detected on the basis of said access logs of said user.

12. The method (20) according to claim 10 or 11, further comprising, if the outcome of the evaluation step (32) is positive or if the outcome of the evaluation step (33) is negative, the step of evaluating (34) whether said user is a traveling user, i.e., when said user has accessed said computer system (13) from more than two different countries, said characteristic of said user being detected on the basis of said access logs of said user.

13. The method (20) according to claim 12, further comprising, if the outcome of the evaluation step (34) is positive, the step of evaluating (35) whether said user has made an impossible journey, i.e. when said user has accessed said computer system (13) from two or more geographically distant access points in too short a period of time, said characteristic of said journey of said user being detected on the basis of said access logs of said user.

14. A computer (10) comprising means (11, 12) configured to perform the steps of the method (20) according to any one of claims 1 to 13.

15. A computer program comprising instructions which, when the program is run by a computer (10), cause the computer (10) to execute the steps of the method (20) according to any one of claims 1 to 13.

16. A computer-readable memory medium comprising instructions which, when the instructions are executed by a computer (10), cause the computer (10) to execute the steps of the method (20) according to any one of claims 1 to 13.

Images