Home > Edge > Manufacturing Edge > Guides > Dell Validated Design for Manufacturing Edge - Design Guide with 5 Independent Software Vendors > Cybersecurity for Litmus
The following settings have been validated on Litmus Edge version 3.2 unless specifically stated otherwise.
Confirm that CA signed certificates can be used by Litmus Edge during operations. This adds a layer of trust for when communicating with Litmus Edge (for example, when accessing the HTTPS interface). The end user can be assured that the certificate was signed by a trusted party.
Validate LE can connect to MQTT brokers using TLS to secure the connection in addition to using username and password to authenticate the connection.
Validate LE can connect to an OPC UA server and ingest data over a secured connection using encryption and authentication. This is recommended instead of using unsecure communications as that can compromise the confidentiality and integrity of the data. A custom CA signed certificate is used on Litmus to validate that users can load their own certificates instead of using default self-signed certificate.
Validate that Litmus Edge can integrate with an Active Directory server over LDAP using TLS (also known as LDAPS). This enables central management of users and protects the confidentiality of the authentication data when using LDAPS instead of regular LDAP. This test is done using a manual entry method. Using templates or loading features were not validated for this test.
Additional information:
Confirm that Litmus Edge can configure robust password settings for locally created user accounts. Defining stronger password settings helps to reduce the risk of compromised accounts.
Confirm that LE can define groups with specified permissions. Validate that the configured permissions are working correctly. Note that this test does not validate every set of permission settings but rather tests the overall functionality. LE comes with three predefined roles: administrator, developer, and observer.
Validate the capability of LE to audit/log actions taken on the system such as successful or failed login attempts or system configuration changes. This is critical in keeping users accountable for their actions and for any potential investigations into suspicious activity.
Validate the capability for LE to integrate with a central logging server. Specifically, Splunk will be used with the HTTP Event Collector (HEC) over an TLS-enabled connection using Litmus Edge's (LE) Splunk Integration. LE system events can also be sent over Syslog using UDP port 514. Splunk's HEC is the recommended method since the data is encrypted over the network.
Part of an effective audit/logging system is to have time synchronized across devices on the network. This helps when correlating events across a range of device logs. Validate that Litmus Edge can successfully connect to an NTP server.
Validate a secure connection between Litmus Edge and Litmus Edge Manager using CA signed certificates, specifically on LEM. The secure connection is created using HTTPS. Other secure protocols such as WireGuard and MQTT over TLS are used for other functions such as data aggregation and remote UI access.
Validate that Litmus Edge nodes that are connected and managed by Litmus Edge Manager can securely send and aggregate data at LEM. Specifically, this test case validates that a MQTT over TLS connection can be used to transfer LE simulator data to LEM. Per the prerequisite, this requires that the testing LE instance has already been added to LEM which automates the creation of a MQTT over TLS integration on LE.
The following settings have been validated on LEM version 2.3.
Validate that Litmus Edge Manager can integrate with an Active Directory server over LDAP using TLS. This enables central management of users and protects the confidentiality of the authentication data when using LDAPS instead of regular LDAP.
sudo keytool -import -alias <alias> -cacerts
-storepass <truststore-password> -noprompt
-trustcacerts -file </path/filename.crt>
Validate LEM's capability to use two-factor authentication. This enhances access control where users have to use something they know and something they have in order to authenticate into LEM.
Confirm that LEM can define groups with specified permissions. Validate that the configured permissions are working correctly. Specifically for this test case, Teams for specific Companies will be created and tested with read/write permissions.
Validate the capability of LEM to log system events for actions taken on the LEM web UI. Examples of events are creating activation codes, adding or removing LE devices, and more.
Part of an effective audit/logging system is to have time synchronized across devices on the network. This helps when correlating events across a range of device logs. Validate that Litmus Edge can successfully connect to an NTP server.
#timedatectl set-ntp true
NTP=<NTP server IP address/FQDN>
#sudo systemctl restart systemd-timesyncd.service
#systemctl status systemd-timesyncd.service
#timedatectl
The following Litmus Edge IDMZ architecture and security validation use cases have been tested on Litmus Edge version 3.2 and Litmus Edge Manager version 2.3.
LEM may be deployed outside the plan floor/control network for use cases such as aggregating LE data from different geographically located factories. These firewall rules validate secure LE to LEM connection through an IDMZ. In this scenario, an LE host is deployed in the IDMZ subnet as a proxy for plant floor LE hosts. The proxy LE aggregates data from the plant floor LE instances and then has a connection the LEM instance on the IT/Enterprise network. NATS is used as the protocol to transfer data between the OT and proxy LE instances.
Description | Source network | Source device | Destination network | Destination device | Port | Application |
Allow OT LE instance to send data to Proxy LE hosted on the IDMZ network using NATS. | OT | Plant Floor Litmus Edge (1) | IDMZ | Proxy Litmus Edge (2) | TCP 4222 | SSL, Unknown-TCP1 |
Allow Proxy LE to connect to LEM for sending data and for LEM remote control of LE host. | IDMZ | Proxy Litmus Edge (2) | IT | LEM (3) | TCP 443, TCP 8883, TCP 8445, UDP 51820 | SSL, Unknown-UDP2 |
SDP may be deployed on the IT network for data aggregation purposes. This use case provides validated guidance on how to securely transport LE data from the OT network to SDP hosted on the IT network. There are two LE instances in this use case, one that collects data on the OT network, and a proxy instance that aggregates LE data from the OT network and sends it to SDP. NATS is used as the protocol to transfer data between the OT and proxy LE instances.
For guidance on how to configure LE forwarding over NATS, reference Configure Litmus Edge to forward data to another Litmus Edge instance.
Description | Source network | Source device | Destination network | Destination device | Port | Application |
Allow OT LE instance to send data to Proxy LE hosted on the IDMZ network using NATS. | OT | Plant Floor Litmus Edge (1) | IDMZ | Proxy Litmus Edge (2) | TCP 4222 | SSL, Unknown-TCP1 |
Allow Proxy LE to connect to SDP MQTT broker using MQTT over TLS. | IDMZ | Proxy Litmus Edge (2) | IT | SDP (3) | TCP 8883 | SSL |