In Part 1 and Part 2 of this blog series we looked at the segmentation of the IoT security architecture. In this post, we shift our focus to IoT security lessons from recent projects that could be used to improve security for the Internet of Things.
We don’t have to look too deeply to find practical ways to protect IoT operations. In this post, we will cover three common issues facing IoT projects and best practices to resolve.
- Lesson A – Message metadata can be leveraged to secure dispersed data distribution
- Lesson B – Legacy control equipment will often be the “weakest link”
- Lesson C – Vendor “fine print” may create data leakage leading to increased risk
Lesson A – Message metadata can be leveraged to secure dispersed data distribution
All IoT devices need to send data to a ‘cloud’‘ somewhere, and often, to multiple clouds simultaneously. This cloud can be something hosted on the Internet or a system inside a company’s data centre. Sending data to a cloud means allowing data to be ‘consumed’ to the cloud, the data owner’s IT systems, a third party hosting site or a hybrid of these. Some companies require that data collected from devices, be used by one or more companies for analysis, reporting and subsequent actions. This is a rapidly increasing trend.
One approach to enable this is to encapsulate all the data as a message. In many cases, it doesn’t really matter how that message is structured, or what protocols are used. However, using messages means that they can be queued, copied, routed or broadcast securely to multiple parties. It also means that one user reading a queue of messages will not interfere with the queue of another user.
Messaging protocols such as MQTT and AMQP are commonly mentioned in IoT implementations and each has their advantage. The important thing to remember is that when ‘consuming’ these messages, all the data necessary to understand and process the message content does not necessarily need to be encapsulated in the message. Likewise, the consumers of the data (messages) need not understand how the device collecting the data works (e.g., what it is talking to, what sensors are involved, etc.). All they wish to know is simple: what is the reading, what units are used, what machine does it refer to, etc. This is known as the ‘metadata’ of the system and parts of it can be stored and managed separately from the readings.
IoT Security Lessons
George Cora, security specialist at Ardexa, presents a recent metadata example:
“The owner of an energy plant wanted to allow an analytics company to access operational data from the plant in order to help improve performance and forecast production. At the same time, an unrelated maintenance company required alarm and machine parameters related to the service of the machines, however they were NOT permitted to access to production data. The complication is that some maintenance messages (such as vibration data) with some additional processing, may result in leakage of sensitive operational information. Therefore, how can a message be sent, without releasing operational data?
One approach to solve this, is to use the message metadata to limit access. By defining various ‘grades’ of maintenance messages (detailed within the metadata), the data owner can apply a criticality ‘grade’ that essentially ranks the operational data based on its sensitivity level. This enables the appropriate messages to be sent to the corresponding company. These messages should be easy to consume and include just enough metadata so that the end user can not extract any detailed knowledge of the reporting device. Furthermore, if the vendor ‘cloud’ service is not trusted, then these messages could also use double encryption, so that they can still use the cloud infrastructure, but no-one except authorized users can read the messages.”
George Cora, CEO at Ardexa
Lesson B – Legacy control equipment will often be the “weakest link”
IoT devices reside in all sorts of environments and networks. These devices usually need to communicate with other devices or sensors, and can therefore be found in some sort of industrial network. Most IoT solutions have software on the device whose task is to arbitrate communications with the cloud – usually called the ‘agent’. Agent stability is of high importance, as it has to be as resilient and functional as possible. For example, the agent must have the ability to transfer data and files in any format, including photographs and video, as well as a host of other tasks and be designed to collect data at very fast rates (up to 1000 events per second). These agents also need to communicate securely with other devices on the local network. From a security point of view, it is often these older existing networks that will introduce the greatest security concerns.
IoT Security Lessons
George Cora, security specialist at Ardexa, presents a recent “weak link” example:
“Some industrial networks have systems that can send alerts via the 3G ‘mobile’ network. They are essentially a mobile phone, whose job it is to ring a number and/or send an SMS or other message if an alarm condition exists. The problem is, if these 3G gateways are not configured correctly, then they can be used to answer calls and therefore be used as a gateway into the network. This is an unauthorized and insecure ‘back door’ to the industrial network. This shows that the security of an IoT implementation sometimes comes down to its weakest link. Our experience is that this weakest link is often not the device itself, but another legacy component that may appear as a ‘trusted’ network component. The best strategy in these instances is to design the IoT device or service with ‘zero trust’ i.e., not having to trust other network components. Where possible, this means the device should have a firewall, using encrypted and authenticated links.
The recent vulnerability to WeMo, a cloud controlled ‘IoT switch’ shows what happens when encryption and authentication are not used. Similarly, securing a connection to sensors is sometimes neither desirable nor possible. For example, when connecting to a serial or RS485 network it may be impossible to secure the link as many of these IoT connections made to legacy equipment cannot support any level of secure communications. Furthermore, the cost to change such machines is prohibitive. On the other hand, when using Bluetooth or WiFi to communicate with devices, it is usually essential that the link be authenticated and encrypted. Therefore, a sensible balance between risk and cost has to be achieved when dealing with legacy equipment. This is fundamental in most successful IoT projects today.”
George Cora, CEO at Ardexa
Lesson C – Vendor “fine print” may create data leakage leading to increased risk
It is important to understand, that a lot of companies who offer ‘IoT’ cloud services, are doing so with the unspoken objective of controlling their customers’ data. This, of course, can raise serious privacy issues. To avoid losing ownership of the data, a German Industry Association recently told its members to refrain from working with big cloud vendors. The Association was highly concerned by the big cloud vendors’ terms and conditions that take advantage of their market positioning by claiming ownership of the data and essentially doing whatever they want with the data. Security vulnerabilities can arise if the information (however mundane it may seem) gets into the wrong hands. For example, social engineering attacks typically use seemingly innocuous information (e.g., names, addresses, phone numbers). This can be used to enhance psychological attacks on users by attempting to extract more sensitive information (e.g., passwords) to gain access to the secured network.
IoT Security Lessons
George Cora, security specialist at Ardexa, presents a recent “fine print” example:
“A well-known IoT company has a legal disclaimer with their products that states that their cloud ‘gathers information from users, which may be comprised of … personally identifiable information’. It then goes on to say that ‘We do not consider the name, title, business address email or telephone number of an organization and/or employee of an organization …’ to be ‘… personally identifiable information …’. This is a case in point to look very clearly at the legal disclaimer. Some businesses will collect your or your client’s information and sell it or use it as they see fit. That is their business plan, and it is up to you to check because if the release of user information is specific enough, this can in turn, disclose information on the users of the particular IoT network. Potential intruders of the IoT network will now have specific user information to leverage through social engineering attacks. The end result is a risk increase to the IoT network.”
George Cora, CEO at Ardexa
That concludes our 3-part series on Understanding IoT Security where we looked at IoT Security architecture on the device, communication, cloud and lifecycle management layers as well as highlighting IoT security lessons from recent IoT implementations. For more info on the top IoT security vendors in the market check out our List of 150 IoT Security Companies. Also, find how the overall IoT security market is shaping up in our IoT Security Market Report released in September 2017.
We would like to thank George Cora, CEO of Ardexa, for his expert security contributions. For more information on Ardexa device management and secure connection services, please go their website at http://ardexa.com/.
About George Cora
George is a seasoned IoT Security expert with more than 20 years of experience from senior IT and operational security roles in defence, intelligence, industry, healthcare and government. George has founded security businesses and developed numerous software Internet-security applications currently in use globally by some of the most prominent organisations.
About Ardexa
Ardexa is a privately-owned, global IoT software company, headquartered in Australia. It develops innovative software and operates cloud services to help manufacturers, operators, developers and engineers build their device services and businesses.
For more information about Ardexa, click here.
