EP3314498A1

EP3314498A1 - Security system for industrial control system

Info

Publication number: EP3314498A1
Application number: EP16730712.3A
Authority: EP
Inventors: Zakarya DRIAS
Original assignee: Schneider Electric Industries SAS
Current assignee: Schneider Electric Industries SAS
Priority date: 2015-06-26
Filing date: 2016-06-03
Publication date: 2018-05-02
Also published as: WO2016206947A1; FR3038097B1; CN107787576A; US20180137297A1; FR3038097A1

Abstract

Security system for an industrial control system that includes one or more hardware entities and/or one or more software entities that are accessible by at least one user through at least one security portal, the security system including: a security database (4); and a security server (3); and each hardware or software entity includes a software agent comprising: a module (500) for verifying each security token received from a security portal (10) or a hardware or software entity (6); a module (501) for analysing the access rights of the user (1), of another software entity (6) or of another hardware entity (5); and a module (502) for receiving security tokens, said module in particular being arranged to transfer a token to a second hardware or software entity that a security portal (10) or another entity would like to access.

Description

Security system for industrial control system

Technical field of the invention

The present invention relates to a security system for an industrial control system.

State of the art

An industrial control system (ICS) refers generally to a control system used in the industrial field and including SCADA-type supervision solutions, distributed control systems (DCS) ) or any other solution that includes one or more Programmable Logic Controllers (PLC). In particular, an industrial control system is designed to configure, supervise and manage critical infrastructures such as those related to an electricity generating station, a nuclear power plant, a water treatment plant, mining or quarrying solutions. gas, a pharmaceutical or chemical manufacturing process. The system thus comprises one or more hardware entities and / or software entities installed and accessible through one or more security portals. A hardware entity may be a programmable logic controller (PLC), a sensor, an actuator, etc. For example, a software entity is software implemented to configure, manage, control or supervise the system and one or more of its hardware entities. defined above.

Given the criticality of the infrastructures described above, IT security has become a major issue to protect the system from malicious intrusions.

Today, the security of each hardware entity or software entity of the system is managed independently so that a user must log in each time, providing identity data (eg login and password) and by justifying specific access rights, which he wishes to access to a hardware entity or a separate software entity from the industrial control system.

WO2006 / 059195A1 discloses a secure power management architecture comprising a plurality of intelligent electronic devices connected to each other. The object of the invention is to propose a security system for an industrial control system making it possible to prevent a user from logging in whenever he wishes to access a hardware entity and / or a software entity of the control system. industrial. The solution of the invention makes it possible to manage the identity data of each user or material entity of the system originating from action in the system, as well as the access control to the resources of the various entities of the system.

This goal is achieved by a security system for an industrial control system that comprises one or more hardware entities and / or one or more software entities accessible by at least one user through at least one security portal, the security system comprising :

a security database arranged to memorize:

- identity data associated with each user and material entity,

- access rights data to each hardware entity or software entity of the system,

security tokens generated for each user and each hardware entity, each security token comprising the data signed by a security server and relating to the identity of the user or of the material entity and the rights data; access granted to the user or the physical entity,

a security server comprising:

a verification module in the security database of the identity data of a user or of a material entity,

a module for generating security tokens for each user or hardware entity identified in the security database,

a module for managing the identity data of each user, a material entity stored in the security database,

a module for managing access rights data stored in the security database,

Each hardware entity or software entity comprises a software agent comprising:

a module for verifying each security token received from a security portal, a software entity or another hardware entity, a module for analyzing the access rights of the user, of another software entity or of another material entity,

a security token receiving module arranged to receive and memorize each received token and to sign the security token received from a security portal or a first hardware entity and to transfer this signed token to a second hardware entity or software to which the security portal or the first hardware entity wishes to access.

According to one particularity, each software agent comprises a cryptographic key management module arranged for the generation, exchange, storage, use and replacement of cryptographic keys necessary to sign a security token or to decrypt it.

According to another particularity, each software agent comprises one or more cryptographic libraries.

In another feature, the software agent of a hardware entity includes an authentication module arranged to send the identity of the hardware entity to the security server to receive a security token from him.

Brief description of the figures

Other features and advantages will appear in the following detailed description with reference to the accompanying drawings in which:

FIG. 1 schematically represents the architecture of the security system of the invention used to secure an industrial control system,

FIG. 2 illustrates the procedure for registering a user and adding a hardware entity to the security system of the invention, FIG. 3 illustrates the procedure for enrolling a hardware entity and authentication. of this entity,

FIG. 4 illustrates the procedure for authentication of a user and access to a software entity by a user,

FIG. 5 illustrates the procedure of access of a user to a hardware entity via a software entity,

FIG. 6 illustrates the procedure for accessing a physical entity to another physical entity, Figure 7 illustrates the procedure for updating a security token, Figures 8A and 8B show two separate architectures of a security token.

Detailed description of at least one embodiment

As described above, an industrial control system is for example intended to manage a critical infrastructure and comprises one or more hardware entities and / or one or more software entities. A hardware entity is for example a programmable logic controller, a sensor, an actuator, etc. For example, a software entity is intended to manage the configuration and / or operation of one or more hardware entities of the system.

Depending on the configuration of the system, several cases of interaction between user, hardware entity 5 and software entity 6 may occur:

the user 1 can be brought to connect to a hardware entity 5 or a software entity 5 of the system via a security gateway 10,

a hardware entity 5a or a software entity 6a may be made to connect to another hardware entity 5b or to another software entity 6b.

Each of these cases of operation will be described below, in connection with the security system of the invention.

The security system of the invention mainly comprises the following elements:

a security database 4,

a security server 3,

software agents 50, 60 each associated with a hardware entity 5 or with a separate software entity 6.

The security database 4 is intended to store different types of security data:

authentication data 40, authorization data 41,

data 42 related to the security policy implemented for the system.

In the authentication data 40, there are:

- for each user, an identifier, a password and a security token,

- for each hardware entity, an identifier, a certificate and a security token.

In the authorization data 41, we find:

for each hardware entity and software entity of the system, data related to their access rights to each hardware entity and to each software entity of the system,

In the data 42 related to the security policy, we find:

for each user 1 and hardware entity 5 of the system, a file in a suitable format, for example XACML (for Extensible Access Control Markup Language), to summarize the authorizations associated with each user 1 or hardware entity 5 of the system and a copy of the associated security token.

For each user 1 and hardware entity 5 of the system, the security token corresponds to the XACML file described above, timestamped and signed by the security server 3.

The security server 3 is intended in particular to manage the authentication of each user 1 and each hardware entity 5 of the system. It includes:

a module 30 for managing the authentication data of each user 1, stored in the security database 4, intended to check the authentication data of each user, a module 31 for managing the authentication data of each hardware entity 5 of the system, stored in the security database 4, intended to verify the certificate of each hardware entity,

a module 32 for managing data relating to the access rights of each user 1 and each hardware entity 5 of the system, stored in the security database 4,

a module 33 for managing the security tokens allocated to each user and each hardware entity of the system, in particular to carry out the signature and the time stamp at the generation of each security token, an administrator interface 34 enabling, in particular, an administrator, using an administrative software tool, registering new users and new hardware entities, entering access rights to the various hardware entities and software entities in the system, and configuring and assigning access to each user and each hardware entity.

Each hardware entity 5 comprises a software agent 50 whose responsibility is to manage all the security operations related to the physical entity with which it is associated. For a hardware entity 5, such software agent 50 comprises:

a module 500 for verifying each security token received from a security gateway 10, a software entity 6 or another hardware entity 5,

a module 501 for analyzing the access rights of the user 1, of a software entity 6 or of another hardware entity 5 after decryption and reading of a received security token,

a security token receiving module 502 arranged to receive and memorize each received token and to sign the security token received from a security gateway 10 or a first entity and to transfer this signed token to a second entity to which the security gateway 10 or the first entity wishes to access,

a cryptographic key management module 503 arranged for the generation, exchange, storage, use and replacement of cryptographic keys, one or more cryptographic libraries 504 such as, for example, OpenSSL,

an authentication module 505 arranged to send the identity (certificate) of the hardware entity to the security server 3 to receive from it a security token.

Each software entity 6 also comprises a software agent 60 whose responsibility is to manage all the security operations related to the software entity 6 with which it is associated. This agent comprises:

a module 600 for verifying each security token received from a security portal, a hardware entity or another software entity,

a module 601 for analyzing the access rights of the user, of a hardware entity or of another software entity after decryption and reading of a received security token,

a security token receiving module 602 arranged to receive, memorize each received token and to sign the security token received from a security gate or a first entity and to transfer this signed token to a second entity to which the security portal or the first entity wishes to access,

one or more cryptographic libraries 603 such as for example OpenSSL.

In each hardware or software entity 6 of the system, the access rights analysis module 501, 601 analyzes the architecture of the XACML file which includes a point of application of the decision (PEP for "Policy Enforcement Point"). and a Policy Decision Point (PDP).

Figures 8A and 8B show the architecture of a security token, respectively when it comes from the security server and when it is transmitted by a software agent. In FIG. 8A, the security token transmitted by the security server is a file that includes the following data:

datapoint data 80 specifying the creation date of the file,

the validity period 81 of the security token,

data 82 of identity of the user 1 or the hardware entity 5 associated with the security token,

data 83 identifying the organization that generated the file,

the data 84 related to the access rights of the user 1 or of the material entity 5 concerned,

This file is signed (signature 85) by the security server 3 with the aid of a private key in order to generate the security token.

In FIG. 8B, the security token transmitted by a software agent 50, 60 of a hardware entity 5 or of a software entity 6 consists of the security token described above which is additionally signed (signature 86). by the software agent 50, 60 in order to be authenticated by the receiver.

The security system may comprise a certification authority 7 intended in particular to provide the certificates for each hardware and software entity of the system. The certification authority interacts with the security server to provide, upon request from the security server, each certificate associated with a hardware and software entity of the system. The certificates are stored in a database managed by the CA. The certification authority 7 also has the means to generate new certificates and to check whether the certificates of each hardware and software entity are up to date.

To encrypt the data exchanged, the security system of the invention uses a conventional encryption system based on a public key mechanism and private key, for example TLS / SSL.

FIG. 2 illustrates the principle of registering a user 1 and a hardware entity 5 of a system by an administrator 2 connected to the security server through the administration software tool 20 executed on a computer station. For all administration task, the administrator 2 must first identify (A1) to the security server 3 via the administration software tool 20. For the addition of a user 1, the procedure follows the steps following:

A2: the administrator 2 sends to the security server 3 a request to add a user 1, along with the identification data of the user 1,

A3: the security server 3 issues a command to write the identification data relating to the user 1 in the security database 4,

A4: The security database 4 confirms to the security server 3 the addition of the user 1,

A5: The security server 3 confirms the addition of the user in the security database 4.

For the addition of a hardware entity 5, the procedure comprises the following steps:

B1: via the administration software tool 20, the administrator 2 sends to the security server 3 a request to add a hardware entity 5,

B2: the security server 3 sends a request to the certification authority 7 in order to obtain the certificate of the hardware entity 5 to be registered,

B3: Certificate Authority 7 returns the required certificate,

B4: the security server 3 sends a command to write identification data, including the obtained certificate, related to the hardware entity 5 in the security database 4,

B5: security database 4 confirms the registration of the physical entity,

B6: The security server confirms the addition of the hardware entity to the administrator.

FIG. 3 illustrates the procedure for enrolling a hardware entity 5 and its authentication: C1: via the administrator interface of the security server 3, the administrator 1 issues a "Discover" command of the security server in order to determine the hardware entities of the system,

C2: the security server 3 sends a request for a certificate request to the software agent 50 of a hardware entity 5 of the system,

C3: the authentication module 505 of the software agent 50 of the hardware entity 5 responds to the request by sending its certificate,

C4: the security server 3 verifies the certificate of the hardware entity 5, if the certificate is valid:

C5: the hardware entity 5 is authenticated,

if the certificate is not valid:

C6: the administrator 2 sends a request to add the hardware entity 5 to the security server 3,

C7: the security server 3 sends a request for enrollment to the authentication module of the software agent 50 of the hardware entity with the address of the certification authority 7 in order to obtain a certificate from the certification authority 7,

C8: the software agent 50 of the hardware entity 5 sends a request to the certification authority 7, for example in the form of a request based on the SCEP protocol ("Simple Certificate Enrollment Protocol"), to obtain a valid certificate,

C9: the certification authority 7 generates a certificate for the hardware entity 5 and responds to the request by sending the certificate to the software agent 50 of the hardware entity 5,

C10: the authentication module of the software agent 50 of the hardware entity 5 sends the certificate obtained to the security server 3,

C1 1: the security server 3 validates the authentication of the hardware entity 5 with the administrator 2.

C12: the administrator 2, from the administrative software tool 20, enters the configuration data of the hardware entity 5, including the data related to the access rights of this hardware entity, C13: the administrator 2 sends a request to save the configuration data of the hardware entity to the security server 3 for the creation of the XACML file for the hardware entity 5,

C14: the administrator then sends a request to the security server for the generation of the security token,

C15: the security server 3 generates the security token thanks to its management module,

C16: the security server 3 distributes the security token to the hardware entity,

C17: the receiving module of the hardware entity stores the received token.

Figure 4 illustrates the procedure of access of a user to a software entity. This procedure consists of the following steps:

D1: the user 1 launches a software entity 6 of the system,

D2: the software entity 6 requests its software agent 60 to authenticate this user 1 and to check its access rights,

D3: the software agent 60, through its verification module, checks the security token of the user 1,

- if the security token is valid:

D4: The software entity runs.

- if the security token is not valid:

D5: the software agent sends a request to the security portal to obtain the current security token associated with the user,

D6: If the security portal has a security token for this user:

D7: The security gateway sends the security token to the software agent of the software entity,

D8: the software entity agent verification module checks the received security token for authentication, D8: the software agent's software agent analysis module checks the user's access rights,

D9: if the user is authenticated and his access rights validated, the software entity executes,

the security portal does not hold a token:

D10: the security portal asks the user to enter his identity data (username, password),

D1 1: The user informs his identity data,

D12: the security portal issues a request to the security server to obtain a security token by issuing the user's identity data,

D13: The security server checks the identity data received from the security database:

D14: If the identity data is not entered in the security database:

D15: the security server sends a negative response to the security gateway,

D16: The authentication procedure failed.

D17: If the identity data is entered in the security database:

D18: the security server sends a request to the security database to obtain the data related to the access rights of the user, that is to say the XACML file associated with this user,

D19: Security database 4 returns data related to the user's access rights as the XACML file,

D20: Based on the received XACML file, the security server generates the security token,

D21: the security server sends the generated security token to the security gateway, D22: the security portal transfers the security token to the software agent of the software entity,

D23: the software entity agent verification module verifies the received security token for authentication of the user and verification of his access rights,

D24: if the user 1 is authenticated and his access rights validated, the software entity 6 executes.

FIG. 5 illustrates the procedure implemented for the access of a user to a hardware entity 5 through a software entity 6. The procedure comprises the following steps:

E1: the user 1 sends a request to the software entity 6 to perform an operation on a hardware entity 5,

E2: the software entity 6 requests the hardware entity 5 to establish a secure communication channel (for example under the TLS protocol for Transport Layer Security),

E3: the hardware entity 5 establishes a secure communication channel with the software entity 6,

E4: the software agent 60 of the software entity 6 signs the security token of the user 1 and sends it to the software agent 50 of the hardware entity 5,

E5: The hardware agent verification module 50 of the hardware entity 5 checks the received security token.

E6: If the security token is valid, the operation can be performed on the hardware entity 5.

- if the security token is invalid:

E7: the software agent of the hardware entity sends a response to the hardware agent's hardware agent to indicate that it is invalid,

E8: the software agent of the software entity requests an update of the security token to the security portal of the user, E9: the security portal asks the user to enter his identity data (username, password),

E10: the user informs his identity data,

E1 1: the security gate sends a request to the security server for obtaining a security token, along with the identity data of the user,

E12: after reading the security database 4, the security server 3 sends the generated security token to the security portal,

E13: the security gate transfers the security token to the software agent of the software entity that transfers it to the hardware entity's software agent,

E14: Hardware entity's software agent verification module checks the received security token for authentication, the hardware agent's software agent's scanning module checks the user's access rights ,

E6: If the new security token is valid, the operation can be performed on the hardware entity.

Figure 6 illustrates the procedure implemented to allow a first hardware entity 5a to access a second hardware entity 5b. It comprises the following steps:

F1: the first hardware entity 5a requests the second hardware entity 5b to establish a secure communication channel (for example under the Transport Layer Security TLS protocol),

F2: the second hardware entity 5b establishes a secure communication channel with the first hardware entity 5a,

F3: the software agent of the second hardware entity 5b sends a request to the software agent of the first hardware entity 5a to obtain its security token, F4: the software agent of the first hardware entity 5a sends its security token to the software agent of the second hardware entity 5b,

F5: the software agent verification module of the second hardware entity 5b checks the received security token,

- if the security token is valid:

F6: the software agent of the second hardware entity analyzes the access rights of the first hardware entity,

F7: if its access rights are validated, the first hardware entity 5a can issue commands to the second hardware entity 5b,

F8: the second hardware entity 5a authorizes the access of the first hardware entity 5a according to its access rights,

F9: If the security token is invalid:

F10: the software agent of the second hardware entity requests a new security token from the first hardware entity,

F1 1: the software agent of the first hardware entity sends a request to the security server to obtain an update of its security token,

F12: the security server generates a new security token from the XACML file, the security server time stamping and signing said file,

F13: the security server sends the new security token to the software agent of the first hardware entity 5a,

F14: the software agent of the first hardware entity transfers the security token to the software agent of the second hardware entity,

F15: the software agent's verification module of the second hardware entity checks the new security token, F6: If the new security token is valid, the software agent of the second hardware entity analyzes the access rights of the first hardware entity,

Figure 7 illustrates the procedure for updating a security token belonging to a hardware entity. A software agent of a hardware or software entity that has received a valid security token can ask if the security token in its possession is up to date. The verification procedure that an up-to-date security token is performed on data representative of a compressed signature of the security token. Thus, only this data is sent by one entity to another. This procedure consists of the following steps:

G1: the agent of a first entity (hardware in FIG. 7) requests a verification of the received security token to the software agent of a second (software) entity present in the chain,

- G2: if the software agent of the second entity concludes with a difference, it returns a response to the agent of the first entity,

G3: the software agent of the first entity requests the agent of the second entity the updated security token,

- G4: the software agent of the second entity sends a request to the security portal to find out if the security token is up to date,

- G5: after verification, if the security token is not up to date, the security portal sends a response to the software agent of the second entity indicating that the security token is not up to date,

- G6: the software agent of the second entity requests from the security portal the security token up to date,

- G7: the security gateway sends a request to the security server to know if the security token is up to date, G8: After verification, if the security token is not up to date, the security server sends a response to the security portal indicating that the security token is not up to date,

G9: the security portal asks the user to enter their identity data,

G10: the user enters his identity data,

G1 1: the security gateway sends a request to the security server to obtain a new security token,

G12: The security server responds to the security portal by sending a new security token to the security portal.

The solution of the invention thus has many advantages, among which:

Allow the management of the identity data of each user or material entity in the industrial control system, in a centralized way with a limited impact on the architectures of existing products,

Permit the management of the authorizations and access rights of each user or physical entity to each hardware or software entity of the system,

- Secure communication between the different entities of the system, by the direct exchange of security tokens between these entities, without going through a central server, using in particular asymmetric cryptographic techniques,

- Cover all levels of an industrial control system,

- Access multiple resources from a single sign-on.

Thus, thanks to the security system of the invention, a user authenticates one time with the security server, and then any authentication of the user by the different entities is to authenticate the security token that has been associated with it. Similarly, a user or a hardware entity with a security token has the ability to securely access one or more software hardware entities of the system directly or indirectly on multiple levels.

Claims

1. Security system for an industrial control system which comprises one or more hardware entities and / or one or more software entities accessible by at least one user through at least one security gate, characterized in that the security system comprises:

a security database (4) arranged to store:

identity data associated with each user (1) and hardware entity (5),

- access rights data to each hardware entity (5) or software entity (6) of the system,

security tokens generated for each user and each hardware entity, each security token comprising the data signed by a security server (3) and relating to the identity of the user or of the hardware entity and the data of access rights granted to the user or the physical entity,

a security server comprising:

a verification module in the security database (4) of the identity data of a user (1) or a hardware entity (5),

a module for generating security tokens for each user (1) or hardware entity (5) identified in the security database (4),

a module for managing the identity data of each user (1) and hardware entity (5) stored in the security database,

a module for managing access rights data stored in the security database (4),

Each hardware entity or software entity comprising a software agent comprising:

a module (500) for verifying each security token received from a security gateway (10), a software entity (6) or another hardware entity (5),

a module (501) for analyzing the access rights of the user (1), of another software entity (6) or of another hardware entity (5), a security token receiving module (502) arranged to receive and store each received token and to sign the security token received from a security gate (10) or a first hardware entity (5) and to transfer this signed token to a second hardware or software entity to which the security portal (10) or the first hardware entity (5) wishes to access.

2. System according to claim 1, characterized in that each software agent (50, 60) comprises a cryptographic key management module (503) arranged for the generation, exchange, storage, use and replacement of cryptographic keys needed to sign a security token or to decrypt it.

3. System according to claim 1 or 2, characterized in that each software agent (50, 60) comprises one or more cryptographic libraries (504).

4. System according to one of claims 1 to 3, characterized in that the software agent (50) of a hardware entity (5) comprises an authentication module (505) arranged to send the identity of the hardware entity to the security server (3) to receive from it a security token.