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 process 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 is 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 use 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/ |
| Hosted | Passwords | The containers within the Management System require passwords for mutual authentication. TTTech ensure 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 use 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 need to pulls 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:
|
| 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.
Secure installation
| Hardware | Product aspect | Description & measures |
|---|---|---|
| MFN200 | Pre-Installation | During production, TTTech configures the BIOS to use secure boot, and sets a unique password for the BIOS. The password is communicated to the user on a label. |
| Supported HW | SW installation | The user shall
|
| All | Physical installation | The user shall ensure
|
| 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.
|
| 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.
|
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:
|
| Permissions |
|
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.
|