Skip to content

Security hardening recommendations

The following section gives an overview of several product areas or aspects of the product where measures need to be taken by the implementers to ensure security of the setup. Since the Data Gateway application is required to run on the Nerve Edge hosting platform, the security hardening guidelines and the security recommendations checklist of Nerve must also be considered.

Creation, installation and deployment

Product aspect Description and measures
Skilled users for workload creation and deployment Creating the Nerve workload with wrong settings such as misplaced Docker volumes can introduce security vulnerabilities.
Implementers of security shall ensure that only personnel with sufficient security know-how create the Data Gateway workload. Implementers of security shall ensure that the guide in chapter Setup is followed when defining the Nerve workload.
DNA for deployment For secure operation of a system, being able to verify the versions of the different components is essential.
Implementers of security shall use the Nerve DNA feature for deployment management of the Data Gateway and other components.

Configuration

Product aspect Description and measures
Skilled users for workload configuration Configuring the application in the wrong way can introduce security vulnerabilities.
Implementers of security shall ensure that only personnel with sufficient security know-how configure the Data Gateway workload.
Log Level Logs are essential to operate and monitor an application and can improve security significantly by indicating security-related events and configurations. However, logs can also potentially leak sensitive information.
Implementers of security must use a log level of "INFO" or higher (WARNING, ERROR, CRITICAL). The log level DEBUG must not be used by implementers of security as this could potentially leak sensitive information.
Sensitive information Sensitive information is necessary for proper configuration of the Data Gateway (credentials for connections, passphrases for keys, etc.).
Implementers of security shall ensure, through proper role and permission assignment, that only the intended personnel has access to the configuration files.
Secure connections Secure connection options are available for all connections.
Implementers of security shall ensure that authentication and encryption (equivalent to mutual TLS 1.2 or higher) is used for all connections between the Data Gateway and other components. For MQTT connections, tlsInsecure shall be disabled in production, and TLS 1.3 should be preferred where available.
Digital signing of configuration The Data Gateway offers the possibility to verify the authenticity and the integrity of the configuration files via a digital signature.
Implementers of security shall digitally sign the configuration files and enable the authenticity and integrity check via the Data Gateway's workload configuration.
Certificates and keys The use of certificates and cryptographic keys is essential for certain security features. Minimum requirements are necessary to ensure a state-of-the-art security standard.
Implementers of security must only use keys with a minimum length of 4096 bits.
Rate limitation Flooding of incoming messages can potentially limit the functionality of the application by producing a very high load, which can reduce the resources available for intended operation.
Implementers of security shall activate the rate limit for MQTT inputs to avoid flooding.
MQTT topic scope and retained messages Over-broad topic subscriptions and unmanaged retained messages can increase attack surface and propagate stale or malicious data.
Implementers of security shall minimize topic wildcards (especially #), define topic scopes per use case, and review retained-message behavior on all externally sourced topics.

Operation

Product aspect Description and measures
Monitoring The application provides logs that can be used to detect malfunction or attacks.
Implementers of security shall have a process to monitor the relevant logs to potentially detect malfunction and attacks.

Removal

Product aspect Description and measures
Removal Information may be leaked after decommissioning the system. For example, a decommissioned device might be used for another purpose or sold and may provide the opportunity to analyze the system and leak data.
Implementers of security shall ensure that the workload and Docker volumes are removed on decommissioned systems.