Method for intrusion detection in industrial automation and control system

Abstract

A method and system for automatic signalling an alert when a possible intrusion occurs in an industrial automation and control system, based on security events which occur in the industrial automation and control system or are externally fed into the system. The method includes the steps of: (a) determining a correlation of a first and second security event and storing the correlation in an event database, wherein the correlation includes a probability that the first security event is followed by the second security event within a normalized time period, (b) identifying a candidate event as the first security event, based on event information of the candidate event, upon occurrence of the candidate event, (c) classifying the candidate event as anomalous when the probability exceeds a predetermined threshold and no second security event follows the candidate event within the normalized time period, and (d) signalling the alert indicating the candidate event.

Claims

1. A method for automatic signalling an alert when a possible intrusion occurs in an industrial automation and control system, comprising: connecting an event collector with multiple event providers distributed in the industrial automation and control system, the event providers transmitting security events to the event collector and being at least one of embedded devices, security systems, or computers, determining, via a processor of the event collector, a correlation of a first security event E.sub.1 and a second security event E.sub.2 without requiring semantic information about the first security event E.sub.1 and the second security event E.sub.2, and storing the correlation in an event database, wherein the correlation includes a probability P.sub.E1,E2 that the first security event E.sub.1 is directly followed by the second security event E.sub.2 within a normalised time period, the normalised time period being an average time between occurrences of the first security event E.sub.1 and the second security event E.sub.2, identifying, via an analyzer having a processor for training and probability analysis, a candidate event as the first security event E.sub.1, based on event information of the candidate event, upon occurrence of the candidate event, the analyzer being configured to access the event database, classifying the candidate event as anomalous when the probability P.sub.E1,E2 exceeds a predetermined threshold and no second security event E.sub.2 follows the candidate event within the normalised time period, and signalling the alert indicating that the candidate event is anomalous for inspection into whether an intrusion has occurred, wherein the method further comprises machine learning of the processor in the event collector by accumulating the correlation of the first security event E.sub.1 and the second security event E.sub.2 upon their re-occurrence, and updating the event database.

2. The method according to claim 1, wherein the predetermined threshold P.sub.thres is 0.8.

3. The method according to claim 1, wherein the probability P.sub.E1,E2 is a distributed probability.

4. The method according to claim 1, wherein the probability P.sub.E1,E2 increases with elapsed time since the occurrence of the first security event E.sub.1.

5. The method according to claim 1, wherein the event information comprises a provider identification and an event identification.

6. An alert system for automatic signalling when a possible intrusion occurs in an industrial automation and control system, the alert system comprising: an event collector configured to connect to multiple event providers distributed in the industrial automation and control system and having a processor to receive security events from the event providers, the event collector determining a correlation of a first security event E.sub.1 and a second security event E.sub.2 without requiring semantic information about the first security event E.sub.1 and the second security event E.sub.2, the event providers being at least one of embedded devices, security systems, or computers, an event database connected to the event collector, the event database storing the correlation upon being transmitted from the event collector, wherein the correlation includes a probability P.sub.E1,E2 that the first security event E.sub.1 is followed by the second security event E.sub.2 within a normalised time period, the normalised time period being an average time between occurrences of the first security event E.sub.1 and the second security event E.sub.2, the processor of the event collector being configured for machine learning by accumulating the correlation of the first security event E.sub.1 and the second security event E.sub.2 upon their re-occurrence, and updating the event database, and an analyzer having a processor for training and probability analysis, the analyzer being configured to access the event database and retrieve the probability P.sub.E1,E2, wherein the analyzer identifies a candidate event as the first security event E.sub.1, based on event information of the candidate event, upon occurrence of the candidate event, the analyzer classifies the candidate event as anomalous when the probability P.sub.E1,E2 exceeds a predetermined threshold and no second security event E.sub.2 follows the candidate event within the normalised time period, and the analyzer signals the alert indicating that the candidate event is anomalous for inspection into whether an intrusion has occurred.

7. The system according to claim 6, wherein the predetermined threshold P.sub.thres is 0.8.

8. The system according to claim 6, wherein the probability P.sub.E1,E2 is a distributed probability.

9. The system according to claim 6, wherein the probability P.sub.E1,E2 increases with elapsed time since the occurrence of the first security event E.sub.1.

10. The system according to claim 6, wherein the event information comprises a provider identification and an event identification.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The subject matter of the invention will be explained in more detail in the following text with reference to preferred exemplary embodiments which are illustrated in the attached drawings, in which:

(2) FIG. 1 schematically shows the correlations of several security events happening in the past, where the correlations are identified and stored in the event database, according to the present invention; and

(3) FIG. 2 schematically shows a system for signalling an alert according to the present invention, where the security events from two event providers are collected by the event collector, and the analysis module provides training and probability analysis as well as the anomaly detection.

(4) The reference symbols used in the drawings, and their primary meanings, are listed in summary form in the list of designations. In principle, identical parts are provided with the same reference symbols in the figures.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

(5) The present invention can recognize that an industrial automation and control system (IACS) has a different mixture of devices and systems that provide security events. These systems differ not only in how security events are represented, but also in the meaning of the individual fields of an event. In addition, each IACS may have different guidelines for naming devices, users and systems. Thus, it is infeasible for vendors to create intrusion detection rule sets that apply to every IACS without requiring major adaptation.

(6) Therefore, the present invention avoids relying on a semantic definition of security events or on a common format. In contrast, it automatically establishes correlations between different security-related events and can recognize event patterns that have not been seen before. Table 1 below illustrate several exemplary security events that may occur in the ICSA:

(7) TABLE-US-00001 TABLE 1 Date/Time Provider ID Event ID Event Info 01-01-14, 10:32:34 B98 A323 John Smith, 23 01-01-14, 10:34:21 A2323 E3423 User: chjsmi 01-01-14, 10:37:34 R23 VP23 <Event> <Account> chjsmi </Account> <IP> 90.54.32.14</IP> </Event> 01-01-14, 11:41:34 B99 A324 John Smith, 23

(8) Without further analysis, correlating these events is a hard problem, as the meaning of the IDs for providers and events may be unclear as shown in Tables 2 and 3 below.

(9) TABLE-US-00002 TABLE 2 Provider ID Description B98 Door-Entry System A2323 Control System R23 VPN Access B99 Door-Exit System

(10) TABLE-US-00003 TABLE 3 Event ID Description A323 Entry successful E3423 Login successful VP23 Login successful A324 Exit successful

(11) As shown the format of the event info field differs between different security event providers. To get an understanding of what has happened, a computer system would have to know the semantic meaning of each event info field, translate them into a common format, correlate them and run analytics with pre-defined rules. This can be a very time-consuming engineering task, especially if the providers of the security events are third-party devices.

(12) A human, on the other hand, can in this example conclude that John Smith entered the building, accessed the control system and then logged into the VPN from the outside, which could indicate a security anomaly, or be perfectly fine, as he is preparing a mobile device for work in the field. To judge the relevance of such a situation in terms of security, it is important to compare this situation with the past and other everyday situations. The system will perform such an automated analysis of the occurrence of these events, including an analysis of the difference in the event info fields, e.g. the number of characters, etc.

(13) The internal workings are, that the system takes a series of new security events, performs a query within the set of past data whether such series of events has occurred before in the same or slightly different form (e.g., using edit distance matching or other metrics), counts the number of found matches, and puts it into relation to the overall amount of data. If this relation is above a certain threshold, the series of events is considered as legitimate, otherwise it is considered anomalous.

(14) FIG. 1 illustrates an exemplary embodiment of the present invention. The event e10 that John Smith entered the door was provided with event information John Smith, 23. After John entered the door, he logged into the computer system. This event e20 happened 2 minutes after the event e10. These two events may occur very often consecutively, since John usually enters the door in order to login into the computer. Based on this information, the system according to the present invention can determine the probability, e.g. how certain is it that the event e20 will occur directly after event e10. For instance, in the exemplary embodiment, the probability is 90%. Further, the system according to the present invention can also evaluate a normalised time period, e.g. when John enters the door after what time he usually logs into the computer system. The normalised time can be the average of the times between the occurrence of events e10 and e20, e.g. 2 min. That is, when John enters the door, the probability that he logs into the computer system is 90% within 2 minutes.

(15) After John logs into the computer system, he usually starts to work. For instance, it is unlikely he logs out e30 after only a couple of minutes. After several hours, John finishes his work and logs out from the computer system, e.g. likely after three hours, very likely four hours, and most likely five hours. Thus, the probability that he logs out may increase with lapsed time.

(16) Based on the evaluation above, the correlations between event e10 and e20 as well as between e20 and e30 can be determined. Now, the system according to the present invention can be used for signalling a possible intrusion. For instance, when a person successfully enters the door as John and does not log into the computer system within 2 minutes, it is an indication of a possible intrusion, e.g. the person obtained the door access card and is in reality not authorised for entering the door. The system according to the present invention can now signal an alert to the security operators who can then inspect if there is something wrong. Thus, the present invention can assist the security operator for intrusion detection by automatic signalling an alert.

(17) FIG. 2 shows an exemplary embodiment of the system according to the present invention. An event provider 1 and 2 for initiating the event can be in form of embedded devices, security systems, or regular computers. An event collector module 3 collects these security events and stores them within a database 4. An analysis module 5 accesses the database, and performs a training and probability analysis on them. This data can be used for anomaly detection, i.e. whenever a pre-defined number of events have been newly inserted into the database, the anomaly detection can be performed. The user or security operator 7 can interact with the system through a user interface 6.

(18) An exemplary training algorithm for determining probabilities according to the present invention can be used in the analysis module:

(19) Firstly, for each unique security event E in a list of security events L.sub.e, the overall occurrences of the event E can be determined, where each of these single occurrences can be referred to as E.sub.1, E.sub.2 . . . E.sub.n: count, for each unique security event F that follows E.sub.1 to E.sub.n within a user-specified time frame x, the number n of occurrences of F, if n is greater than a user-specified number, mark this event as a correlation, where the probability of this occurrences is computed by dividing the number of occurrences through the number of events E.sub.1, E.sub.2 . . . E.sub.n.

(20) The result of the above algorithm can be, for each security events, a list of possible follow-up events with an associated probability. In order to determine an anomaly, the following anomaly detection algorithm can be executed: identify a security event E.sub.v to be monitored, look up the follow-up events and the probabilities determined by the previous algorithms for each follow-up events E.sub.f that is above a certain user defined threshold probability, put E.sub.f into a list of follow-up events L.sub.f, wait until another security event E.sub.v1 is received or a timeout has passed, if E.sub.v1 is in L.sub.f, the algorithm is restarted with the event E.sub.v1. if timeout has passed and no security event has been received, signal an alert.

(21) While the invention has been described in detail in the drawings and foregoing description, such description is to be considered illustrative or exemplary and not restrictive.

(22) Variations to the disclosed embodiments can be understood and effected by those skilled in the art and practising the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word comprising does not exclude other elements or steps, and the indefinite article a or an does not exclude a plurality. The mere fact that certain elements or steps are recited in distinct claims does not indicate that a combination of these elements or steps cannot be used to advantage, specifically, in addition to the actual claim dependency, any further meaningful claim combination shall be considered disclosed.