Many companies want to migrate their IT infrastructure to cloud platforms. However, in some cases security issues hampers such a process of migration. This is particularly true for the Critical Infrastructure (CI) domain, which represents a fundamental branch of societies. CIs enclose assets essential for the functioning of all countries' fundamental facilities such as energy, telecommunications, water supply, transport, finance, and health. Unlike other sectors, cloud technologies are still far from being widely adopted in CIs. CIs are increasingly target of terrorist cyber-attacks as demonstrated in last years (e.g. "Black Energy 3" in 2015, or "Havex" in 2014). The disclosure or manipulation of CIs sensitive data may have a devastating impact on the society at large. Hence, in order to migrate CIs to the cloud, new advanced hardening mechanisms are certainly needed.
In the context of SERECA project, we demonstrate how Intel SGX jointly with Vert.x can provide unprecedented security for a CI use case: a Water Supply Network Monitoring application (namely RiskBuster). The WSNM administration (EIPLI) is in charge of the management of seven dams in southern Italy. They want to migrate the monitoring infrastructure to the cloud, but they need guarantees regarding data condentiality and, most important, data integrity.
In such a scenario, Vert.x and Intel SGX are a perfect and suitable combination. SERECA provide the platform able to leverage them. The WSNM is: 1) Easily deployable among the dierent dams and the cloud environment; 2) Highly scalable in front of sensors measurements peaks 3) Highly available in front of failures; 4) High performing in the process of sensors data collection, processing and provision.
From a security point of view, instead, RiskBuster leverage the security features of Intel SGX, through a number of SERECA components. That is:
- SERECA Vert.X ApplicationFramework - RiskBuster is composed of 5 microservices developed with the Eclipse Vert.x toolkit and the SERECA application framework. These communicate through an Event Bus. In order to harden the communication of Vert.x microservices we included in RiskBuster the Secure Event Bus developed in the context of SERECA by Red Hat (as described in deliverable D2.1-D2.2) and made available using the SERECA Application Framework.
- SGX-JNI bridge - developed by TU Braunschweig, born to address a significant issue. That is, integrating the trusted execution of SGX into the microservice application to improve the security of data processing. It was non-trivial to support SGX-based trusted execution within Eclipse Vert.x since this necessarily needs a Java Virtual Machine (JVM) to execute. A solution for integrating C/C++-based TEEs into the JVM- based environment was mandatory to execute SGX-enabled application on top of Vert.x. In this context, the SGX-JNI bridge was considered the best solution and it was integrated in RiskBuster to especially protect the processing performed by the Alarm-Manager microservice. The idea is that the Java application runs outside the enclave, but use a JNI bridge to interact with the C code from within the enclave. The communication channel is secured and give access to the security features of the enclave.
- Secure Containers (SCONE) - RiskBuster needs two databases (MongoDB and MySQL) in order to meet EIPLI requirements, i.e., storing historical and time- recent data for complex event processing. The consortium has been able to provide a secured version (SGX-enabled) of both storage systems, which leverages the Secure Containers (SCONE) developed by TU Dresden. These have been included in the pilot as explained in D4.3.
- SecureKeeper - The application runs on top of the secured version (SGX-enabled) ZooKeeper, namely SecureKeeper, developed by TU Braunschweig. The goal is to ensure security of data exchanged by the coordination system.
- SGX-LKL - Finally, RiskBuster leverages the security provided by the SGX-LKL component that allows to run simple Java code within SGX in a transparent manner.
Starting from the left of the figure reported above, the Data Collector (DC) verticle sends sensors measurements from the dam to the MaaS cloud through a VPN TLS-secured communication. Data arrives to the cloud where a gateway verticle is in charge of receiving it and then publish on the Vert.x Event Bus. Such a verticle decides – based on a protected configuration file – if data might be published on the secure event bus, and so directed to secured verticles, or on the non-secured event bus. The other running secure micro-services (or verticles) are subscribed to the secure bus and periodically receive measurements messages. According to the secure event bus design, payloads of messages are encrypted before being sent through route-based keys pre-configured before.
The Alarm Management System (AMS) is a verticle which receives on-field data, enforces a Complex Event Processing (CEP) to detect possible alarm conditions, and sends alarm notifications to the web proxy verticle. Such a micro-service, therefore, is highly critical for the WSNM security. Attackers could hacked the measurements or the alarm notifications in order to hide a particular situation occurring on the dam. For this reason, we classified the AM as a Secure Verticle, which from now on securely processes data into a SGX enclave and transmits sealed-encrypted alarms through the secure event bus. Data is received from the gateway, through the secure bus, directly into the enclave using the JNI bridge. Vice versa, if an alarm is detected, the secure AM verticle sends to the Web Proxy a point-to-point message generated within the enclave and sent to the Vert.x secure bus through the JNI-bridge.
Two additional verticles are implemented to manage the storage services. The archiver verticles are in charge of all the storage activities management. On the basis of EIPLI requirements, we need to provide in RiskBuster two secure storage systems for historical and time-recent data, i.e., MySQL and MongoDB, respectively. Since the security of data-at-rest is of paramount importance, we decided to develop these micro-services as secure verticles. Like before, data is therefore received from the gateway, through secure bus and JNI bridge, into an enclave, and then is sent to the storage systems. Currently, we are still using the non- secured versions. We are near to include the SCONE secure containers that will contain the SGX-enabled storage services. Sensors measurements and historical alarms will be always kept sealed and encrypted into both storages.
Moreover, an additional verticle is needed to interface the application back-end and front-end, i.e., the web-based dashboard. Such a micro-service is responsible for providing real-time data, alarms notification, and data stored to the graphical interface. At the same time it forwards user requests to the appropriate verticle that will carry out the needed service. As attackers may sniff or alter the data travelling to the web browser, the web proxy micro-service has been equipped with a Secure SockJS bridge that encrypts data using a key shared with the browser.