Logging events and logging analysis are essential. The analysis traces user actions for maintenance and abnormal events that can indicate a potential attack.

The complete system needs to have a robust logging system distributed in all devices. The events related to cyber security are logged locally and sent to a remote server using Syslog protocol.

In the system architecture, event logging involves two parties:

  • A log server that receives all the cyber security events of the system through Syslog protocol.

  • Log clients (Ethernet connection points where cyber security events are monitored: device, Control Expert).

Event Log Service Description

Each log client role is to:

  • Detect and time-stamp events.

    A single NTP reference needs to be configured in the system to time-stamp the cyber security events.

  • Send the detected events to the event logging server.

    The events are exchanged between the client and the server using Syslog protocol (RFC 5424 specification).

    The Syslog messages respect the format described in RFC 5424 specification.

    Syslog exchanges are done with TCP protocol.

    On devices, events are not lost in case of transient network breakdown. Events are lost in case of device reset (except for M580 CPU firmware ≥ 4.0).

Facility Values for Event Types

Syslog message facility values as per RFC 5424 specification associated with event types:

Facility value

Description

0

Kernel messages.

1

User-level messages.

2

Mail system.

3

System daemons.

4

Security / authorization messages.

5

Messages generated internally by Syslog.

6

Line printer subsystem.

7

Network news subsystems.

8

UUCP subsystem

9

Clock daemon.

10

Security / authorization messages.

11

FTP daemon.

12

NTP subsystem.

13

Log audit.

14

Log alert.

15

Clock daemon.

16...23

Local use 0...7.

Severity Values for Event Types

Syslog message severity values as per RFC 5424 specification associated with event types:

Severity Value

Keyword

Description

0

Emergency

System is unusable.

1

Alert

Action must be taken immediately.

2

Critical

Critical conditions.

3

Error

Error conditions.

4

Warning

Warning conditions.

5

Notice

Normal but significant condition.

6

Informational

Informal messages.

7

Debug

Debug-level messages.

Architecture Example

The following figure highlights the position of logging server in a system architecture:

Syslog messages.

Logged Event Message Structure for M580 CPU (Firmware Versions 4.0 and later), BMECRA31310, and BMENOR2200H (Firmware Versions 3.01 and later)

Fields

Description

PRI

Facility and severity information: "FACILITY" = 10 for cybersecurity events

VERSION

Version of the Syslog protocol specification (Version = 1 for RFC 5424.).

TIMESTAMP

Time stamp format is issued from RFC 3339 that recommends the following ISO8601 Internet date and time format: YYY-MM-DDThh:mm:ss.nnnZ

NOTE: -, T, :, . , Z are mandatory characters and they are part or the time stamp field. T and Z need to be written in uppercase. Z specifies that the time is UTC.

Time field content description:

  • YYY: Year

  • MM: Month

  • DD: Day

  • hh: Hour

  • mm: Minute

  • ss: Second

  • nnn: Fraction of second in millisecond (0 if not available)

HOSTNAME

Identifies the machine that originally sent the Syslog message: fully qualified domain name (FQDN) or source static IP address if FQDN is not supported.

Source @IP address =  @IP address A OR @IP address B in case of HSBY CPU

APP-NAME

Identifies the application that initiates the Syslog message. It contains information that identifies the entity sending the message (for example, subset of commercial reference).

PROCID

Process or protocol name that originated the message (e.g., Modbus, HTTPS, LocalHMI, ….)

MSGID

An identifier of the type of the event. (eg: CONNECTION_FAILURE_AND_BLOCK).

Event information

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

See STRUCTURED-DATA description below.

MSG

Message containing the event-specific result (see Event Logging Message Descriptions)

.

  • STRUCTURED-DATA: mandatory event information.

    • [ meta ]: mandatory structured-data to provide meta-information about the message. Where parameter is:

      • sequenceId: the event identifier (rollover to 1 when maximum value 2147483647 is reached).

      • sysUpTime: this value should be included when component is incapable of obtaining system time (integer containing the time in 1/100th of the second since the system was last re-initialized).

    • STRUCTURED-DATA: event information depending on event category.

      • [ authn@3833 ]: structured-data used for authentication events. Where parameters are:

        • itf: the interface where the user is connected to, either a network port or a local interface (hmi, usb , …).

        • peer: the FQDN or IP address of the component from which the user is connected, plus it’s port (ipAddress:port), optional in case of local interface

        • user: the user name (component or human), optional if user name unknown.

      • [ authz@3833 ]: structured-data used for authorization events. Where parameters are:

        • user: the user name (component or human)

        • object: the object access by the user, object is product dependant.

        • action: the action performed on the object: Create, Read, Update, Delete (CRUD)

      • [ config@3833 ]: structured-data used for configuration events. Where parameters are:

        • object: the name of the security object to configure (Firmware, RBAC, Security Policy, Device Setting, Trust Anchor, product dependant objects)

        • value: optional version or value of the new object

      • [ cred@3833 ]: structured-data used for credential management events. Where parameters are:

        • name: the common name of the certificate or the user login name

      • [ system@3833 ] structured-data for system events. Where parameters are:

        • object: the name of the system object that change (PLC, module, Rotary Switch, SD Card, product dependant object)

      • [ backup@3833 ]: structured data used for backup. Where parameters are:

        • object: the part of the component that has been backup/restore, object is product dependant.

      • Structured data can also be defined by each application for specific events.

Logged Event Message Structure for M580 CPU (Firmware earlier than Version 4.0), BMENUA0100 (Firmware Versions 1.10 & 2.0), and BMENOR2200H (Firmware earlier than Version 3.01)

Syslog message structure for M580 CPU firmware and the BMENUA0100:

Field

Description

PRI

Facility and severity information (description provided in following tables).

VERSION

Version of the Syslog protocol specification (Version = 1 for RFC 5424.).

TIMESTAMP

Time stamp format is issued from RFC 3339 that recommends the following ISO8601 Internet date and time format: YYY-MM-DDThh:mm:ss.nnnZ

NOTE: -, T, :, . , Z are mandatory characters and they are part or the time stamp field. T and Z need to be written in uppercase. Z specifies that the time is UTC.

Time field content description:

  • YYY: Year

  • MM: Month

  • DD: Day

  • hh: Hour

  • mm: Minute

  • ss: Second

  • nnn: Fraction of second in millisecond (0 if not available)

HOSTNAME

Identifies the machine that originally sent the Syslog message: fully qualified domain name (FQDN) or source static IP address if FQDN is not supported.

APP-NAME

Identifies the application that initiates the Syslog message. It contains information that identifies the entity sending the message (for example, subset of commercial reference).

PROCID

Process or protocol name that originated the message (e.g., Modbus, HTTPS, LocalHMI, ….)

Receives NILVALUE if not used.

MSGID

Identifies the type of message on which the event is related to, for example HTTP, FTP, Modbus.

Not used (NILVALUE).

MESSAGE TEXT

This field contains several information:

  • Issuer address: IP address of the entity that generates the log.

  • Peer ID: Peer ID if a peer is involved in the operation (for example, user name for a logging operation). Receives null if not used.

  • Peer address: Peer IP address if a peer is involved in the operation. Not used (null).

  • Type: Unique number to identify a message (description provided in following tables).

  • Comment: String that describes the message (description provided in following tables).

Setting Up a Syslog Server in the System Architecture

A wide variety of Syslog servers are available for various operating systems.

NOTE: Syslog servers need to be compliant with RFC 5424.

Examples of Syslog server providers:

Setting Up Syslog Clients in the System Architecture

Event logging is managed in Control Expert for all devices, DTMs, and Control Expert.

The event logging function, server address, and port number are configured in Control Expert as follows, and these parameters are sent to each client in the system after the Build action:

Step

Action

1

Click Tools > Project Settings.

2

Click Project Settings > General > PLC diagnostics .

3

Select Event Logging check box (deselected by default).

NOTE: A project with this setting checked can only be opened in Unity Pro (Control Expert) 10.0 or later.

4

Enter a valid SYSLOG server address and SYSLOG server port number.

5

Perform a Build after configuring this setting (you are not required to select Analyze Project ).

Diagnose Event Logging

The following table displays the type of event logging diagnostic available for various devices:

Devices

Diagnostic information

Control Expert

If a communication error with the Syslog server occurs, the detected error is recorded in the event viewer. To enable the event viewer in Control Expert, select Audit check box in the Policies tab of the Security Editor.

BMENOC0301/11 device DDT (SERVICE_STATUS2 parameter)

Two diagnostic information is available:

  • EVENT_LOG_STATUS: Value = 1 if event log service is operational or disabled.

    Value = 0 if event log service is not operational.

  • LOG_SERVER_NOT_REACHABLE: Value = 1 if the Syslog client does not receive the acknowledge of the TCP messages from the Syslog server.

    Value = 0 if the acknowledge is received.

Modicon M580 CPU device DDT

BMECXM Device DDT