Security hardening guidelines

Nerve is a third-party platform for which software can be developed. It provides several features and measures that need to be used to ensure security. The following section gives an overview of several product areas or aspects of the product where measures need to be taken by implementers. Note that the measures listed can have major implications for software development processes and functions to ensure the entire system operates according to the security standard.

For ease of use, a summary of all measures can be found in the Security recommendation checklist.

Management System guidelines

To install and operate a Management System in a secure manner, multiple requirements must be fulfilled. When the Management System is hosted, TTTech implements policies and processes guaranteeing the security of the Management System operations. When the Management System is self-managed, the customer, further referenced as hosting manager in the document, shall define and implement the necessary policies and processes to ensure secure operations. The next sections provide information on the policies implemented by TTTech and guidelines for the hosting manager in case of self-managed systems.

Installation and update

Hosting	Category	Description & measures
Hosted	Authenticity	To ensure the integrity and authenticity of the software, the hash of the images are checked per script and the signature is checked by the notation tool before starting the images. This applies to the installation and all updates.
Self-Managed	Authenticity	Please contact TTTech to received the necessary information and scripts to perform an authenticity check on installation or update.
Hosted	Network	TTTech limits the network traffic to and from the Management system based on actual needs
Self-Managed	Network	The hosting manager shall limit the network traffic according to the table below. Additional restrictions and exceptions may be applied depending on the exact hosting context
Hosted	Data at rest	TTTech uses the platform disk encryption from Azure to protect the data at rest
Self-Managed	Data at rest	The hosting manager shall ensure that the Docker volumes (mounted on /data//) are encrypted at rest
Hosted	Passwords	The containers within the Management System require passwords for mutual authentication. TTTech ensures that the passwords are unique for each Management System, have sufficient entropy and are rotated on each update
Self-Managed	Passwords	The hosting manager shall ensure that a proper password policy is in place to create strong passwords and rotate them periodically. Please contact TTTech support for the exact list of passwords
Hosted	Synchronization	TTTech configures the hosting virtual machine to use a high precision time source.
Self-Managed	Synchronization	The hosting manager shall ensure that the hosting virtual machine uses a high precision time source (NTP, PTP...).
Hosted	Access	Access to hosting VM is granted only to a limited number of trained employees.
Self-Managed	Access	The hosting manager shall implement a process to ensure that only trained employees access the hosting VM.
Hosted	Update	When an update is available, TTTech support contacts the customer to define a maintenance window to perform the update of the Management System.
Self-Managed	Update	When an update is available, TTTech support informs the customer, and provide the information needed for the hosting manager to perform the update.

The following external connection shall be allowed.

Direction	Host / URL	Port	Justification
Incoming	Any user	80, 443	HTTP / HTTPS access to the Management System. Port 80 may be blocked if redirection is not needed and the certificates are not delivered by Let'Encrypt using a HTTP challenge.
Outgoing	https://software-center.nerve.cloud/	443	Needed to download updates for the nodes
Outgoing	Docker registries	80 / 443	Needed if the Management System needs to pull Docker images from an external Docker registry
Outgoing	mail server	587	Needed to send emails for user creation and credential reset

Additional exceptions are probably needed for:

OS maintenance
Monitoring of the Management System
EDR reporting

These rules are highly dependent on the hosting environment and are under the responsibility of the hosting manager.

Configuration

The Management System can be configured through a file. This configuration can only be changed by the hosting manager in case of self-managed system or by the TTTech support in the hosted case. Only the security relevant parameters are described here.

Category	Parameter	Default	Description
Brute force	max_attempts_by_ip_and_username	5	max number of failed attempts for the username + IP address
Brute force	max_attempts_by_ip_and_username_node_users	10	Max number of failed attempts for the username + IP address(case when a user logins on the node)
Brute force	max_attempts_by_ip_and_username_dashboard_users	10	Max number of failed attempts for the username + IP address(case when a user logins on the dashboard)
Brute force	max_attempts_by_ip_and_username_validate_token	10	Max number of failed attempts for the username + IP address(validate token)
Brute force	max_attempts_by_ip_and_username_verify_log_agent	10	Max number of failed attempts for the username + IP address(verify log agent)
Brute force	max_attempts_by_ip_and_username_ws_tunnel	10	Max number of failed attempts for the username + IP address(ws tunnel)
Brute force	max_attempts_by_ip_and_username_mfa_validation	10	Max number of failed attempts for the username + IP address(mfa validation)
Brute force	reset_attempts_interval_by_ip_and_username	1800 s	username + IP address can try max_attempts_* times to login within this interval
Brute force	block_duration_by_ip_and_username	1800 s	period that username and IP address combination is blocked
Brute force	max_attempts_by_ip	100	max number of failed attempts for the IP address
Brute force	reset_attempts_interval_by_ip	86400 s	an IP address can try max_attempts_* times to login within this interval<>
Brute force	block_duration_by_ip	86400 s	period that the IP address is blocked
Remote connection	session_duration	3600 s	How long the SESSION is valid after the Nerve Connection Manager loses the connection with the Management System
Audit logs	file_warm_state_retention_policy_audit_ms	180d	Retention of audit logs for the Management System in days
Audit logs	file_warm_state_retention_policy_security_auditlog	180d	Retention of audit logs for the nodes in days
Audit logs	file_warm_state_retention_policy_audit_docker_log	180d	Retention of audit logs from the workloads in days
MFA	mfa_enabled	false	Enable multifactor authentication for the Management System

Maintenance and Monitoring

The Management System is composed of several Docker containers running in a virtual machine. To ensure reliable and secure operations, several precautions must be implemented.

Hosting	Category	Description & measures
Hosted	OS update	TTTech patches the OS in the virtual machine on a daily basis. A maintenance window is required every second week to reboot the virtual machine and ensure that all patches are applied
Self-Managed	OS Update	The hosting manager shall ensure a regular patching of the OS of the virtual machine running the Management System.
Hosted	Resources	TTTech enforces a limit on RAM and CPU consumption of each container from the Management System.
Self-Managed	Resources	The hosting manager shall enforce resources limits for each container, adapted to the hosting environment.
Hosted	Monitoring	TTTech monitors several parameters (e.g. RAM and CPU consumption, disk usage) to ensure the proper function of the Management System. If one of the parameters reaches a certain threshold, the TTTech support team is alerting allowing for a timely response to the event.
Self-Managed	Monitoring	The hosting manager shall implement and operate a monitoring and alerting system to ensure reliable and secure operation of the Management System. Please contact the TTTech support team for a recommendation on the parameters to monitor.
Hosted	Certificate	TTTech uses LetsEncrypt to generate a certificate for protecting the HTTPS communication. The certificate is rotated with a period shorter than 90 days. A self-signed certificate is used for JWT signing token. The certificate is rotated regularly, on the same basis as the passwords used for container authentication.
Self-Managed	Certificate	The hosting manager shall implement a policy and a process to generate certificates with sufficient strength, protect them on the hosting machines and ensure regular rotation.
Hosted	Malicious code	TTTech ensures the integrity and authenticity of the Management System during deployment. Additionally, CrowdStrike is used in the hosting VM to detect intrusion into the system and provide protection against malicious code.
Self-Managed	Malicious code	The hosting manager shall implement the same checks when deploying / updating a Management System and shall implement a protection against malicious software by using CrowdStrike or a similar tool.
Hosted	Backup	TTTech ensures a daily backup of each management system. 7 daily backups, last 4 weekly backups, last 12 monthly backups, 1 yearly backup for each year are retained.
Self-Managed	Backup	The hosting manager shall implement a regular backup system guaranteeing the integrity of the data.
Hosted	Restore	For disaster recovery or on customer request, TTTech can restore the last known good backup.
Self-Managed	Restore	The hosting manager shall implement and tests a process to restore the Management System date from a backup including an integrity check.

Note

The audit logs for the Management System and for the nodes, are stored on the same disk as other customer data and thus covered by the monitoring system. This provides a robust mechanism to protect audit log storage capacity issues.

Decommissioning

Hosting	Category	Description & measures
Hosted	Decommissioning	When a customer request the termination of a Management System, the TTTech support team: Perform a last backup Stops the VM Propose the data for download for 30 days After expiration of the waiting period, the VM is destroyed, all related disks are wiped and the backup are deleted.
Self-Managed	Decommissioning	The hosting manager shall define a process ensuring that the hosting VM, all related data disks and the backups are destroyed.

Node guidelines

The installation of a node requires a different process, depending on the hardware. In case of hardware delivered by TTTech (MFN 200), the BIOS is already configured to support secure boot and protected by a password, and the software is installed. In case of supported hardware purchased by the customer, part of the protection shall be implemented during installation.

Device preparation

TTTech delivered hardware

As part of the production and configuration process, TTTech ensures the following protections are in place:

Anti-tampering and tampering detection mechanism by using anti-tampering screws and labels allowing to detect if the device was open
TTTech MOK keys installed
Secure boot and disk encryption
Other boot options disabled
Unique password set for BIOS, default admin user, SSH access

Note

This is valid for MFN 200 and Fitlet3, installed with a version higher or equal to 3.0.0.

Other hardware

Before starting the procedure, a USB drive must be prepared following the instructions in the Device Guide

Connect the monitor and the keyboard to the device.

To ensure that the device is secure to operate, the following procedure must be followed:

Check if anti-tampering protection and detection measures are in place.
If not, install them (e.g., replace some screws and add labels).
Update the BIOS to the latest qualified version using the OEM instructions.
Insert the USB drive with the Nerve-installer and boot the device.
Confirm the installation by selecting OK.
When the installer requests a password for MOK key, enter a string of your choice and confirm by pressing Enter.
This is a one time password only needed during next reboot.
Acknowledge the Secure Boot screen by selecting OK.
When the status Installation successful is displayed on the screen, follow the instructions and remove the USB drive.
Press Enter

During the next reboot, enter the BIOS settings by performing the following steps:

Navigate to the Security tab.
Activate Secure boot.
If needed, select Secure Boot Mode Custom.
Set the administrator password.
Adhere to internal policies regarding password strength. Store the password securely.
Navigate to the Boot tab.
Change the Boot option 1 to Nerve_<boot_entry>.
Disable all other boot options.
Save the BIOS setting and exit the BIOS by selecting Save and Exit and pressing Enter.
During the next reboot, the status Perform MOK management is displayed on the screen.
Select Enroll MOK and press Enter. Be sure not to miss any timeouts of the boot screen, as you might be required to restart the process.
Select Continue and press Enter.
When the request Enroll the key(s) is displayed on the screen select YES and press Enter.
Enter the previously selected MOK key password and press Enter.
Select Reboot and press Enter.

The node boots now as a Nerve device.

Secure installation

Hardware	Product aspect	Description & measures
All	Physical installation	The user shall ensure physical protection against physical access to the device. that physical access to the network cables is limited in order to protect the network within the machine. that only trained personal is granted physical access to the node
All	Network	The node should be installed in a network protected by a firewall and against low level network attacks (ARP attacks, DNS spoofing...). No incoming connection is needed. Once licensed, the node only needs an outgoing access to the URL of the Management System over HTTPS(port 443)

Note

Secure boot is only supported on device installed with version 3.0 and higher.

Node operations

Product aspect	Description & measures
Update	TTTech provides regular update for the Nerve node. The user shall ensure that the updates are applied in a timely manner.
User management	Nerve's local user interface is designed to be used by service engineers with sufficient expertise and security knowledge. After onboarding, the user management is delegated to the Management System. In the Management System roles for the node can be assigned to the users. Implementers of security shall ensure that only those people with sufficient need and security know-how shall be able to obtain the local node credentials for installation. Implementers of security shall ensure that at least one user with node admin permissions logs in on the node to disable the default account. Implementers of security shall ensure the accounts and permissions for accessing the node are included in the periodic review of permissions in the Management System.
Backup and recovery	The Nerve node provides several mechanism for backup and recovery. For Virtual Machines see VM-Backup, VM-Restore. For Docker volumes see Volumes Local UI and Volumes MS. Codesys does not store data locally. The archives are protected by a SHA-256 for VM and by a CRC32 (zip file) for the Docker volumes. Docker images and Codesys workloads should be redeployed from the Management System. Implementers of security shall define and implement a backup and restore strategy based on the mechanism listed here. Implementers of security shall protect the backup files against unauthorized access.

Secure disposal guidelines

Product aspect	Description & measures
Secure disposal	Information may leak after decommissioning the system. For example, decommissioned hardware may be sold and may provide the opportunity to analyze the system and leak data. The user shall ensure that a process exists to securely delete or destroy all data on decommissioned systems. It is recommended to offboard the node before decommissioning.

Note

On Nerve version 3.0 and higher, if secure boot is activated, disk encryption is active. In such cases, the offboarding of the node destroys the encryption key, ensuring that all user data are not retrievable any more.

General guidelines

Account management guidelines

Product aspect

Description & measures

User Management

Implementers of security shall follow best practices for account management:

delete user account in a timely manner, when a user does not need it anymore
review the role assignment periodically to ensure that only the minimum permissions are granted.

Permissions

Implementers of security shall periodically review the permissions assigned to each role and remove unnecessary permissions.
Implementers of security shall assign the right to create, configure or modify workloads only to users with sufficient need and expertise.
Implementers of security shall assign the right to create, configure or modify remote connections only to users with sufficient need and expertise.
Implementers of security shall review the permissions to access nodes. *

Note

The Nerve Management system defines a default admin role for which the permissions cannot be managed. Only a very limited number of properly trained users should be assigned this role.

Secure operation guidelines

Product aspect

Description & measures

Creating a process to act on security information provided by the Nerve team

The Nerve team provides security information to the contact address given to the Nerve team when licenses were purchased.

Implementers of security shall ensure that there is a process to read and act upon the security information provided by the Nerve team through the given contact address.
Implementers of security should create, deploy and sell their systems based on Nerve in a way that frequent security updates are acceptable.
Implementers of security shall create a process to verify that the version and configurations of Nerve software correspond to the desired state.
Implementers of security shall create a process to periodically review audit logs of the Management System and of the Nodes for unexpected or unauthorized access.