Security¶
Security and data protection on aedifion.io
Overview¶
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¶
Operating System and Software¶
The aedifion Edge Device runs Ubuntu 20.04 LTS Server and is hardened according to industry standards established by the dev-sec project. Before it is commissioned, each Edge Device must pass an extensive series of functional and penetration tests. During operation, each Edge Device is rigorously monitored on hardware, system and application level and receives automatic security updates daily..
On request, the Edge Device's software stack 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 as detailed in the admin guide.
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.
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¶
Hosting¶
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.
Server authentication¶
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
Service availability¶
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 DIN ISO 27001 certification.