Industrial Edge Management Security¶
The table below covers the features being provided by Industrial Edge Management v1 which is considered as deprecated. The newer versions of IEM are provided as SaaS solution by Siemens or as a helm chart which can be deployed on the customer's Kubernetes-based infrastructure which includes also OpenShift.
General mission of the Industrial Edge Management¶
The Industrial Edge Management is the component which is used to manage the connected Industrial Edge Devices. When setting up an Industrial Edge Device, it must be registered with a corresponding Industrial Edge Management; this Industrial Edge Management can be operated by Siemens as a SaaS solution or by the customer. The onboarding is done by creating a one-time token inside the Industrial Edge Management; the token is valid for 2h. After registering the connected Industrial Edge Devices, locally created (e.g. corporate-wide available) or publicly shared (via IEHub/Industrial Mall) Industrial Edge Apps can be installed on the Industrial Edge Devices. Additionally, an Industrial Edge-specific user management via Keycloak is provided. This user management enables the Industrial Edge Operator to delegate the user management to external authorization systems. Furthermore, different user permissions can be assigned to specific Industrial Edge Management users.
The connections from/to the Industrial Edge Management are encrypted. The web interface of an Industrial Edge Management system is also providing a REST API which is used for instance by the Industrial Edge App Publisher or the connected Industrial Edge Devices.
The integrity and authenticity of an Industrial Edge management is validated using the local truststore of the connected Industrial Edge Devices.
The Industrial Edge Management also represents the policy enforcement point by evaluating a ruleset. This ruleset is used to ensure that only certain trustworthy Industrial Edge apps (depending on the issuer of the certificate) can break the container isolation by using elevated privileges. Additionally, this policy is checking if the target Industrial Edge Device provides specific features required by an Industrial Edge App.
Industrial Edge Management v1 security¶
| Component | Purpose | Description |
|---|---|---|
| IMA | Linux Integrity Measurement Architecture | Industrial Edge implements the Linux Integrity Measurement Architecture (IMA) to guarantee the integrity of the loaded modules.* |
| Measured boot | Measure trusted boot and update channels | The measured boot checks the integrity of the whole boot chain and compares it with the trusted initial deployment. The fingerprints are stored in crypto hardware.* |
| Full disk encryption | Encrypted rootfs and data partitions | All system partitions are encrypted and locked by crypto hardware.* |
| Volumes and backup encryption | Keep the files secure | Volumes and backups need to encrypted |
| Policy engine | Supervise app policies | During an app installation, the policy engine checks the app (IEA) against a list of rules and informs the operator of any special permissions required by the app. The operator can then accept or decline the installation. The rules being handed over to the policy engine enforces privilege management for IEAs and ensures that only apps being highly trusted can break the isolation boundaries of a container and have privileged access to ressources of the underlying IED. The policy engine represents a policy enforcement point for the apps being installed on the target devices. |
| No root user login | Allow only user access | The Industrial Edge Management Operating System (IEM OS) does not provide any possibility to login as root user. In case the helm deployment method is used, root access must be restricted by the responsible operator of the underlying Kubernetes infrastructure. |
| Access credentials | Default password assignments | There are no default passwords assigned in the Industrial Management Web Interface during the installation process. When setting up an IEM, new access credentials must be assigned individually. Locally created passwords must be changed after the first login by the user and comply with defined complexity rules including lengh requirements and special characters as being specified by the Keycloak default policy. |
| 3rd party identity providers | Central user management | 3rd party user management systems like Entra ID and (corporate) OAuth-based identity providers can be connected to the IEMs. They can also be used to implement a 2-factor authentication for authorizing the IEM sessions. |
| System update | Keep the system updated and secure | A system update functionality is provided by the Industrial Edge Management. Security patches and system updates are published in the IE Hub shortly after vulnerabilities are known and issues are fixed. |
| Network communication to other Industrial Edge related components | Encryption of traffic | All communication between the IEM and the connected IEDs, IEHs and IEAs are encrypted by using TLS-based encryption (TLS 1.3) via https. The IEM can be equipped with an own certificate and runs by default with a self-signed certificate. |
| IEM registry | Configuration for external access | All images being stored in the IEM registry for making the container images of the related IEAs are only exposed in readonly-mode. Changing the images in the registry is only possible via the IEM interface which validates and distributes Industrial Edge Apps to the connected IEDs. |
| IEA signature validation | Validation of officially released Industrial Edge Apps | Industrial Edge Apps must be signed before being officially released in the Marketplace. Such IEAs are validated on the IEM. In case an app is unsigned or the signature validation fails, the installation can be enforced by accepting a corresponding warning message being shown to the IEM user managing the corresponding IEDs. |
| *For deployments on hosting environments with Trusted Platform Module (TPM). Does not apply to Kubernetes-related Deployments (e.g. via helm chart) | ||
Industrial Edge Management v2 and above¶
The Industrial Edge Management v2 is operated inside a Kubernetes-based cluster running in its own namespace deployed by a helm chart.
| Component | Purpose | Description |
|---|---|---|
| Firewall Protection | Protect exposed Industrial Edge Management Components | The SaaS solution being operated by Siemens is protected by a perimeter firewall using a block-by-default policy for in- and outgoing requests. In case the IEM is operated by the customer, the customer should also set up a valid perimeter protection using a block-by-default policy. Ports to be opened can be taken from here. |
| IEM-Related Secrets | Secret protection | Secrets used for authenticating application-related components can be assigned using the Helm chart or created automatically during the installation process for each individual installation, with no default passwords being used. When assigning passwords during installation, users must not reuse the same passwords across multiple instances. In IEM Pro and Virtual, secrets are securely stored in either the Kubernetes (K8s) secret store or an internal IEM database. IEM uses symmetric encryption algorithms, such as AES256-GCM or AES256-CBC. It is crucial for K8s administrators to ensure that the K8s secret store is protected against unauthorized access. User passwords are stored in the internal database as hashed values that cannot be reverted to plaintext. The hashing algorithm for these passwords can be configured in the Keycloak Admin UI, offering flexibility to meet specific security requirements. Secrets configured on IEM but used on IED are encrypted either with the device specific public key by using RSA Algorithm (legacy mode), or are encryted with a device specific shared secret (DH Key Exchange). |
| Assigned privileges and resource limits | Limitation of potential impact of vulnerabilities and dDOS attacks | Each container-instance used for providing the IEM functionality has defined CPU and memory limits and does not require any elevated privileges or mounting host paths on the underlying device. |
| Kubernetes nodes | Hardening of components | When using IEM as a SaaS service being provided by Siemens, the Kubernetes nodes are running in the cloud (AWS Frankfurt) and are protected by a firewall. In case of running the infrastructure on customers' premises, the Kubernetes nodes should be hardened and up-to-date according to hardening best-practices, e.g., specified in the CIS Kubernetes and Linux benchmarks. |
| Kubernetes control plane | Implementation of access restrictions | When using the SaaS service provided by Siemens, the orchestration endpoint is not exposed to the internet and protected by a network perimeter. Customer-related installations must not expose orchestration endpoints to the internet as well and apply suitable access restrictions according to the need-to-know principle. |
| Vulnerability management | Mitigation of vulnerabilities on IEM application components and execution environment | The components operated in the SaaS flavor are constantly monitored for vulnerabilities. In case critical vulnerabilities are detected, they are fixed in a timely manner. Fixed versions will also be provided for the Helm chart for customer installations in the Industrial Edge Hub. Industrial Edge Hub users will also be informed additionally via email. The customer is responsible for applying updates to the underlying Kubernetes-based infrastructure and rolling out updated helm charts. |
| Key material (certificates) | Generation of key material/Using own certificates | When installing the Industrial Edge Management on the customer infrastructure, own certificates can be installed or private certificate authority will be generated during the installation process. |
| Backup and disaster recovery | Creation of Backups | The Siemens-operated SaaS IAM solution is backed up on a daily basis for 7 days. For one month, weekly backups are created. In case of running your own cluster, backup and recovery can be performed on the Kubernetes cluster by using Velero as described here. |
| User management | Integration of central user management solutions for IAM | Within the IEM, a Keycloak instance is provided which can be used to integrate other corporate central user-management systems into the IEM. |
| IEM registry | Configuration for external access | All images being stored in the IEM registry for making the container images of the related IEAs are only exposed in readonly-mode. Changing the images in the registry is only possible via the IEM interface which validates and distributes Industrial Edge Apps to the connected IEDs. |
| Access credentials | Default password assignments | There are no default passwords assigned in the Industrial Management Web Interface during the installation process. When setting up an IEM, new access credentials must be assigned individually. Locally created passwords must be changed after the first login by the user and comply with defined complexity rules including length requirements and special characters as being specified by the Keycloak default policy. |
| Policy engine | Supervise app policies | During an app installation, the policy engine checks the app (IEA) against a list of rules and informs the operator of any special permissions required by the app. The operator can then accept or decline the installation. The rules being handed over to the policy engine enforce privilege management for IEAs and ensures that only highly trusted apps can break the isolation boundaries of a container and have privileged access to resources of the underlying IED. The policy engine represents a policy enforcement point for the apps being installed on the target devices. |
| Container settings and Kubernetes requirements | Privileges of containers | Beside short living Init-Containers, none of the running containers has root-privileges. CPU and memory restrictions are applied to all containers being provided by the helm chart. Kubernetes users having the right to deploy the helm chart must have the right to set up cronjobs for enabling secret rotation. |
| Logging | Provide valid information for auditing | User-related authentication logs are provided by Keycloak running in the Kubernetes namespace, additional authorization information is generated as additional logs for the container instances provided by the IEM. When running Kubernetes on the customer's infrastructure, the operator of the platform must decide how to persist and analyze the logs (e.g. by using a SIEM system) |
| K8s Ingress Controller or Loadbalancer | Expose IEM to external networks | To expose your service to the external network in a Kubernetes setup, you can use either an Ingress controller or a Load Balancer. The setup must support HTTP/1.1, WebSockets, and large payloads (over 1GB) for app and firmware management. |
For security related topics refer to Security consideration for K8s installation.
NOTICE
Refer to Certificate Management for more information about that topic.