IoT and Security




Scene 1
 
It’s a pleasant Sunday morning, a perfect weather and you are out on a long drive cruising a stretch of highway in your latest car. The same car which caused some sensation when you showed this latest techno-wonder to your friends. Today you feel lucky because there is almost no traffic at this hour.

Your all-time connected car is constantly updating you about weather, road conditions, nearest places of interest and of-course your social feeds. You driving at moderate speed enjoying the drive. Suddenly something seems to be wrong. Without you doing so, your car starts accelerating, you feel engine revving up, steering wheel feels so heavy and the breaks seem so hard to apply. The car seems to be out of your control. Instead of showing the usual data, navigation panel in your car is showing some funny messages. Fortunately, after few minutes things seem to be under control again. But you are damn scared.

Scene 2

Your neighbour has returned home after a major heart surgery. Best thing is that his doctors can keep an eye on health of his heart without seeing him, thanks to the latest Internet connected cardiac device which is implanted in his chest. Using these device they can control his heart function and prevent heart attacks. He is recovering fast and is in good health post operation. Since he’s being constantly monitored by doctors, there is nothing to worry about.

Suddenly at one night you see ambulance rushing him to hospital in a critical condition again. What happened, you wonder.

Incidents similar to these are happening around the world. More sinister situations are being confronted every day. You have witnessed results of attacks by IoT hackers.

IoT is inevitable and accept it or not, it is and will be essential part of modern life. That is why it becomes so important to understand as much as possible about security in IoT world. This article series is aimed at covering this topic in details.

 End-to-end IoT solution

As a very general design, an IoT solution can be seen as a four tier solution. The first tier is smart sensors or devices, the second tier is aggregator or an edge device, third tier is cloud or server which stores and processes data, and the fourth tier is end-user or end-devices. All these tiers communicate with each other using plethora of protocols over wireless or wired media.
At one end there are various "things" which collect data and/or assert conditional control. These devices generally talk to an aggregator node which has some local intelligence and processing power. The aggregator further connects either to server machine or to another aggregators. All these components use variety of communication protocols and types, as the requirement dictates. The data collected from smart sensors is consumed by analytical and visualization applications as per the needs of the end user.

While discussing security, knowing a couple of most commonly used terms might help understanding the subject better.

Attack vector – it is a way or mean by which a hacker can get access to a computer or network to carry out malicious activity.

Attack surface – it is the sum of all such ways (vectors) which can be used to hack a computer or a network.

Now let’s take a quick overview of major components in an IoT solution before we end this introductory article.

End devices
 
These are smart sensors or smart devices. These devices may or may not have local processing power. This category is vulnerable to physical attacks, hardware tampering and firmware/software hacks with intentions including but not limited to eavesdropping, tampering of data, tampering device functionality, denial of service and plain destruction of the device.

Edge devices
 
Generally end devices communicate with edge devices. Edge devices (also called as aggregaters, gateways) are more sophisticated compared to end devices. They have some level of local processing power and intelligence. Physical attacks are relatively difficult but not impossible. None the less, they are also “devices” and are very much susceptible to all the attacks applicable to end devices. With relatively less effort, attacks on edge devices leave a large impact on the system than attack on individual end device.

Communication
 
Different types of media and protocols are employed for communication between end devices to edge devices and between edge devices to cloud. Lighter protocols like MQTT, AMQP, CoAP are utilized by end devices to talk to edge devices, while there is no such constraint for edge devices to communicate with cloud. Owing to great number of end devices, popular medium of communication with edge devices is wireless (e.g. Bluetooth, BLE, ZigBee etc.), but wired media may also be used. Communication between edge devices and cloud/other edge devices popularly utilizes wired media as well as wireless media. All these media are very much vulnerable to intercepts and attacks by hackers.

 Cloud

Data collected by “things” ultimately resides on “servers”. These servers could be physical machines, virtual machines and could be provided by Cloud service providers. But ultimately, somebody has to secure these machines from attacks. Attack surface for this category is big – being connected to the Internet, for example, vulnerabilities in the OS running on server, networking software stack in the OS, vulnerabilities in application software, server configuration – all lead to a broader attack surface.

Applications

IoT applications gather, condition, store and retrieve data. They are written using different programming languages and additional readily available third-party solutions. Apart from language specific vulnerabilities, careless programming practices may also create a new attack surface. Compromised applications cause data leaks, breach of privacy and integrity of entire solution.

End users

The term “End users” encompasses human users as well as devices consuming analyzed data. The devices range from tiny custom devices to cellphones to general purpose computers. End users may use wired or wireless mode of communication with cloud. Faulty or compromised devices can pose serious problems to IoT solutions such as breach of privacy, stolen data and hostage situations. Rigorous authentication methods, controlled access and dissemination of data and secured communication methods are necessary along with other methods to make this last component secure.

What’s next?

In the next part we will inspect and understand security of end devices. We will discuss attack vectors and attack surface for this component. With this understanding we will then discuss different ways and considerations to secure end devices.

Comments

Post a Comment

Popular posts from this blog

Security in Linux Kernel - Part 2

Image
  In the previous part of this series, we saw role of LSMs in kernel security. As mentioned earlier, there are eight LSMs available today in the modern Linux kernel. In this part, let's have a look at different main stream LSMs. SMACK Simplified Mandatory Access Control Kernel ( SMACK ) is designed primarily for embedded linux systems with an intention to make it easier for administrators. This was the second LSM (after SELinux) to be accepted in the linux kernel. It appeared in the 2.6.25 kernel release. This is an attribute (label) based simple LSM, and is the default for Linux implementations tuned for Automotive industry. Yama Yama collects system-wide DAC security restrictions that are not handled by the core kernel itself. It offers control over scope of ptrace() system call to control ptrace attachment by processes. Build time configuration option CONFIG_SECURITY_YAMA and runtime option through sysctls can be used to enable this LSM. The ptrace restrictions can be controll...
Read more

Security in Linux Kernel - Part 3

Image
  In this short post we will explore a Linux system call facilitating secure computing. In earlier parts of this series we saw how LSMs protect the kernel. However, LSMs occupy a much deeper position in the call hierarchy and do not offer protection at process level. Additional mechanism is required to provide protection at process level. Need for a system call In Linux, applications programs use a number of system calls, in fact a large number of system calls are available to applications programmer. These processes using system calls expose a large area of the kernel to malicious attacks. Linux offers a mechanism to limit this capability using seccomp system call, thereby reducing the attack surface. seccomp is enabled using prctl() system call with appropriate operation mode. seccomp Modes The seccomp system call works in two modes - strict mode (SECCOMP_SET_MODE_STRICT) and filter mode (SECCOMP_SET_MODE_FILTER). When seccomp is set to first mode, i.e. strict mode , process has ...
Read more

Trusted Platform Module

Image
In the previous article, we discussed end device security and various factors affecting it. There was a fleeting mention about TPM - the Trusted Platform Module. In this installment we will discuss mode about the TPM. Generally, for any device, the safest way to ensure it's integrity is to make sure it always boots from a secured, verified and unalterable source. This forms the logical "root" of the entire boot process. Once the device boots from a trusted source, it further uses it to verify each and every software component it utilizes. Every module checks and verifies integrity of the next module to be loaded thus forming a "chain of trust" which if broken can be easily detected. This chain of trust then can be extended to encompass other devices across and upstream the network hierarchy. In this installment, let's have a deeper look at TPM. What is TPM? TPM is (generally) a chip designed to provide security related functions. It provides functiona...
Read more