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.
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
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.
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.
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.
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.
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.
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 are handled in multiple layers. 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 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.