At CALMS we take security of our customers and their data very seriously. We employ a proven combination of techniques to provide enterprise-level encryption. It consists of multiple lines of defense, preventing a potential attacker who has gained control of a part of our application from accessing the whole application.
Note that CALMS does not own any data stored by users in the CALMS Cloud and all data is owned by its users.
Edge device
Edge device to sensor communication
Edge device is IIOT device responsible for getting sensor values from
customers measurement sites, encrypting them and sending to CALMS
cloud.
Within the on-site local network, the device collects data from sensors
using encryption provided by sensor manufactures. In most cases, they do
not provide any encryption and but this does not present a significant
attack vector, because any attacker would need physical access to the
edge device and/or sensors to intercept this data.
Access to edge device
After we capture the data, it is stored at our edge device. Access to this device is limited to a physical password protected terminal and SSH remote connection over internal VPN using authentication certificates. These certificates are issued only to a few of our employees, who are responsible for device configuration, problem troubleshooting and regular software updates.
Edge device to CALMS cloud communication
When an edge device is connected to the internet (usually over GSM provider), it sends data to MQTT broker in our cloud using RSA 2048-bit encryption over MQTT protocol, all within the internal VPN. Device and MQTT broker authenticate each other using short-lived m-TLS certificates that are automatically regularly updated.
CALMS cloud
The CALMS Cloud is a complex network of servers, distributed worldwide. It is structured to provide the best performance, availability and security. It consists of numerous server and database types, of which the key types are discussed below in more detail.
Servers are hosted at several industry-leading hosting providers like Amazon AWS, Digital ocean and Google (for segmentation and stability reasons), with the highest security standards and ISO 27001 certifications.
Access to the cloud
Our cloud infrastructure uses multiple mechanisms and layers to provide maximum security and prevent an attacker from accessing or modifying the data. These mechanisms have been developed and tested by many other cloud service providers, such as Google and Amazon. Access to our cloud infrastructure is severly limited, controlled and monitored.
Microservice architecture
Our software is composed of multiple programs that can run independent of the others. This way we limit a potential attacker that has gained access to a part of the application only to that compromised part and not the whole application. For example, we isolate user data in a separate microservice, so it can be protected from a security incident in other parts of the application.
Isolation
All of our microservices (parts of our application) are orchestrated by Kubernetes, an advanced system for managing cloud infrastructure. Within Kubernetes, every part of the application is isolated and enclosed in a separate Docker container. To an attacker, it would seem like every program runs on a separate computer and cannot access other parts of our application. To access another microservice is almost as hard as compromising another computer. To further improve security, we made sure that those containers only have programs needed for their work. So if an attacker is able to gain access to one of the containers, this would be equivalent to gaining access to a computer without a display, keyboard, mouse or an operating system.
Kubernetes cluster
The CALMS Cloud platform contains multiple Kubernetes clusters for enabling and managing microservices. This modern architectural style ensures optimal scalability and availability of the CALMS Cloud platform. Microservices allow large applications to be structured as a collection of loosely coupled, smaller applications (services) that can be managed and updated individually, without downtime. Each microservice is built as a Docker container and Kubernetes is used for managing all these microservices.
Calms user application
Passwords and authentication
For user authentication we use OAuth2 architecture based on a user chosen password and cryptographically signed JWT token. Before being stored, passwords are hashed using BCrypt HMAC algorithm, so in extreme case where an attacker gains access to the database, they will not be able to get retrieve passwords users may use in other applications.
Encrypted connections
Encrypted connections are necessary to prevent attacks which can let attackers gain access to accounts and sensitive information. All connections to and from the CALMS Cloud and between Cloud services are therefore encrypted using HTTPS with TLS 1.2 or higher. MQTT connections are also TLS encrypted to ensure the confidentiality of your machine data. VPN connections use single-use VPN certificates and are encrypted using AES-256-CBC with SHA512. CALMS Cloud user passwords are stored as hashes using PBKDF2 with 12 bytes salt, 12000 iterations and SHA512 + HMAC. These strong algorithms help to establish a secure connection.
Permissions in CALMS
In the application, we have advanced permission system where each segment of the data is protected with a specific permission. Without granted correct permissions, user cannot load any data. We also log every important user actions so data do not get lost, deleted or modified without traces.
Preventing security leaks in software development
To ensure high quality and security of our product, we have multiple practices in place, designed to identify security vulnerabilities before they are exploited. We run automated unit and end-to-end tests of our application, we review a code of our developers alongside regular security reviews.
Backups
Backups are handled in multiple layers. All data that exists in the CALMS Cloud is backed up using automated systems. Every edge device has its own internal backup of a few gigabytes. The age of the oldest data in the device backup depends on number of channels and sampling interval.
Another backup layer we have is a backup of the whole application and history of all the channels and devices. Such backups are made every 12 hours and retained indefinitely. Together with edge device backups they can recover the whole system with no data loss in case of major data loss or other severe incident within our application.
CALMS’s senior developers can access these in a disaster recovery event.
API services
The application programming interface (API) services are the heart of the CALMS Cloud. They handle key processes in the CALMS Cloud, including authorizing and configuring VPN connections and connecting to our databases. The API services are not publicly accessible, but can be used by CALMS Cloud users after a unique API key is provided by CALMS. Users are then able to use the API services for creating custom applications or integrations with third parties.
MQTT broker services
CALMS Cloud uses the Message Queueing Telemetry Transport (MQTT) protocol for data transfer. The MQTT protocol is ideal for the Industrial IoT, because it is highly efficient, secure, has minimal overhead and greatly diminishes bandwidth use. CALMS MQTT broker services are used for pushing router configurations, firmware upgrades and for the transmission of Cloud Logging and Cloud Notify data. The MQTT broker services are physically located in AWS data centers.
