Network attack identification in network environment

Abstract

A mechanism for identifying cyberattacks in a network environment is provided. One method is performed by a security analysis module. This method includes obtaining logged events. These events have occurred and been logged in the network environment. Each logged event is associated with a network security deviation score and network security deviation statistics. The method includes matching each logged event to a network attack lifecycle stage by comparing the characteristics of each logged event given by the network security deviation statistics with known network attack lifecycle stages. The method includes linking these logged events together by forming at least one chain. Each chain corresponds to a type of network attack given by a combination of known network attack lifecycle stages. The network security deviation score and network security deviation statistics are updated based on how these logged events are linked together. The method includes determining whether these logged events are benign or part of a network attack based on how they are linked together and the updated network security deviation score and network security deviation statistics.

Description

Technical Field

[0001] The embodiments presented herein relate to methods, security analysis modules, computer programs, and computer program products for identifying network attacks in a network environment. Background Technology

[0002] Network security systems ingest logs, events, streams, and many other data in various formats to generate warnings, alerts, and notifications for Security Operations Center (SOC) analysts to triage, sort, analyze, and correlate.

[0003] This data is generated in massive quantities, even trillions of events per day. SOC analysts spend a significant amount of time sifting through false alarms and warnings, and relaying relevant alerts and warnings for further analysis at the next level. Security Information and Incident Management (SIEM) tools can be used to collect incidents, and Security Orchestration, Automation, and Response (SOAR) tools can be used to process (and potentially automate) the analysis of incidents.

[0004] Current log collection engines ingest human-readable log events and parse relevant fields from them into their database, normalizing them into a standard format where possible. Log events are all information written by developers, passed from one person to another for interpretation, and formatted in an application-specific manner. Log database data is analyzed by attempting to find search queries that indicate potential intrusion events. Security analytics solutions are developed to find threat events in large data databases, and they generate anomaly scores that distinguish events from others.

[0005] Much log and event data is ingested in a non-contextual way; for example, as human-readable log events, machines don't interpret them but rather collect and parse fragments of information. The parsed data doesn't reveal any relationships between data fragments within the log events and doesn't add data or relationships from other events. Once analyzed, the data is typically not revisited, or if it is, it requires complex queries to analyze relationships with other data fragments.

[0006] Many cybersecurity solutions generate various anomaly scores or similar scores, but the interpretation of the events is left to SOC analysts. Anomaly scores generate a large number of "false" alerts, and it takes a significant amount of human analysis to sort them out.

[0007] Intrusion detection and prevention solutions cannot scale because millions of new and different types of malware are created every day, and new ways to communicate with bots are constantly being developed. Inspecting every file or packet against millions or even billions of signatures or file hashes is impractical.

[0008] Therefore, there is a need to improve event handling in the network environment for detecting network attacks. Summary of the Invention

[0009] The purpose of the embodiments described herein is to provide effective identification of network attacks in a network environment.

[0010] According to a first aspect, a method for identifying network attacks in a network environment is provided. The method is performed by a security analysis module. The method includes obtaining logged events. These events have occurred and been logged in the network environment. Each logged event is associated with a network security deviation score and network security deviation statistics. The method includes matching each logged event to a network attack lifecycle stage by comparing the characteristics of each logged event given by the network security deviation statistics with known network attack lifecycle stages. The method includes linking these logged events together by forming at least one chain. Each chain corresponds to a type of network attack given by a combination of known network attack lifecycle stages. The network security deviation score and network security deviation statistics are updated based on how these logged events are linked together. The method includes determining whether these logged events are benign or part of a network attack based on how these logged events are linked together and the updated network security deviation score and network security deviation statistics.

[0011] According to a second aspect, a security analysis module for identifying network attacks in a network environment is provided. The security analysis module includes processing circuitry. This processing circuitry is configured to acquire logged events. These events have occurred and been logged in the network environment. Each logged event is associated with a network security deviation score and network security deviation statistics. The processing circuitry is configured to match each logged event with a network attack lifecycle stage by comparing the characteristics of each logged event given by the network security deviation statistics with known network attack lifecycle stages. The processing circuitry is configured to link these logged events together by forming at least one chain. Each chain corresponds to a type of network attack given by a combination of known network attack lifecycle stages. The network security deviation score and network security deviation statistics are updated based on how these logged events are linked together. The processing circuitry is configured to determine whether these logged events are benign or part of a network attack based on how these logged events are linked together and the updated network security deviation score and network security deviation statistics.

[0012] According to a third aspect, a security analysis module for identifying network attacks in a network environment is provided. The security analysis module includes an acquisition module configured to acquire logged events. These events have occurred and been logged in the network environment. Each logged event is associated with a network security deviation score and network security deviation statistics. The security analysis module includes a matching module configured to match each logged event with a network attack lifecycle stage by comparing the characteristics of each logged event given by the network security deviation statistics with known network attack lifecycle stages. The security analysis module includes a linking module configured to link these logged events together by forming at least one chain. Each chain corresponds to a type of network attack given by a combination of known network attack lifecycle stages. The network security deviation score and network security deviation statistics are updated based on how these logged events are linked together. The security analysis module includes a determination module configured to determine whether the logged events are benign or part of a network attack based on how they are linked together and the updated network security deviation score and network security deviation statistics.

[0013] According to the fourth aspect, a computer program for identifying network attacks in a network environment is proposed, the computer program including computer program code that, when run on a security analysis module, causes the security analysis module to perform the method described in the first aspect.

[0014] According to a fifth aspect, a computer program product is proposed, comprising the computer program as described in the fourth aspect and a computer-readable storage medium storing the computer program thereon. The computer-readable storage medium may be a non-transitory computer-readable storage medium.

[0015] Advantageously, these aspects provide effective identification of network attacks in the network environment.

[0016] Advantageously, these aspects enable the processing of events in a network environment for the detection of network attacks.

[0017] Advantageously, these aspects enable the storage of log events in a normalized, standardized interpretation format, which reduces the need for storage and subsequent normalization.

[0018] Advantageously, these aspects enable effective event correlation and analysis by leveraging early possible interpretations of malicious (or benevolent) intentions.

[0019] Advantageously, these aspects enable effective analysis of cybersecurity incidents and are suitable for automation using statistical or machine learning techniques.

[0020] Advantageously, these aspects enable the re-evaluation of initially analyzed log events as new events are logged.

[0021] Advantageously, these aspects enable the automatic interpretation of anomalous scores by leveraging relevant context and their relationship with other events.

[0022] Advantageously, these aspects enable the identification of the security status relative to the attack phase and the prediction of possible next steps in an ongoing cyberattack to expedite optimal mitigation actions.

[0023] Advantageously, these aspects enable efficient processing of log events to produce relevant results, the timing and type of the attacker's next move, and provide the possibility for predictive defensive actions.

[0024] Other objects, features, and advantages of the appended embodiments will become apparent from the following detailed disclosure, the appended dependent claims, and the accompanying drawings.

[0025] Generally, unless otherwise expressly defined herein, all terms used in the claims shall be interpreted according to their ordinary meaning in the art. Unless otherwise expressly stated, all references to “a / an / the element, device, component, part, module, step, etc.” shall be openly interpreted as referring to at least one instance of an element, device, component, part, module, step, etc. Unless expressly stated otherwise, the steps of any method disclosed herein need not be performed in the exact order disclosed. Attached Figure Description

[0026] The inventive concept will now be described by way of example with reference to the accompanying drawings, in which:

[0027] Figure 1 This is a schematic diagram illustrating a network environment according to an embodiment;

[0028] Figure 2 This is a flowchart of the method according to an embodiment;

[0029] Figure 3 The illustration schematically depicts events that occur and are recorded along a timeline according to an embodiment;

[0030] Figure 4 This is a schematic diagram illustrating the functional units of the security analysis module according to an embodiment;

[0031] Figure 5 This is a schematic diagram illustrating the functional modules of the security analysis module according to an embodiment; and

[0032] Figure 6 An example of a computer program product including a computer-readable storage medium according to an embodiment is shown. Detailed Implementation

[0033] The inventive concept will now be described more fully below with reference to the accompanying drawings, in which certain embodiments of the inventive concept are illustrated. However, the inventive concept can be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. In the specification, the same numerals refer to the same elements. Any step or feature indicated by dashed lines should be considered optional.

[0034] As mentioned above, there is a need to improve event handling in the network environment for detecting network attacks.

[0035] In this regard, logging event chains have traditionally required human ingenuity to manually link them and, if possible, match them with specific malware or botnets and their modus operandi. Security analysis has traditionally been used to improve threat / intrusion detection, but such analysis often fails to analyze the intent and context of logging events and offers little help in interpretation.

[0036] Therefore, the embodiments disclosed herein relate to mechanisms for identifying network attacks in a network environment. To obtain such a mechanism, a security analysis module, a method executed by the security analysis module, and a computer program product including code (e.g., in the form of a computer program) that, when run on the security analysis module, causes the security analysis module to execute the method.

[0037] Figure 1 This is a schematic diagram illustrating a network environment 100 in which the embodiments proposed herein can be applied. User 110 represents a bona fide user, a normal user operating the network with good intentions.

[0038] Attacker 170 represents a malicious user with the intent to intrude into the network and use it for malicious purposes.

[0039] Application 120 represents the management or application components of a service operated by a benevolent user. Malicious users may compromise Application 120 and gain access to compromised accounts to inject malicious activity through authorized channels.

[0040] Server 160 indicates a server owned / controlled by a malicious user and capable of being used for malicious actions against network units, depending on the connection architecture. This is typically a command and control server to which malware connects.

[0041] Core network 130 refers to the core network, which includes routers, firewalls, etc. It is the transmission network through which traffic between network units traverses.

[0042] Device 140 refers to any number of devices connected to core network 130, typically end devices such as Internet of Things (IoT) devices, personal computers, mobile phones, etc.

[0043] Network unit 150 refers to network units such as radio equipment, operations support system and business support system servers, mobile core units, and other network units used to deliver requested services to user 110 and to facilitate communication between user 110 and device 140 via core network 130.

[0044] Security analysis module 200 may include a Security Information and Event Management (SIEM) system 180 and / or a Security Operations and Analysis Platform Architecture (SOAPA) system 190, and is configured for network attack identification in network environment 100. Security analysis module 200 is configured to collect log events from all relevant entities (e.g., application 120, core network 130, device 140, network unit 150, server 160). This part of security analysis module 200 may be implemented by SIEM system 180. Security analysis module 200 is configured to analyze these log events for network security-related intelligence related to malicious activities. This part of security analysis module 200 may be implemented by SOAPA system 190. Further aspects of network attack identification in network environment 100 will be disclosed below.

[0045] Figure 2This is a flowchart illustrating an embodiment of a method for identifying network attacks in a network environment 100. These methods are performed by a security analysis module 200. These methods are advantageously provided as a computer program 620.

[0046] S102: Security analysis module 200 obtains log events. These events have occurred and been logged in network environment 100. Each log event is associated with a network security deviation score and network security deviation statistics.

[0047] S106: The security analysis module 200 matches each log event with a network attack lifecycle stage by comparing the characteristics of each log event given by the network security deviation statistics with known network attack lifecycle stages.

[0048] S108: The security analysis module 200 links these logging events together by forming at least one chain. Each chain corresponds to a type of network attack given by a combination of known network attack lifecycle stages. The network security deviation score and network security deviation statistics are updated based on how these logging events are linked together. That is, which logging events are linked to which logging events.

[0049] S110: The security analysis module 200 determines whether these log events are benign or part of a cyberattack based on how they are linked together and on updated cybersecurity deviation scores and cybersecurity deviation statistics.

[0050] Whether a logged event is benign or part of a cyberattack can be represented by a probability metric.

[0051] Now, embodiments relating to further details of network attack identification in network environment 100 performed by security analysis module 200 will be disclosed.

[0052] Generally speaking, in network environment 100, an attack is any attempt to expose, modify, disable, destroy, steal, or gain unauthorized access to or use of assets. A cyberattack is any offensive strategy of any kind against network environment 100, such as computer information systems, infrastructure, computer networks, or personal computer devices.

[0053] Non-limiting examples of cyberattacks can include a variety of known ransomware and malware, as well as worms.

[0054] Now, various aspects of log events will be made public. Traditionally, log events are created based on how the event is described according to the software specification, meaning that each piece of software describes similar events differently. Additionally, the formats of dates, addresses, and other information may vary. In some embodiments, all log events therefore have a uniform, machine-readable format. Consequently, log event data may be provided in a format that can be used in later stages of network attack identification.

[0055] As a non-restrictive example, events related to login failure can be logged as follows:

[0056] Aug 18 00:00:57izxvps sshd

[5657] :Failed password for rootfrom95.58.255.62 port 38980 ssh2

[0057] This event can be converted into a machine-readable, normalized event format in ways such as the following:

[0058] {"intent":"login","unix_time":"1566086457,"dest":"server-a","port":38980,"service":"ssh","user":"root","success":"false"}

[0059] As a non-limiting example, for events related to network streams, the network streams may be logged in a format designed by the application, but should be converted to a normalized, machine-readable format:

[0060] StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport TotPkts TotBytesState

[0061] 17:48:36.592155 e tcp 192.168.0.68.60245->128.2.129.188.http27 1820FIN

[0062] This event can be converted into a machine-readable, normalized event format, for example, by the following methods:

[0063] {"intent":"http","unix_time":"1566086457,"target":"128.2.129.188","port":80,"service":"ht tp","bytes":1820,"proto":"tcp","source":"192.168.0.68","source_port":60245,"state":"FIN"}.

[0064] Now, we will disclose all aspects of the calculation of cybersecurity deviation scores and cybersecurity deviation statistics.

[0065] A cybersecurity deviation score can be considered an anomaly score, confidence score, probability, or any score that suggests suspiciousness, malice, or security-related differences in an event (particularly related to other data in a relevant group). In this respect, a cybersecurity deviation score is an anomaly-type score that provides a measure of the degree of anomalousness of a logged event or the degree of deviation of a logged event from a normal event in a cybersecurity-related sense. The features / values ​​used in calculating the cybersecurity deviation score are cybersecurity-related. Algorithms such as random forests, statistical outliers, and autoencoders can be used to calculate cybersecurity deviation scores, for example.

[0066] Cybersecurity deviation scores can be calculated from various cybersecurity-related features, and then evaluated to obtain statistics. In this respect, cybersecurity deviation statistics typically provide a measure of how much a feature value deviates from the average in some statistical sense. Usually, statistics are not calculated for only a single feature. Cybersecurity deviation statistics can be calculated using ordinary statistics.

[0067] Events can be network, host, log, or other types of events, because not only network events but also log events and other events can be suspicious or obviously malicious based on various factors. In some embodiments, the security deviation score for each log event is proportional to the probability that the event is part of a network attack. In some embodiments, the security deviation statistic for each log event is defined as the standard deviation of the network security deviation scores for the same event.

[0068] Cybersecurity deviation scores can be calculated in various ways, such as using autoencoders, random forests, and other statistical and machine learning methods. Cybersecurity deviation scores can be scaled in different ways, for example, always taking values ​​between 0 and 100, where 100 is the most anomalous. The cybersecurity deviation statistic of an event represents its deviation from other (normal) events and can be calculated in several ways. One example is calculating the mean and standard deviation of a group of events in a survey. The cybersecurity deviation statistic for each feature of an event can be estimated, for example, using the normalized standard deviation of the feature values ​​from the mean. This can be used as the importance of the feature in the interpretation of the cybersecurity deviation score.

[0069] As a non-limiting example, in a cyberattack involving brute-force attacks, a login failure might indicate a brute-force or password spraying attempt, but it could also be part of a forgotten password scenario. A cybersecurity deviation score can be calculated using the number of login failures and the time between possible login attempts. One way to provide this feature is to use the sigmoid function to provide automatic scaling. That is, cybersecurity deviation score = 100 / (1+exp(-n)), where n is the number of failed attempts.

[0070] As a non-limiting example, numerical features can be used to define normal behavior embeddings for autoencoder models. Autoencoders can be used to compute representations, and for novel events, reconstruction errors can be used as a metric for scoring cybersecurity deviations.

[0071] As a non-limiting example, the mean and variance of a feature can be calculated, and the standard deviation can be used to calculate cybersecurity bias statistics. Cybersecurity bias statistics can be estimated by how much the feature values ​​deviate from the mean by standard deviation.

[0072] Now, we will reveal how to use cybersecurity deviation scoring and cybersecurity deviation statistics to interpret various aspects of logged events, given the known lifecycle stages of cyberattacks.

[0073] The relevant characteristics of each event typically depend on the specific stage of the cyberattack lifecycle (e.g., reconnaissance). Network event data such as connection direction, protocol, number of connections, and their deviations from other or normal data values ​​can be used to determine the underlying intent.

[0074] In some embodiments, the comparison in S106 involves selecting the network attack lifecycle stage that best matches the combination of event type, network security deviation score, and network security deviation statistics for each logged event.

[0075] As a non-limiting example, for a cyberattack involving malware delivery, if a network event exists in the data ingestion (where the mean is 1000 bytes and the measurement is 275000 bytes) with a network security deviation score of 68 and a highest characteristic deviation of 9.5 according to the network security deviation statistics, then this can be interpreted as an event with the intent to download malware onto the host. It could also be a benign event of software installation. Therefore, the event is either malware delivery (malicious intent) or firmware delivery (benevolent intent).

[0076] As a non-limiting example, for a network attack involving port scanning, if the network security deviation score is 87 and the highest characteristic deviation according to the network security deviation statistics is 13.2 in terms of port count, then this would be a high indication of intent to scan the target host's ports to find out what services are available and potentially vulnerable. Therefore, the event is either reconnaissance (malicious) or network testing (benevolent).

[0077] Now, we will reveal how various aspects of how cybersecurity deviation scores and statistics are correlated with probability values ​​(related to whether a cyberattack is underway).

[0078] Generally, logging events can indicate suspicious or obviously malicious behavior based on various factors and should be evaluated for the probability of being malicious or benign. For example, using network event data such as connection direction, protocol, and number of connections, or using failed login attempt log events, the intent behind each event can be estimated. In particular, in some embodiments, the security analysis module 200 is configured to perform (optionally) step S104:

[0079] S104: The security analysis module 200 obtains a probability score for each log event as part of a network attack. Then, the matching in step S106 is based on network security deviation statistics for each log event.

[0080] In some embodiments, the probability score for each logging event is based on host data associated with that logging event, network data such as connection direction, protocol, number of connections, and failed login attempts.

[0081] As a non-limiting example, in a cyberattack involving brute-force attacks, a failed login attempt could indicate a brute-force or password spraying attempt, but it could also simply be a forgotten password scenario. New events may increase or decrease the probability of malicious activity, and may also increase or decrease the probability that past events are considered more malicious. The average count of login attempts can be used to assess the probability of malicious activity.

[0082] As a non-limiting example, for cyberattacks involving malware delivery, this probability increases with a larger deviation of the data volume from the average.

[0083] Now, the aspects of marking logged events as malicious or benign will be made public.

[0084] Generally, each event may involve several different intentions. In some embodiments, each event is marked as malicious or benign based on a probability score of the logging event, and the matching in S106 depends on which logging events are marked as malicious and which logging events are marked as benign.

[0085] Next, we will disclose other aspects of how log events can be linked together.

[0086] In some embodiments, log events are linked together according to an ordered sequence in which these events occur. This ordered sequence is given by a combination of known network attack lifecycle stages.

[0087] As a non-restrictive example, access to a server is required before malware can be implanted, and an assessment of which servers are available must be performed before access to the server. Therefore, the sequence of events can be used to interpret what type of cyberattack is underway.

[0088] In some embodiments, this combination of known network attack lifecycle phases is based on a set of network attack lifecycle templates, wherein each network attack lifecycle template includes its own unique sequence of occurrence and the characteristics of that known network attack lifecycle phase.

[0089] In some embodiments, during the linking process in S108, each logging event is provided with a network attack lifecycle stage label.

[0090] There are different ways to describe the stages of a cyberattack. In some respects, there are main stages and sub-stages, and the embodiments disclosed herein can be applied to both. For example, the first stage, “reconnaissance,” typically consists of activities aimed at identifying any available and potentially vulnerable servers. This stage may be followed by the “weaponization” stage, in which malware is developed / selected for the target server. The malware is delivered to the target server in the “deliver” stage. In the “control” stage, the malicious actor uses various covert methods to instruct the malware to take what actions.

[0091] As a non-limiting example, logging events indicate attempts to connect to many different ports on the target server. This can appear as anomaly in the aggregated log events, indicating a high probability of malicious activity. Authorization log logging events indicate many failed login attempts. Network event log logging events indicate an unusual increase in data traffic flowing to the server (this may or may not be highly anomalous, and may be benign with a low to moderate probability of malicious intent). Network event log logging events indicate suspicious connections to the server, which may be an indication of the "control" phase.

[0092] The embodiments disclosed herein can be used to provide a graph relating anomalous, suspicious, and malicious events, where events have varying probabilities of belonging to a malicious graph. These events can be linked together in the graph, with each edge providing the probability that a given event belongs to a malicious event chain (compared to belonging to a benign event chain). This linking can be based on servers, users, applications, and other data. Here, the graph depicts the actions of a single malicious attacker or benign user. The aim is to identify which events belong to which actor.

[0093] Now, other aspects of how cybersecurity deviation scores, cybersecurity deviation statistics, or probability scores can be updated based on how log events are linked together will be made public.

[0094] Generally, the embodiments disclosed herein are based on the understanding that the links between logged events can change as more information becomes available. An event that was previously benign may become malicious and thus enter a malicious graph.

[0095] In some embodiments, the probability score, network security deviation score, and network security deviation statistics for each log event are updated based on the types of other log events and the probability score, network security deviation score, and network security deviation statistics linked to that log event.

[0096] In some embodiments, the security analysis module 200 is configured to perform (optional) step S112:

[0097] S112: The security analysis module 200 determines whether these log events belong to the same attacker based on how they are linked together and the updated probability score, network security deviation score, and network security deviation statistics.

[0098] Similar determinations can be made regarding whether log events belong to the same benign user and whether log events belong to the same attacker.

[0099] As new events are logged, they not only provide more information about possible ongoing cyberattacks, but also offer two directions for intent interpretation: first, the probability of malicious intent in past (weak) links that may have been assessed as most likely benign can be reassessed; second, the probability of malicious intent in new logging events can be assessed from malicious logging events of known links.

[0100] In the example above, for a new log entry event where the intent interpretation probability is represented as a "deliver" stage event, two steps can be taken: first, potentially malicious events that have already been linked can be used to estimate the intent probability of the new log entry event; second, the new log entry event can be used to re-evaluate the intent probabilities of previously linked events (as well as those with potentially benign intent). This can also be achieved using reinforcement learning.

[0101] Once linked events are identified, and optional cybersecurity deviation scores and statistics for the relevant log events are updated, the probability that the linked events are part of an ongoing cyberattack can be reassessed. Furthermore, previously unlinked log events can also be linked based on the reassessed probability values ​​and optional cybersecurity deviation scores and statistics.

[0102] Now, it will be made public whether the logs documented the incident as benign or part of a cyberattack.

[0103] Statistical methods can be used to predict what other events might be logged in response to an ongoing cyberattack. Specifically, in some embodiments, the security analysis module 200 is configured to perform (optionally) step S114:

[0104] S114: The security analysis module 200 predicts other events that will be recorded as part of a cyberattack based on how log events are linked together and the probability scores, network security deviation scores, and network security deviation statistics that may be updated.

[0105] This information can be used to determine appropriate countermeasures to mitigate cyberattacks. Specifically, in some embodiments, the security analysis module 200 is configured to perform (optionally) step S116:

[0106] S116: The security analysis module 200 determines at least one network attack mitigation action to be taken based on events that have been predicted to be recorded as part of a network attack.

[0107] In further aspects, as part of event linking and a reassessment of intent probabilities, templates for known cyberattack lifecycle stages can be used. However, as the details of the ongoing cyberattack emerge with the acquisition of graphs, ratings, probabilities, biases, statistics, and other data, a signature of the cyberattack is generated. This signature includes a graph where each vertex represents a logged event, and each edge represents a probability value. Other data, such as ratings, statistics, and time differences between events, can be added to this graph. The signature of the cyberattack can be transformed into a vector that can be compared with other signatures for proximity and grouping. If the signature deviates significantly from other signatures, it indicates a new type of cyberattack. Therefore, in some embodiments, a cyberattack is identified as a new type of cyberattack when the combination of known cyberattack lifecycle stages does not perfectly match any of the aforementioned cyberattack lifecycle templates.

[0108] Furthermore, log events can be stored in a database and can be searchable. This allows log events to be searched based on specific intent as part of incident response or threat hunting.

[0109] In further aspects, such as the visualization of linked log events, can be provided to the user interface, such as using labeled time charts or as icons. Ratings, statistics, and / or probability values ​​can be used to determine the color of the labels, thus providing dynamic coloring of the labels as the ratings, statistics, and / or probability values ​​are updated.

[0110] Figure 3 Four host computers A, B, C, and D are schematically shown, along with events 310a, 310b, 310c, 310d, and 310e that occur and are recorded along the timeline. Figure 3The diagram further illustrates how probability values ​​are evaluated and adjusted over time. The first event, 310a, is evaluated at 320a as a "delivery" event due to the specific source and destination of numerous connections, and its probability value; alternatively, this event could be benign. The second event, 310b, is evaluated at 320b as a "delivery" event due to received data, but it could also be benign. However, since host computer B is identical for both events 310a and 310b, this information can be used to link these two events via a malware attack. Therefore, the probability value for both events being malicious is increased at 320c. The third event, 310c, is evaluated at 320d as an "executive" event and is linked to the same host computer B. Therefore, the probability value for the "delivery" event is further increased again at 320e via the link between the host computer and the malware attack. If a fourth event 310d, similar to the first event 310a, is recorded, then due to the previously linked events and the increased probability, the fourth event 310d is immediately assigned a high probability of being malicious at 320f. Similarly, if a fifth event 310e, similar to the second event 310b, is recorded, then due to the previously linked events and the increased probability, the fifth event 310e is immediately assigned a high probability of being malicious at 320g.

[0111] Figure 4 The components of the security analysis module 200 according to an embodiment are illustrated schematically according to some functional units. A computer program product 610 (such as one capable of execution on, for example, a storage medium 230) is used. Figure 6 The processing circuit 210 may be provided by any combination of one or more of the suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., storing the software instructions shown in the diagram. The processing circuit 210 may also be provided as at least one application-specific integrated circuit (ASIC) or field-programmable gate array (FPGA).

[0112] Specifically, processing circuitry 210 is configured to cause security analysis module 200 to perform the set of operations or steps disclosed above. For example, storage medium 230 may store the set of operations, and processing circuitry 210 may be configured to retrieve the set of operations from storage medium 230 to cause security analysis module 200 to perform the set of operations. The set of operations may be provided as a set of executable instructions.

[0113] Therefore, processing circuitry 210 is thus configured to perform the methods disclosed herein. Storage medium 230 may also include a permanent storage device, such as any one or any combination of magnetic storage, optical storage, solid-state storage, or even remotely mounted storage. Security analysis module 200 may further include communication interface 220, which is configured at least to communicate with other functions, nodes, entities, modules, and devices of network environment 100. Thus, communication interface 220 may include one or more transmitters and receivers, comprising analog and digital components. Processing circuitry 210 controls the general operation of security analysis module 200, for example, by sending data and control signals to communication interface 220 and storage medium 230, by receiving data and reports from communication interface 220, and by acquiring data and instructions from storage medium 230. Other components and related functions of security analysis module 200 are omitted to avoid confusion with the concepts presented herein.

[0114] Figure 5 The components of the security analysis module 200 according to an embodiment are illustrated schematically according to some functional modules. Figure 5 The security analysis module 200 includes multiple functional modules: an acquisition module 210a, which is configured to execute step S102; a matching module 210c, which is configured to execute step S106; a linking module 210d, which is configured to execute step S108; and a determination module 210e, which is configured to execute step S110. Figure 5 The security analysis module 200 may further include any one of the following optional functional modules: the acquisition module 210b configured to perform step S104, the determination module 210f configured to perform step S112, the prediction module 210g configured to perform step S114, and the determination module 210h configured to perform step S116.

[0115] Generally, each functional module 210a-210h may be implemented solely in hardware in one embodiment, while in another embodiment it may be implemented in software. That is, the latter embodiment has computer program instructions stored on storage medium 230, which, when executed on the processing circuitry, cause the security analysis module 200 to perform the above-mentioned combined... Figure 5The corresponding steps described herein. It should also be noted that even though these modules correspond to parts of a computer program, they do not need to be separate modules within it; rather, their software implementation depends on the programming language used. Preferably, one or more or all functional modules 210a-210h can be implemented by processing circuitry 210 and may cooperate with communication interface 220 and / or storage medium 230. Processing circuitry 210 can therefore be configured to retrieve instructions from storage medium 230 as provided by functional modules 210a-210h and execute those instructions to perform any of the steps disclosed herein.

[0116] Security analysis module 200 can be provided as a separate device or as part of at least one other device. For example, security analysis module 200 can be provided as part of, or include, SIEM module 180 and / or SOAPA module 190. Alternatively, the functionality of security analysis module 300 can be distributed among at least two devices or nodes. These at least two nodes or devices can be part of the same network segment or can be distributed among at least two such network segments. Thus, a first portion of the instructions executed by security analysis module 200 can be executed in a first device, while a second portion of the instructions executed by security analysis module 200 can be executed in a second device; the embodiments disclosed herein are not limited to any particular number of devices on which the instructions executed by security analysis module 200 can be executed. Therefore, the methods according to the embodiments disclosed herein are suitable for execution by security analysis module 200 residing in a cloud computing environment. Therefore, although in Figure 4 A single processing circuit 210 is shown, but processing circuit 210 can be distributed among multiple devices or nodes. The same applies. Figure 5 Functional modules 210a-210h and Figure 6 Computer program 620.

[0117] Figure 6 An example of a computer program product 610 including a computer-readable storage medium 630 is shown. A computer program 620 may be stored on this computer-readable storage medium 630, which may cause processing circuitry 210 and entities and devices operatively coupled thereto, such as a communication interface 220 and a storage medium 230, to perform the methods according to the embodiments described herein. Therefore, computer program 620 and / or computer program product 610 may provide components for performing any of the steps disclosed herein.

[0118] exist Figure 6In the example, computer program product 610 is shown as an optical disc, such as a CD (Compact Disc), DVD (Digital Universal Disc), or Blu-ray Disc. Computer program product 610 can also be embodied as memory, such as random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or electrically erasable programmable read-only memory (EEPROM), and more particularly as a non-volatile storage medium in the form of external memory, such as USB (Universal Serial Bus) memory or flash memory such as compact flash memory. Therefore, although computer program 620 is schematically shown herein as a track on the depicted optical disc, computer program 620 can be stored in any manner suitable for computer program product 610.

[0119] The inventive concept has been described above primarily with reference to several embodiments. However, as will be readily understood by those skilled in the art, other embodiments besides those disclosed above are also possible within the scope of the inventive concept as defined by the appended claims.

Claims

1. A method for identifying network attacks in a network environment (100), the method being executed by a security analysis module (200), the method comprising: Obtain (S102) log recording events, which have occurred and been recorded in the network environment (100), wherein each log recording event is associated with a network security deviation score and network security deviation statistics; Each log event is matched with a network attack lifecycle stage by comparing the characteristics of each log event given by the network security deviation statistics with known network attack lifecycle stages (S106). The log-recording events are linked together (S108) by forming at least one chain, wherein each vertex represents a log-recording event, and each edge represents a probability value that the event is malicious, wherein each chain corresponds to a type of network attack given by a combination of the known network attack lifecycle stages, and wherein the network security deviation score and the network security deviation statistics are updated based on how the log-recording events are linked together; and Based on how the log events are linked together and the updated network security deviation score and network security deviation statistics, determine (S110) whether the log events are benign or part of a cyberattack.

2. The method according to claim 1, wherein, All logged events have a uniform, machine-readable format.

3. The method according to claim 1 or 2, wherein, The security deviation score for each logged event is proportional to the probability that the event was part of a cyberattack.

4. The method according to claim 1 or 2, wherein, The security deviation statistics for each log event are defined as the standard deviation of the cybersecurity deviation score for the same event.

5. The method according to claim 1 or 2, wherein, The comparison involves selecting the cyberattack lifecycle stage that best matches the combination of event type, cybersecurity deviation score, and cybersecurity deviation statistics for each logged event.

6. The method according to claim 1 or 2, further comprising: (S104) Obtain a probability score for each log event that is part of the network attack, wherein the matching is based on the network security deviation statistics for each log event.

7. The method according to claim 6, wherein, The probability score for each log event is based on the host data and network data associated with that log event, including connection direction, protocol, number of connections, and failed login attempts.

8. The method according to claim 6, wherein, Each event is marked as malicious or benign based on the probability score of the log event, and the matching depends on which log events are marked as malicious and which log events are marked as benign.

9. The method according to claim 1 or 2, wherein, The log events are linked together according to an ordered sequence of occurrence, wherein the ordered sequence is given by a combination of known network attack lifecycle phases.

10. The method according to claim 9, wherein, The combination of the known network attack lifecycle phases is based on a set of network attack lifecycle templates, wherein each network attack lifecycle template includes its own unique order of occurrence and the characteristics of the known network attack lifecycle phases.

11. The method according to claim 1 or 2, wherein, During the link, each logging event is provided with a network attack lifecycle label.

12. The method according to claim 6, wherein, Based on the types of other log events and the network security deviation scores and network security deviation statistics linked to those log events, update the probability score, network security deviation score, and network security deviation statistics for each log event.

13. The method of claim 12, further comprising: Based on how the log events are linked together and the updated probability score, network security deviation score, and network security deviation statistics, determine (S112) whether the log events belong to the same attacker.

14. The method according to claim 1 or 2, further comprising: Based on how the log events are linked together and the updated network security deviation score and network security deviation statistics, it is predicted (S114) that other events will be recorded as part of the network attack.

15. The method of claim 14, further comprising: Based on events that have been predicted to be recorded as part of the cyberattack, determine (S116) at least one cyberattack mitigation action to be taken.

16. The method of claim 10, wherein, When the combination of the known network attack lifecycle stages does not fully match any of the network attack lifecycle templates, the network attack is identified as a new type of network attack.

17. A security analysis module (200) for identifying network attacks in a network environment (100), the security analysis module (200) comprising processing circuitry (210) configured to cause the security analysis module (200) to: Obtain log recording events, which have occurred and been recorded in the network environment (100), wherein, Each log event is associated with a cybersecurity deviation score and cybersecurity deviation statistics; Each log event is matched with a network attack lifecycle stage by comparing the characteristics of each log event given by the network security deviation statistics with known network attack lifecycle stages. The log-recorded events are linked together by forming at least one chain, wherein each vertex represents a log-recorded event, and each edge represents a probability value that the event is malicious, wherein each chain corresponds to a type of cyberattack given by a combination of the known cyberattack lifecycle stages, and wherein the cybersecurity deviation score and the cybersecurity deviation statistics are updated based on how the log-recorded events are linked together; and Based on how the logged events are linked together, as well as updated cybersecurity deviation scores and cybersecurity deviation statistics, it is determined whether the logged events are benign or part of a cyberattack.

18. The security analysis module (200) according to claim 17 is further configured to perform the method according to any one of claims 2 to 16.

19. A computer-readable storage medium (630) having thereon stored a computer program (620) for identifying network attacks in a network environment (100), wherein, The computer program includes computer code that, when executed on the processing circuitry (210) of the security analysis module (200), causes the security analysis module (200) to: Obtain (S102) log recording events, which have occurred and been recorded in the network environment (100), wherein each log recording event is associated with a network security deviation score and network security deviation statistics; Each log event is matched with a network attack lifecycle stage by comparing the characteristics of each log event given by the network security deviation statistics with known network attack lifecycle stages (S106). The log-recording events are linked together (S108) by forming at least one chain, wherein each vertex represents a log-recording event, and each edge represents a probability value that the event is malicious, wherein each chain corresponds to a type of network attack given by a combination of the known network attack lifecycle stages, and wherein the network security deviation score and the network security deviation statistics are updated based on how the log-recording events are linked together; and Based on how the log events are linked together and the updated network security deviation score and network security deviation statistics, determine (S110) whether the log events are benign or part of a cyberattack.

Images