Security and data protection on aedifion.io
aedifion.io provides cloud-based data acquisition, analytics, and control. Inevitably, these services require a connection between your building automation network (.i.e, the customer's) and the aedifion.io platform, as well as storing and processing data on it.
Some of our customers have initially been concerned about connecting their building network to the Internet, even if only to our platform. Typical concerns are:
"The building automation network is not connected to the Internet for security reasons."
- Large german real estate operator
"80 % of our customers insist on a physical separation of building automation network and Internet for example via serial communication."
- Provider of cloud-based control algorithms
"We need more information to convince the building operator."
- Energy service company
Many of our existing customers' apprehensions were settled once they had understood exactly which connections are made, how they are established, and for what reasons. In this article, we thus explain and review the precautions and security measures aedifion takes to protect your building network and data.
The Edge Device¶
The aedifion Edge Device is a small industrial PC hardened against splash water, extreme temperatures, vibrations, shocks, etc. It can be mounted on standard DIN rails. The Edge Device has been designed, assembled, and approved according to German standards. We currently use the following hardware:
The Edge Device runs Ubuntu 18.04.1 LTS server and receives automatic security updates daily. Login to the device is only available through SSH and the root user's account is deactivated. Each Edge Device must pass an extensive series of functional and penetration tests before it is sent out for deployment.
On request, the Edge Device's software can run on your own hardware and operating system.
Connecting to the building network¶
The Edge Device has two built-in network adapters. The first network adapter must be directly connected to the local building automation network. This is important to support auto-discovery of devices and their datapoints as many building communication protocols such as BACnet use broadcasts in the local network for auto-discovery and these broadcasts are per standard not forwarded outside of the local network. The Edge Device will only communicate on the port(s) corresponding to the targeted building automation network protocol, e.g., port 47808 for BACnet.
The installation and connection of the Edge Device is done by the customer's local technician. In particular, aedifion will never require physical access to your networks.
If certain data points or entire areas of the building must not be read out, this can either be technically prevented in advance (e.g. by network masks or VLANs) or handled flexibly within the settings of the Edge Device. Together with you, we select data points which should be written or stored, and which should not be, since they can be classified as critical or privacy-sensitive.
Connecting to aedifion.io¶
The second network adapter of the Edge Device must be connected to a network with Internet access. Through this network interface, the Edge Device establishes a connection to the servers that host the aedifion.io platform. This connection is required, e.g., for data acquisition and remote administration. All communication between the Edge Device and aedifion.io is secured via TLS or SSH.
In most deployment scenarios, local networks with Internet access are placed behind a firewall that limits outgoing connections. In this firewall, the following ports need to be opened:
- 22/TCP Secure Shell (SSH)
Used only on-demand to establish a secure connection from the Edge Device to one of two dedicated servers for remote administration, e.g., to carry out software updates without manual interaction on location. SSH is the de-facto standard protocol for remote administration in cloud environments and used in millions of IT systems world wide.
- 123/TCP - Network Time Protocol (NTP)
NTP is a standard protocol for system time synchronization and establishes an outgoing connection to a pool of time servers. On request, the Edge Device can use customer-provided time servers, e.g., on the local network, for time synchronization. In this case, port 123/TCP may remain closed in the customer's firewall. By default, the aedifion Edge Device uses Ubuntu's standard time servers.
- 443/TCP Hypertext Transfer Protocol Secure (HTTPS)
- The Edge Device sends periodic heartbeats to two dedicated servers. Based on this feedback, aedifion monitors the accessibility, status, and functionality of its fleet of Edge Devices. All communication is carried over HTTPS (HTTP over TLS) which is the standard for secure communication on the Internet, e.g., used to secure online banking, mail accounts, and so forth. It is well understood by firewalls, intrusion detection, and deep packet inspection systems.
- The Edge Device contacts the Ubuntu package repository to check for security updates every night. Available updates are automatically installed. All communication with the Ubuntu package repository is carried securely over HTTPS.
- 8884/TCP Message Queuing Telemetry Transport Secure (MQTTS)
MQTT is an increasingly popular standardized protocol for Internet of Things and is used by aedifion to stream measurement data collected from the building network to aedifion.io's message broker in near real time. All MQTT messages are transported exclusively over TLS. As an alternative to MQTTS, measurement data can be collected and uploaded in batches through HTTPS. This option, however, sacrifices the near real-time availability of the collected data.
For deployments with critical security requirements, e.g., hospitals or banks, the listed requirements can be reduced down to opening only port 443/TCP for HTTPS traffic and additional security measures such as VPN tunnels can be employed. However, using only the Port 443/TCP is inevitably leading to limitations in platform functionality, such as live data integration.
Communication through the listed ports above has to be opened only for a fixed set of aedifion's servers, i.e., all other destinations besides the following can be blocked by the firewall.
|Port/Protocol||Main servers||Backup servers|
|22/TCP - SSH||ssh2.aedifion.io |
|123/TCP - NTP||0.ubuntu.pool.ntp.org |
|443/TCP - HTTPS||discovery2.aedifion.io |
|8884/TCP - MQTTS||mqtt2.aedifion.io |
All communication is established unidirectionally, i.e., from the Edge Device to the aedifion.io platform, and can be cleared or blocked accordingly in your firewalls. No external access to your network ever takes place. Your networks can remain completely closed and thus protected against external access by your existing firewalls. Thus there is no direct connection of the building automation network and hardware to the Internet.
The aedifion.io platform¶
The aedifion.io platform and all services built on top are hosted on dedicated and virtual servers by the Hetzner Online GmbH, based in Gunzenhausen, Germany. Hetzner is certified according to DIN ISO/IEC 27001 for its IT security standards and has won numerous awards. Hetzner operates data centers in Germany and Finland. aedifion.io is hosted on servers located in their data centers at Nürnberg and Falkenstein, Germany.
On demand, aedifion stores and processes your data on dedicated servers thereby excluding residual risks due to co-location of virtual machines.
All our servers and services are authenticated using standard X.509 certificates issued by Let's Encrypt that are renewed each quarter. As of January 2019, Let's Encrypt has a market share of more than 50%.
Figure 1: Our certification chain
All servers have DoS protection and multi-redundant connectivity to guarantee high availability. aedifion guarantees 97% uptime for the aedifion.io platform.
Custom Service Level Agreements (SLAs) with higher uptime guarantees can be negotiated.
Storage and Processing¶
All storage and processing of data on aedifion.io is strictly encapsulated and separated - down to the system level. In practical terms, this means in the first instance that a dedicated database is operated for each customer - the customer data is therefore separated. In the second instance, this means that virtual users in the backend, such as micro services, but also real users, only receive those rights (privileges) by default that they need for their intended purpose. For example, a data-evaluating, i.e. reading, service may not write data points by default. In the third instance, all processes at system level are separated from each other using Docker containers and only interconnected in dedicated virtual networks if necessary. For example, the analysis of one customer's data is strictly separated from the analysis of another customer's data.
User authentication and authorization¶
By default, user authentication takes place via username and password. Other identity providers, e.g., LDAP and Active Directory, can be integrated through OpenID connect, OAuth, and SAML. Thus, company-wide single sign-ons and integration of existing user databases are possible.
After a user is authenticated, all his/her accesses to the aedifion.io cloud platform are authorized through a comprehensive role-based access control (RBAC) system. Predefined, standardized roles are available but you can also freely define new roles with individual authorizations in a fine granular manner through the APIs.
Access can be controlled down to the granularity of allowing read or write access on single datapoints. E.g., you can grant users rights to modify the temperature in their office but nowhere else.
Our promise of security¶
We are convinced that digitization, and, in particular, the use of cloud and IoT technology, are key to enable and implement resource-conserving, energy-efficient, and user-expanding solutions. In this process, security and data protection are not nice-to-have, but a non-negotiable requirement that must be addressed and built into the design of IT systems right from the start.
That is why aedifion commits to permanently guarantee highest security and data protection standards. If at any time there is any uncertainty about the function of our services, the guarantee of security and data protection, you are welcome to contact us with your questions at any time.
Moreover, we walk the talk: aedifion is currently in the process of obtaining TÜV certification for the aedifion.io platform.