Traditional BMS/SCADA systems versus the Cloud and Proptech solutions
BMS and SCADA systems are traditional IT solutions used in real estate to support technical systems.
BMS and SCADAs are still working in the local network, even though many industries have moved their traditional services to the cloud.
Examples are fintech, insurtech, medtech etc.
Now is time for PropTech, or Property + Technology. Proptech is an attempt to solve traditional challenges that occur in the real estate industry by using modern information technologies.
For the maintenance of technical systems in a building, the biggest challenge so far has been the secure transfer of data and device automation to the cloud.
The most common objections regarding Cloud BMS - Data security
One of the common concerns of Property Managers or Maintenance Teams is off-premises data security.
The fact that the traditional solution - a computer with an operating system and BMS / SCADA software which is physically located within the property creates a false sense of security.
- Why is this only an apparent sense of security?
Are local systems secure or is it just an assumption?
We recommend the presentation by Michał Kurek from the OWASP organization which you can find below.
Security vulnerabilities in the Local BMS
Local systems are only as secure as the people responsible for their operation.
We have identified several very important gaps, which are presented in the diagram below:
The devices are operated by a local BMS via hardware drivers that require programming to support specific functionalities. Programming controllers are usually carried out by a specialized technical service (expensive visit to the facility), and the software (so-called firmware) is uploaded from a USB memory dongle.
This is a serious threat, as the lack of proper procedures for maintaining and securing data on these media and the fact that such updates are performed on many devices (including other clients) and this creates the potential for damage propagation.
The fact that the devices are directly connected to the BMS system in the local network means that a potential BMS ATTACK can have dangerous effects on the entire hardware infrastructure. Devices usually do not have any additional layer of security.
The lack of authorization tokens means that anyone who obtains the system password can make changes to it!
If local systems are also vulnerable, and a security breach can have far more widespread effects than a cloud attack, the question arises:
- How to secure technical systems in the building while using the power inherent in their data and functionality?
The diagrams below show the solutions used in ConnectorIO Cloud BMS.
6 layers of Cloud BMS security
At ConnectorIO Cloud, we use several modern security levels:
- Digital Twins which are a virtual copy of the physical devices and at the same time a layer of security (firewall between the physical and virtual components).
- Authorization tokens for devices.
- Authorization tokens for users.
- I/O Protection (input and output ports) in the hardware gates and the Central Unit.
- In addition ... the security known from traditional systems, such as VPN encryption,
- ... and traditional access passwords.
The diagram below presents the security philosophy used in ConnectorIO.
What is a Digital Twin and what's its role?
A Digital Twin is a virtual representation of a physical device within the ConnectorIO Cloud system.
Digital twins can reflect the full functionality of physical counterparts or limited (which is decided at the stage of authorization and configuration of the system).
The cloud system "sees" only the digital equivalents of devices and communicates with them. The devices that are behind the digital twins are always secure from a communication point of view.
Communication with BMS Cloud in ConnectorIO
Choosing the ConnectorIO Cloud BMS solution enables you to benefit from the advantages offered by cloud computing solutions:
- Automatic updates - the system available in the cloud is always up to date.
- Uniform version of the system on all devices, in all real estate.
- Simple scaling in case of increased demand and system load.
(scaling means the ability to smoothly increase computing power and data space for servers stored in the cloud).
- High reliability and availability of systems in the cloud.
- Low maintenance cost - the cost of having to pay the costs of visits by technical teams at the facility, which translates into higher reactivity and availability of such a service that can be fully implemented remotely.
Data communication to the cloud service
MQTT is an extremely simple and lightweight data transmission protocol.
The Central Unit of the ConnectorIO system is only used to support local data transmission in the absence of cloud access and data buffering. If the cloud service is available, the data is sent directly from the gateways to the cloud.
If the connection to the cloud is suspended, the Central Unit is able to handle the automation rules of the devices, which it stores in its software based on the Linux operating system with a specialized security set.
This is done through communication with digital-twin devices via MQTT.
The process of installing and integrating devices in ConnectorIO
In the case of ConnectorIO, the most important element of the installation process is device authorization in the system, during which a token and a digital twin are generated.
What is a token and why you need one?
The token is a unique "ticket" that is allocated in the system at the time of authorization.
There are two groups of tokens:
- device token,
- token for users.
Communication within the system is possible only with an id, password and token (3 levels).
Of these three elements, only the password can change, the token remains the same (it is unique).
Revocation of a token means that a given user or device loses access to the system - "disappears" from the database of authorized objects.
Who can revoke a token?
- Only the SuperAdmin, i.e. a person with the highest possible authorization who is responsible for proper operation, maintenance and supervision of the cloud system can cancel the token.
The Cloud-based ConnectorIO system has four additional layers of security that traditional SCADA or BMS systems do not have.
- The biggest risk factor for traditional systems is easy access to the system through passwords, which rarely change and often lack proper storage procedures in organizations.
- The second risk factor is the scale of the threat, which represents a direct attack on BMS that can be performed via the computer's extension ports. Admittedly, these devices are located in premises where access is limited, but the scale of damage in the event of an attack is much larger than in the case of an attack via the cloud.
- User and device authorization tokens eliminate the risk of unauthorized access to the system and enable central management of access to building services and systems.
- Digital Twins are not only a virtual representation of physical devices, but also a security layer because the cloud service has no access to the device.
Please share your comments with us
If you have questions or comments regarding the presented ideas, then please let us know by posting a comment below.
More on ConnectorIO