Understanding IoT Security (Part 3 of 3): IoT Security Lessons From Recent Projects
Understanding IoT Security (Part 3 of 3): IoT Security Lessons From Recent Projects
In this series finale, we examine important IoT security lessons to be learned from recent events about metadata, vendor control, and points of vulnerability.
Join the DZone community and get the full member experience.Join For Free
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 center 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.
Exhibit 1: An example of a typical message with meta data and content
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.”
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.
Exhibit 2: Legacy industrial control network with typical points of vulnerability
Here, George Cora 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.”
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.
Exhibit 3: Personal Identifiable Information
Again, George Cora has an example of 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.”
That concludes our three-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.
Published at DZone with permission of Padraig Scully , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.