Does Your Monitoring System Protect Your Data? – The Definitive Guide
Updated: Feb 23
Physically restricting access to intruders in the real world is usually quite straight forward. A lock and key should do the trick! But how do you prevent hackers from accessing sensitive data that is stored on a server (The Cloud)? In this document I will go over some of the measures you must put in place to safeguard yourself when purchasing a Cloud based Monitoring System. I will outline the minimum-security expectations from a supplier and explain some of the data that should and shouldn’t be stored on a Monitoring System platform. I will also offer some little hacks (possibly a poor word choice) that will protect you in the event of unauthorised access.
Disclaimer: This guide does not outline every security measure available and provides no guarantees of security. This guide is designed to provide a brief understanding of the sort of things you should consider before purchasing a Monitoring system.
What are we Protecting?
Firstly, it is important to note that there is nothing that will provide a guarantee of no hackers being able to access your system. What you are looking for is something that poses the least risk, rather than no risk. If you are about to head into the market for a Monitoring System, or maybe you have already shortlisted? Then it is important to know what the minimum level of security would be to safeguard yourself and your facility. To understand what security is necessary we need to reverse engineer the process and look at how and why someone may want to hack your system.
You might be thinking “why would someone want to steal the data from my Sensors? What use would that be?” Well, you might be right! I would agree that the raw data from your sensors may be useless information. Instead, hackers would be seeing the Monitoring System as a Gateway, or a portal if you like, to access the Network that it is connected to. Once they are on the Network, they will be able to access all the sensitive information. I think it goes without saying the problems that this could cause.
Restricting access is quite obviously safer than having a free for all, but there does need to be some level of control. If you are in the market for a large system across multiple departments/buildings/sites, then it is likely that not all users will be responsible for all the sensors.
For example, users in Lab 101 will only have responsibility for the sensors in this Lab and won’t need to know the performance of the sensors in Lab 102, Lab 103, etc… Choosing a system that allows you to segregate a system in this way will not only reduce the chance of error due to unwanted configuration changes, but it will also make the system easier to use and manage for an end user.
Within an organisation there will be some members of staff that will have more responsibilities than others and that should be reflected in the access that is granted. When deciding on a system you should look at their permission levels, how you can segregate your users and if there are any costs associated. Some companies will charge per user account or license, so you need to look out for this. Permission levels is related to your ability to make changes to the configuration of the system. Some systems do not allow for end users to make any changes to the system. Changes must be requested from the manufacturer which can cause delays, increasing the chance of error and is time consuming. Ideally you would want to make all the changes via a software platform with the ability to restrict configuration changes where necessary. Much like the Access control, this leaves less margin for error and means that you have complete control over who can and can’t access your data and system configurations.
If you decide upon a wireless system, then you need to have a vague understanding of the signals being used and how secure they are. Wireless signals can be intercepted and therefore it is important to know what is being transmitted and if you are vulnerable to hackers.
There are potentially two areas that you need to be looking at. First is the wireless communication between the Sensors and the Receivers/Gateways. If you opt to have cellular communication to The Cloud software platform then this also needs to be considered. The question you need to be asking is if the signals are Encrypted? What this means is that data is converted into a code to prevent unauthorised access. With encrypted signals you have far less chance of an intruders gaining access to your data. Even in the event of signal being intercepted, the data could not be interpreted. This should be a standard on most wireless signals, but it is always best practice to check and never assume.
Having your data protected while everything is live and running is one thing, but making sure that you have the measures in place to access and protect your data in the event of an issue with the system provider is another. If the provider folds, if there is a major failure, if the provider changes… If any of these things happened would your data be safe, would you own your data, and would your system still be operational? These are questions that would need to be answered and should be included in a Disaster Recovery document that you should be able to obtain from the provider. Each customer will have different expectations so make sure you are fully aware of the process and how you can proceed if something unexpected was to happen.
Security If you decide to purchase a Cloud based monitoring system, then your data will have to leave your site at some point to be hosted on a web server. Physically protecting the data being kept on your site, if any, is in your control but once the data leaves for the web server, you need to rely on a provider’s security measures. Much like the Disaster Recovery document, this should be readily available. The contents of the document should outline the security measures and processes they have in place. Expectations of security measures is personal preference and therefore you should be asking yourself if the security measures are reassuring and provide peace of mind.
Third Parties GDPR
To provide a great system it sometimes isn’t possible for one company to be a specialist of all the moving parts to a monitoring system. For this reason, third parties will need to be used. Common areas where Third Parties are used is for Calibration, Hosting and Development, however there might be others. If this is the case, then it is wise to understand what data will be shared with these Third Parties and their GDPR.
Information Security & Data Retention
One of the great things about software-based monitoring systems is the ability to store historical data. It is great for reporting and compliance but how easy is it to access? First and foremost, using the previously mentioned measures, you want to make sure that it isn’t easy for unauthorised personnel to access the historical data. However, you want to make sure that it is easy for you and the other authorised end users to access. For the most part, accessing historical data is a simple process but there are a few things to check so you don’t fall into any. One of these being to charge for access to your historical data. Sometimes historical data is archived and there will be a fee to gain access. Maybe the fee is very small and maybe you are happy to pay? Either way, it is something I would advise checking before purchasing.
The other consideration is to the size of storage you have available. If your historical data is important to you then you must check that no data is deleted if you reach maximum capacity. Once it’s gone, it’s gone! Historical data may also be transferred, or backed-up, to an alternative server for storage reasons. Although this may not be a route into your network for any intruder, some of the data may be sensitive. Ensure the same measure of security are taken as outlined above.
I hope this guide has been useful. Please visit www.logicall.co for more guides or sign up for our monthly newsletter below to make sure you don’t miss out on any future posts.
Written by Tom Hunt
White Horse Scientific firstname.lastname@example.org