Safe guard detection for unexpected operations in a MES system

11436321 · 2022-09-06

Assignee

Inventors

Cpc classification

International classification

Abstract

A method for performing a safe guard detection of unexpected operations launched by an operator for a manufacturing execution system (MED system) is based on a first database containing a set of operations, a set of operators, calendar information for a shift and calendar information for the equipment of the MES-system. The MES-systems further has a second database containing a login history of carried out logins of the operator. The detection of a malicious operation is carried out as to whether the operation complies with a set of rules defining allowed operations or with a learning module, in which specific roles of operators are contained and whether an operation complies with a specific role. In case of non-compliance, the operation is stored as an entry in an event trace file for generating alerts.

Claims

1. A method for a safe guard detection of unexpected operations launched by an operator for a manufacturing execution system (MES-System), wherein the MES-System includes: a first database including: a set of operations; a set of operators; calendar information for a shift; calendar information for equipment of the MES-System; a second database including: a login history of carried out logins of the operator; a set of rules defining allowed combinations of operations being launched by the operator at a specific time according to a content of the first database; which method comprises the steps of: checking launched operations as to whether the launched operations comply with the set of rules; storing a launched operation together with data identifying the operator and operator login data as an entry in an event trace file in case of non-compliance of the launched operation; analyzing entries in the event trace file by an intrusion detection system; generating alerts based on an analysis of the entries in the event trace file; and wherein the step of checking launched operations includes at least one step selected from the group consisting of: 1) crosschecking of logins for detecting, whether the operator logs-in himself at different places at a same time where such simultaneous logins may not be expected, 2) determining whether an operation complies with an order scheduling being defined by the calendar information in the first database, and 3) performing a comparison of a login time of the operator with the calendar information for a shift stored in the first database.

2. The method according to claim 1, wherein the step of checking launched operations includes the step of crosschecking of logins for detecting, whether the operator logs-in himself at different places at a same time where such simultaneous logins may not be expected.

3. The method according to claim 1, wherein the step of checking launched operations includes the step of determining whether an operation complies with an order scheduling being defined by the calendar information in the first database.

4. The method according to claim 1, wherein the step of checking launched operations includes the step of performing a comparison of a login time of the operator with the calendar information for a shift stored in the first database.

5. A method for a safe guard detection of unexpected operations launched by an operator for a manufacturing execution system (MES-System), where the MES-System includes: a first database including: a set of operations; a set of operators; calendar information for a shift; calendar information for equipment of the MES-System; a second database including a login history of carried out logins of the operator; a machine learning model; which method comprises the steps of: cataloging the operator in a given role in the MES-System; feeding, in a learning phase, a learning module being part of a machine learning model with launched operations for that role; checking, in a run time phase, the launched operations as to whether the launched operations comply with the operations in the learning module; storing a launched operation together with data identifying the operator and operator login data as an entry in an event trace file in case of non-compliance of the launched operation; analyzing entries in the event trace repository by an intrusion detection system and based on an analysis generating alerts; and wherein the step of checking the launched operations includes at least one step selected from the group consisting of: 1) crosschecking of logins for detecting, whether the operator logs-in himself at different places at a same time where such simultaneous logins may not be expected, 2) determining whether an operation complies with an order scheduling being defined by the calendar information in the first database, and 3) performing a comparison of a login time of the operator with the calendar information for a shift stored in the first database.

6. The method according to claim 5, which further comprises repeating the learning phase in order to get a refinement of allowed operations.

7. The method according to claim 5, wherein the machine learning model input comprises: a user role; operations to be performed or launched; and a time frame.

8. The method according to claim 5, wherein the step of checking launched operations includes the step of crosschecking of logins for detecting, whether the operator logs-in himself at different places at a same time where such simultaneous logins may not be expected.

9. The method according to claim 5, wherein the step of checking launched operations includes the step of determining whether an operation complies with an order scheduling being defined by the calendar information in the first database.

10. The method according to claim 5, wherein the step of checking launched operations includes the step of performing a comparison of a login time of the operator with the calendar information for a shift stored in the first database.

11. The method according to claim 10, wherein the calendar information for the shift indicates whether the operator is meant to be at work and a geographical area at which the operator is expected to be at work.

12. The method according to claim 4, wherein the calendar information for the shift indicates whether the operator is meant to be at work and a geographical area at which the operator is expected to be at work.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

(1) FIG. 1 is an illustration showing a typical and not fraudulent situation with an operator working for different sites around the world;

(2) FIG. 2 is an illustration of an example of a procedure for malicious operation detection;

(3) FIG. 3 is an illustration of a situation at a site containing two production lines each requiring a line operator close to that production line; and

(4) FIG. 4 is an illustration of a structure of a machine-learning model.

DETAILED DESCRIPTION OF THE INVENTION

(5) For the sake of a uniform nomenclature, the term «operator» will be consequently used although in a specific context the term «user» is more common, as e.g. «user administration» of for accessing an IT-System.

(6) A safe guard detection for unexpected operations being launched by an operator for a MES system preferably includes the following events and/or categories.

(7) 1. Login Not Compliant with the Planned Shift

(8) The information belonging to a shift calendar is used to verify whether an incoming login can be expected. In this context reference is made to FIG. 1, which shows two sites siteA, siteB on different continents. The before mentioned verification based alone on the static shift calendar is in a situation according to FIG. 1 obviously not applicable. Not in all cases, but in certain cases a login has to be permitted outside the allowed time-periods according to the shift calendar. This category “Login not compliant with the planned shift” alone does not allow to identify an operation launched by a malicious operator.

(9) 2. Shift Calendar Information

(10) The category “Shift Calendar Information” can however give a precise idea whether an operator is meant to be at work and in which (geographical) area he is expected to be at work, example:

(11) An operator is performing an operation on resources, but according to the shift calendar information, he was not scheduled to be at work in that moment. This is not covered by point 1 since in this case a malicious user managed to bypass the authentication layer.

(12) 3. Equipment Shift Information

(13) The equipment of a site and/or production line is considered as a resource. As a consequence this equipment is subject to a shift scheduling. This consideration on a category “equipment shift information” is therefore similar to cipher 2 as explained above, where the category “shift calendar information” relates to operators (=persons).

(14) 4. Launched Operation Not Compliant with the Order Scheduling

(15) An operation launched by an operator is compared against what is planned according to a given order. The result of such a comparison can be used for detecting potentially operations launched by a malicious operator. In a not very precise language sometimes such an operation is also called a malicious operation. The result of this comparison leads to an event called “Launched operation not compliant with the order scheduling”.

(16) 5. Crosschecking of Logins/Logouts with the User Management Login History

(17) Intentionally the term user management is used for this category “Crosschecking of logins/logouts” in order to make a relation to the common user management for accessing an IT-System. The usual user management covers also the management of the operators for a MES-System. A user management includes the creation of a login history file in which all logins and logouts of a user or of a group of users are recorded. Such a login history file allows a creation of statistical data as e.g. the usual login and logout time. Deviations of a login time or a logout time from the usual statistical login time or logout time can be used as a warning indicator, which should be notified for further clarification or investigation. This warning indicator can be a basis with other indicators for a detection of a malicious operator. The above explained recording of deviations is here summarized under the term “crosschecking of logins/logouts with the user management log-file”.

(18) This category “Crosschecking of logins/logouts” is especially useful for tracking cases where the same operator logs-in himself at different places at the same time where such simultaneous logins may not be expected. FIG. 3 illustrates this: A so-called line operator Op-L or Op-LB has to be physically present at the production line for which he has the role “line operator”. Instantaneous login's can be tracked in a completely different way. It does not need a posteriori analysis and can performed directly by the user management. To this category belong cases where logins do not happen at the exactly same time but where logins are very close (in time) but far (in space). For instance, considering a multi lines site, with a line A very far from a line B, e.g. d=300 m in FIG. 3, and where there is no transportation available from line a To line B. Assuming a user login takes place at a panel of line A and some seconds later at a panel of line B. Under consideration of a set up as depicted before it can be excluded that a line operator has moved from one line to another line in that short time. Such login cases represent a good indication that a malicious operator intends to start a harmful operation. Of course, the time interval has to be defined at engineering time for that site comprising several production lines. A reasonable time interval (e.g. >5 min) helps not to produce too many «false positive». The term «false positive» stands for a result that indicates a given condition exists, when it does not. Additionally in the user management can be foreseen not to allow multiple logins of the same operator or when multiple logins are allowed, that some operations need a single login otherwise, they may not be launched.

(19) 6. Statistical Analysis on Unauthorized Requests

(20) This category “Statistical analysis on unauthorized requests” is explained by an example.

(21) An operator tries to access a resource, which he should not even know. Of course, it is not suggested to trace a single error because there is no clue if it is due to an error or a voluntary operation. For this category, the frequency is a good indicator. E.g. a potential suspected operation launched by a specific operator can be the repeated request of resource that always results in an error or returns without success (i.e. for access denial). This situation reveals a strange behavior of said operator, since it is always failing systematically. Technically speaking, this can be the proof of malicious scanning activities.

(22) In order to detect operators with malicious intentions a statistical approach contributes to a solution (e.g. via an unsupervised neural network, for instance trained following the paradigm of Self-Organizing Map). This statistical approach is a base for defining a correct behavior and for recording the current operation deviation. The recorded deviations can vary depending from the resource, and so it should be a tolerance:

(23) A human resource (mapped in a shift calendar) can be subjected to a higher degree of variation respectively deviation.

(24) An equipment or a tool, being programmed (mapped in an equipment calendar) should need a small tolerance.

(25) 7. Statistical Analysis of Operations Launched by an Operator

(26) A statistical analysis of operations launched by an operator is used in order to reveal deviations. Example of such an analysis: A specific operation, which is permitted to be launched by a specific operator but this operation should not be launched in the daily routine of the operator.

(27) The concept here is that a set of “roles” is configured for the MES-system. These roles are not referring to Access and Authorization roles, but to “operational” ones; examples:

(28) Role “Line3 Packaging operator”,

(29) Role “forklift driver”,

(30) Role “Work Center X assembly line worker” and so on.

(31) Each worker/operator is catalogued in at least one of these roles.

(32) With this statistical analysis of operations a behavioral model for each role is created in order to define the most common operations patterns. The model creation and definition can be performed via machine learning algorithms (both supervised and unsupervised ones). This allows bypassing the privacy problem on tracking the operations launched by each operator. The produced model gives a statistical deviation analysis. However in practice the operator/worker behavior is subject to changes (typically workers get more used to their tasks with time), so a periodic refinement cycle for refining the model is required. Even in this case, the machine learning can become a good approach.

(33) The above described detection system is rule based. However, the same inputs can be used for creating a machine-learning model, for instance, for having the limits tuned on the real use case (and refined too).

(34) Reference is made to FIG. 4: The machine learning model input comprises the following tuple:

(35) The user role, this should be the main cluster identifier,

(36) the activities/operations to be performed or launched, and

(37) the time frame.

(38) The results of the analysis of the operator behavior deviations serve as an input for an Intrusion Detection System IDS. Each time a specific operation has been launched and may be considered as an operation launched by a suspected operator such an event will entered into an event log-file Event Tracer EvTr (cf. FIG. 2) and which is stored a repository. Those events will be analyzed by the customer IDS.

(39) It is necessary to adapt an exception manager able to suppress some warnings related to not conventional behaviors but completely in the norm. For instance, an operator can access remotely a resource out from his shift. It will be the Site\Line Security Manager duty to define properly the exceptions, not to overdo and define very fine one. Otherwise, each time when a positive is detected, both false and true, this positive will simply be discarded due to some exception.

(40) For the category “Shift Calendar” it is necessary to specify a time plan with a combination of shift and exception. More generically, this represents a combination of time-periods. A time-period can be characterized for being associated to a certain class, for instance

(41) “night-shift”,

(42) “daily-shift”,

(43) “planned strike”, etc.

(44) In our invention, we always consider that a time-period and a resource (it may be a human or equipment) is associated to a time-period in order to have a temporal description.

(45) FIG. 2 shows an embodiment of a method for malicious operation detection. It is assumed that a (remote) login to a site from a malicious operator Op-M has taken place. It has to be emphasized that this case represents already a very pessimistic respectively a severe case since several layers of access security have been bypassed: Authentication layers. Just for explaining the geographical setup reference is made to FIG. 1: Two production sites A and B belong to the same group of companies (not necessarily to the same company): SiteA and SiteB located according to FIG. 1 on different continents. Assume in production SiteA works Operator Op-A. Somehow, a malicious operator Op-M got access to the credentials of the current operator Op-A, e.g. via social engineering. The social engineering operation is actually directed to obtain information from the current production located in SiteB. Like it often happens for multinational company, a shared corporate User and Access Management allows Operator Op-Z to connect himself to SiteB, for instance, granting maintenance capability. However, no maintenance activity is currently scheduled and the Site Security Manager did not define any exception in the intrusion detection system.

(46) Again, reference is made to FIG. 2: Assume the Malicious Operator Op-M manages to login 1 successfully since the credentials are valid and correct. The login activity is passed as input to the proposed detection system. In case of a machine-learning model, it will compare the pattern with the produced model and verify how it diverges from the normality, cf 2A in FIG. 2. In case of a rule-based algorithm, a process will compare the current login with the historical login, verifying if an operator is meant to be in the proper site and if an exception has been configured, cf 2B in FIG. 2. It has to be emphasized, that these two detections are mutually exclusive.

(47) In case the operation is labelled as a malicious one, cf 3 in FIG. 2, because no exception has been configured, an entry into the event trace EvTr is written. The IDS will automatically analyse this entry 4 and if required perform the needed actions.

(48) A possible problem will raise if an exception was indeed configured for a maintenance activity. In this case, the login will pass without raising any internal alert and the malicious operator Op-M will be logged in. At this point, however, it will start requesting resources as e.g. web ones or data: This solution will start analysing this kind or requests, verifying if they were scheduled and meant to be request by Operator Op-X remotely during a maintenance activity. It is highly probable that they are not, and so the malicious operator can be finally detected. In this case, the detection can happen either because the malicious Operator is requesting resources that are not used for maintenance activity or because due to the access role restriction is starting to get unauthorized exception responses.

(49) The following is a summary list of reference numerals and the corresponding structure used in the above description of the invention and a glossary:

(50) Login2A Detecting malicious operations by a machine-learning model

(51) 2B Detecting malicious operations by a rule-based algorithmLabelling an operation as malicious

(52) Forwarding to a IDS

(53) Cal Shift calendar, equipment calendar

(54) d Distance between two production lines of a site

(55) DoS Denial-of-service

(56) EvTr Event trace

(57) ICT Information and Communication Technology

(58) IDS Intrusion Detection System

(59) IIoT Industrial Internet of Things

(60) ISA-95 or ANSI/ISA-95 is an international standard from the International Society of Automation for developing an automated interface between enterprise and control systems, source:

(61) IT Information Technology

(62) LineA, LineB Production line

(63) Log log file containing login/logout history

(64) MES Manufacturing Execution System

(65) ML Machine Learning model

(66) MOM Manufacturing Operations Management

(67) Op, OP-Z Operator

(68) Op-LA, Op-LB Operator for production line A, line B

(69) Op-M Malicious operator

(70) OT Operational Technology

(71) SaaS Software as a service is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted; source:

(72) Site, SiteA, SiteB production site comprising at least one production line

LIST OF CITED DOCUMENTS

(73) [Doc 1]«A Comparison of Methods for Implementing Adaptive Security Policies»

(74) http://static.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/loe/loe.pdf retrieved on Apr. 25, 2018.

(75) [Doc 2]

(76) https://www.ge.com/digital/sites/default/files/Architecting-a-Robust-Manufacturing-Network.pdf

(77) [Doc 3]

(78) US 2014/0059578 A1—APPLICATIONS GENERATING STATISTICS FOR USER BEHAVIOR