La consignation des événements et l’analyse des journaux sont essentielles. L'analyse permet de tracer les actions de l'utilisateur en cas de maintenance ou d'événements anormaux susceptibles de révéler une attaque potentielle.

Le système doit être équipé d'un robuste système de consignation englobant tous les équipements. Les événements liés à la cybersécurité sont consignés en local et envoyés à un serveur distant à l'aide du protocole Syslog.

Dans l'architecture du système, la consignation des événements met en œuvre deux parties :

  • un serveur de consignation qui reçoit tous les événements de cybersécurité du système à l'aide du protocole Syslog ;

  • des clients de consignation (points de connexion Ethernet où les événements de cybersécurité sont surveillés : équipement, Control Expert).

Description du service de consignation des événements

Chaque client de consignation sert à :

  • détecter et horodater les événements.

    Une référence NTP doit être configurée dans le système pour horodater les événements de cybersécurité.

  • envoyer les événements détectés au serveur de consignation des événements.

    Les événements sont échangés entre le client et le serveur à l'aide du protocole Syslog (spécification RFC 5424).

    Les messages Syslog respectent le format décrit dans la spécification RFC 5424.

    Les échanges Syslog sont effectués avec le protocole TCP.

    Sur les équipements, les événements ne sont pas perdus en cas de défaillance temporaire du réseau. Les événements sont perdus en cas de réinitialisation de l'équipement (sauf pour le micrologiciel de CPU M580 ≥ 4.0).

Valeurs d'installation pour les types d'événement

Valeurs des fonctions des messages Syslog, conformément à la spécification RFC 5424 associée aux types d'événement :

Valeur d’installation

Description

0

Messages du noyau.

1

Messages de niveau utilisateur.

2

Système de messagerie.

3

Démons du système.

4

Messages de sécurité/d'autorisation.

5

Messages générés en interne par Syslog.

6

Sous-système d'impression en ligne.

7

Sous-systèmes d'actualité du réseau.

8

Sous-système UUCP.

9

Démon d'horloge.

10

Messages de sécurité/d'autorisation.

11

Démon FTP.

12

Sous-système NTP.

13

Historique de consignation.

14

Alerte de consignation.

15

Démon d'horloge.

16 à 23

Utilisation locale 0 à 7.

Valeurs de gravité pour les types d'événement

Valeurs de gravité des messages Syslog, conformément à la spécification RFC 5424 associée aux types d'événement :

Valeur de gravité

Mot-clé

Description

0

Emergency

Système inutilisable

1

Alert

Action immédiate requise

2

Critical

Conditions critiques

3

Error

Conditions d'erreur

4

Warning

Conditions d'avertissement

5

Notice

Condition normale mais importante

6

Informational

Messages d'information

7

Debug

Messages de mise au point

Exemple d'architecture

La figure suivante montre la position du serveur de consignation dans l'architecture d'un système :

Messages Syslog.

Structure des messages d'événement consignés pour la CPU M580 (versions de micrologiciel 4.0 et ultérieures), BMECRA31310 et BMENOR2200H (versions de micrologiciel 3.01 et ultérieures)

Champs

Description

PRI

Informations sur l'installation et la gravité : "FACILITY" = 10 pour les événements de cybersécurité

VERSION

Version de la spécification du protocole Syslog (Version = 1 pour RFC 5424).

TIMESTAMP

Le format d'horodatage est défini par la RFC 3339 qui recommande le format de date et d'heure Internet ISO8601 suivant : YYY-MM-DDThh:mm:ss.nnnZ

NOTE : -, T, :, . et Z sont des caractères obligatoires et font partie du champ TIMESTAMP. T et Z doivent figurer en majuscules. Z spécifie que l'heure est au format UTC.

Description du contenu du champ d'horodatage :

  • AAAA : Année

  • MM : Mois

  • DD : Jour

  • hh : Heure

  • mm : Minute

  • ss : Seconde

  • nnn : Fraction de seconde en milliseconde (0 si non disponible)

HOSTNAME

Identifie la machine ayant envoyé le message Syslog : nom de domaine complet (FQDN) ou adresse IP statique source, si FQDN n'est pas pris en charge.

Adresse @IP source =  Adresse @IP A OU Adresse @IP B dans le cas d'une CPU HSBY

APP-NAME

Identifie l'application qui crée le message Syslog. Il contient des informations qui identifient l'entité qui envoie le message (par exemple, sous-ensemble de référence commerciale).

PROCID

Nom du processus ou du protocole à l'origine du message (par exemple, Modbus, HTTPS, LocalHMI...).

MSGID

Identifiant du type de l'événement. (ex : CONNECTION_FAILURE_AND_BLOCK).

Informations sur l'événement

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:diagram-version="1" ac:macro-id="30296255-e8b7-4cf1-982e-2c45b17b1f06"><ac:plain-text-body><![CDATA[[ authn@3833], [ authz@3833], ]config@3833,, , [,     ][ backup@3833 ]

Voir la description de STRUCTURED-DATA ci-dessous.

MSG

Message contenant le résultat spécifique de l'événement (voir la section Description des messages de consignation des événements)

.

  • STRUCTURED-DATA : informations obligatoires sur l'événement.

    • [ meta ] : données structurées obligatoires pour fournir des méta-informations sur le message. Où le paramètre est :

      • sequenceId : identifiant de l'événement (passage à 1 lorsque la valeur maximale 2147483647 est atteinte).

      • sysUpTime : cette valeur doit être incluse lorsque le composant n'est pas en mesure d'obtenir l'heure du système (entier contenant l'heure en 1/100 de seconde depuis la dernière initialisation du système).

    • STRUCTURED-DATA : informations sur l'événement en fonction de la catégorie d'événements.

      • [ authn@3833 ] : données structurées utilisées pour les événements d'authentification. Où les paramètres sont :

        • itf : interface à laquelle l'utilisateur est connecté, soit un port réseau, soit une interface locale (IHM, USB, etc.).

        • peer : nom de domaine complet (FDQN) adresse IP du composant à partir duquel l'utilisateur est connecté, plus son port (adresseip:port), facultatif en cas d'interface locale.

        • user : nom d'utilisateur (composant ou homme), facultatif si le nom d'utilisateur est inconnu.

      • [ authz@3833 ] : données structurées utilisées pour les événements d'autorisation. Où les paramètres sont :

        • user : nom d'utilisateur (composant ou homme).

        • object : accès à l'objet par l'utilisateur, objet dépendant du produit.

        • action : action effectuée sur l'objet :  Créer,  Lire,  Mettre à jour,  Supprimer (CRUD)

      • [ config@3833 ] : données structurées utilisées pour les événements de configuration. Où les paramètres sont :

        • object : nom de l'objet de sécurité à configurer (micrologiciel, RBAC, stratégie de sécurité, paramètres d'équipement, ancre d'approbation, objets dépendants du produit).

        • value : version ou valeur facultative du nouvel objet.

      • [ cred@3833 ] : données structurées utilisées pour les événements de gestion des informations d'identification. Où les paramètres sont :

        • name : nom commun du certificat ou identifiant de l'utilisateur.

      • [ system@3833 ] : données structurées pour les événements système. Où les paramètres sont :

        • object : nom de l'objet système qui change (automate, module, commutateur rotatif, carte SD, objet dépendant du produit).

      • [ backup@3833 ] : données structurées utilisées pour la sauvegarde. Où les paramètres sont :

        • object : partie du composant qui a été sauvegardée/restaurée, objet dépendant du produit.

      • Les données structurées peuvent également être définies par chaque application pour des événements spécifiques.

Structure des messages d'événement consignés pour la CPU M580 (micrologiciel antérieur à la version 4.0), BMENUA0100 (micrologiciel antérieur aux versions 1.10 et 2.0) et BMENOR2200H (micrologiciel antérieur à la version 3.01)

Syslog pour le micrologiciel de la CPU M580 et le BMENUA0100 :

Champ

Description

PRI

Informations sur la catégorie et la gravité (description fournie dans les tableaux suivants).

VERSION

Version de la spécification du protocole Syslog (Version = 1 pour RFC 5424).

TIMESTAMP

Le format d'horodatage est défini par la RFC 3339 qui recommande le format de date et d'heure Internet ISO8601 suivant : YYY-MM-DDThh:mm:ss.nnnZ

NOTE : -, T, :, . et Z sont des caractères obligatoires et font partie du champ TIMESTAMP. T et Z doivent figurer en majuscules. Z spécifie que l'heure est au format UTC.

Description du contenu du champ d'horodatage :

  • AAAA : Année

  • MM : Mois

  • DD : Jour

  • hh : Heure

  • mm : Minute

  • ss : Seconde

  • nnn : Fraction de seconde en milliseconde (0 si non disponible)

HOSTNAME

Identifie la machine ayant envoyé le message Syslog : nom de domaine complet (FQDN) ou adresse IP statique source, si FQDN n'est pas pris en charge.

APP-NAME

Identifie l'application qui crée le message Syslog. Il contient des informations qui identifient l'entité qui envoie le message (par exemple, sous-ensemble de référence commerciale).

PROCID

Nom du processus ou du protocole à l'origine du message (par exemple, Modbus, HTTPS, LocalHMI...).

Reçoit la valeur NILVALUE s'il n'est pas utilisé.

MSGID

Identifie le type de message auquel l'événement est lié, par exemple HTTP, FTP, Modbus.

Non utilisé (NILVALUE).

MESSAGE TEXT

Ce champ contient plusieurs informations :

  • Issuer address : Adresse IP de l'entité qui génère le journal.

  • Peer ID : ID d'homologue si un homologue est impliqué dans l'opération (par exemple, nom d'utilisateur pour une opération de consignation). Reçoit la valeur Null s'il n'est pas utilisé.

  • Peer address : Adresse IP de l'homologue si un homologue est impliqué dans l'opération. Non utilisé (null).

  • Type : Numéro unique identifiant un message (description fournie dans les tableaux suivants).

  • Comment : Chaîne décrivant le message (description fournie dans les tableaux suivants).

Configuration d'un serveur Syslog dans l'architecture du système

De nombreux serveurs Syslog sont disponibles pour différents systèmes d'exploitation.

NOTE : Les serveurs Syslog doivent être conformes à la spécification RFC 5424.

Exemples de fournisseur de services Syslog :

Configuration de clients Syslog dans l'architecture du système

La consignation des événements est gérée dans Control Expert pour tous les équipements, DTM et Control Expert.

La fonction de consignation des événements, l'adresse du serveur et le numéro de port sont configurés dans Control Expert comme ci-dessous, et ces paramètres sont envoyés à chaque client du système après l'action Générer :

Étape

Action

1

Cliquez sur Outils > Options du projet .

2

Cliquez sur Options du projet > Général > Diagnostics de l'automate.

3

Cochez la case Consignation des événements (décochée par défaut).

NOTE : un projet avec cette case cochée ne peut être ouvert que dans Unity Pro (Control Expert) 10.0 ou version ultérieure.

4

Renseignez les champs Adresse du serveur SYSLOG et Numéro du port du serveur SYSLOG .

5

Sélectionnez Générer après avoir configuré ce paramètre (sélection de la commande Analyser le projet non obligatoire).

Diagnostic de la consignation des événements

Le tableau suivant indique le type de diagnostic de consignation des événements, disponible pour différents équipements :

Equipements

Informations de diagnostic

Control Expert

Si une erreur de communication avec le serveur Syslog survient, elle est enregistrée dans le visualiseur d'événements. Pour activer le visualiseur d'événements dans Control Expert, cochez la case Audit dans l’onglet Règles de l’Editeur de sécurité.

DDT d'équipement BMENOC0301/11 (paramètre SERVICE_STATUS2)

Deux informations de diagnostic sont disponibles :

  • EVENT_LOG_STATUS : valeur = 1 si le service de consignation des événements est opérationnel ou désactivé.

    valeur = 0 si le service de consignation des événements n'est pas opérationnel.

  • LOG_SERVER_NOT_REACHABLE : valeur = 1 si le client Syslog ne reçoit pas l'acquittement des messages TCP de la part du serveur Syslog.

    valeur = 0 si l'acquittement est reçu.

DDT d'équipement de la CPU Modicon M580

DDT d'équipement BMECXM