Security in pervasively connected IoT world

With growing number of IoT devices, often of low computing power, we observe increased security risk in our environment. Wireless sensors and actuators (devices that invoke actions in the physical world according to the signals received through an ICT network) that dominate IoT environments, often have holes through which malicious hackers can break into conventional computer networks. Another common way to intrude IoT systems is related to the transfer of sensitive data about users and their environment. We can imagine several scenarios of sensitive data that may attract cyber criminals. For instance, wireless sensors can be applied to transfer medical records (i.e. blood pressure, heart rhythm) that precisely indicate patient’s diseases. Such information can attract insurance companies or inquisitive journalists if they refer to a famous person. Another example is Smart Campus where IoT devices are often connected to databases that store records about student’s achievements and their personal data.

Security threats in IoT networks

You may have heard the story about jeep Cherokee car whose control system was hacked in a way that allowed a remote user to cause an accident or the intelligent refrigerator connected to a home computer network, which was also attacked. More recently, in 2016, the Mirai malware affected thousands of IP camera and IoT devices using a list of default login credentials. The malware was used to turn these devices to “bots” by creating a botnet in order to cause dramatic drop in network performance. We have to bear in mind that wireless sensors and actuators are vulnerable to such attacks if security recommendations are neglected. From hardware point of view IoT devices have difficulties in producing long (and thus more secure) cryptographic keys – they often lack sufficient resources to do so, emphasis is usually put on low power usage or hardware simplicity (and, thanks to that ensures a low price). Moreover, IoT operators and users must adhere to security recommendations for conventional networks like periodic change of passwords, limitation of authorities (not every user should have the same rights) and so on. They must also modify default settings of built-in operating systems on IoT devices before plugging them into a network where enemies can instantly overhear (often referred to as “sniff”) the transmission.

Unlike conventional computer networks, IoT infrastructure makes it difficult using classical security systems – IoT networks are very heterogeneous, communicate through numerous, often immature, protocols, are intended to be extremely dynamic with new instances but also types of devices to be joined.

Finally, the default configuration of most IoT devices is designed in a manner that attempts the them to work properly in very different conditions – so it is rather relatively generic, not “security hardened” and thus it exposes IoT devices and their users to attacks. Therefore, administrators of IoT networks must handle “security hardening” of sensors, actuators and gateways in addition to periodic upgrade of firmware on these devices.

Security issues in symbIoTe

In symbIoTe, applications and resources of an IoT network are shared by other IoT platforms which helps to deliver sophisticated services to end-users. For instance, let us imagine students that are users of a Smart Campus IoT platform at their home university. While visiting another university these students would like to use similar services (i.e. opening doors, enter a library or a canteen). However, they may not have identical permissions with students of visited university.

The main security challenge in symbIoTe is to provide access to resources that are stored outside the home IoT Platform (i.e. the Platform where a user is logged into or assigned to) in a way that prevents unwanted users from capturing the data or using the application. A motivation for hackers to use our resources could be simply financial – to avoid paying fee for accessing foreign platform’s resources. They also could try to steal personal data of legitimate users and then misuse them or sell them on the black market.

How we identify our users? You surely are familiar with the login and password manner. In symbIoTe, we do not use directly that mechanism, but rather something that is called ABAC – Attribute-Based Access Control. Have you heard about it?

Imagine that in certain situations you do not want to reveal who exactly are you, but there is a need to prove that you have the right to act upon something. For instance, to have a tram ride you will require a ticket. If there is a ticket control, you need to show that ticket but not your personal ID. In another instance, if you are a professor and you might want to populate your presentation among your pupils that have attended the lecture but not share with the complete list of students registered. In both cases, having a ticket, or attending a class, is an attribute. So attribute is not something you know (like a unique password) but rather something you have (usually it is stored in a sort of a token). Multiple users can have the same attribute by definition and this is nothing bad. Regardless of who exactly the user is, if he or she has got an appropriate attribute – may be permitted to access a resource or make action. In symbIoTe, an attribute may be considered as a particular property of a user or its behavior – e.g. the role of a user, the country of a user, or the particular time he or she tries to access a resource. ABAC is a next generation authorization paradigm that provides a flexible and efficient access control mechanism. Imagine this time a pupil who has got a sensitive medical problem and does not want to contact a school doctor in person. Instead he or she may write a message in the ABAC-compatible communicating system plus provide attribute “I am the pupil in that school” (so I may contact the doctor and deserve help).

In symbIoTe there are many different attributes. Access to applications or other resources may be granted if a user has got appropriate set of attributes (usually more than one) and that set satisfies an “access policy”. Apparently, these attributes also are not the things users want to bother about. Actually, if you use your IoT platform, you log somehow to it (symbIoTe is not interested in how you do that, it may be well known user-password pair). If your platform cooperates with symbIoTe (we call it is federated with it) in the background you receive a set of attributes (like “Member of Platform X”, “Professor”, “Student” or alike). And if you want to use additional resources, facilitated by symbIoTe, these attributes are exposed to symbIoTe – also in the background. If they match the access policy – you can use the resource. Thanks to that, symbIoTe does not need to know everything about you. Its databases are much simpler to design and maintain and backup occupies less space. Your data are not spread everywhere.

Anomaly detection in symbIoTe

The symbIoTe system will be equipped also with another mechanism that protects networks against malicious attacks, and confidential user data against illegitimate access. This mechanism is called “Anomaly Detection” and it relies on detecting non-typical behavior of users, applications and networks. Unlike classical antivirus software that rely on known attack signatures, this approach aims at observing network traffic or application behavior and defining metrics that characterize ‘typical’ user behavior. Then, sophisticated algorithms identify whether certain deviation from standard behavior is an anomaly or not. Let us imagine a temperature sensor in Smart Home IoT platform that is polled on average 3 times per minute on average and during the past month the maximum number of polls reached 20 in a minute. Suddenly, we have detected a new user that has polled these sensors 1,000 times in a 10-minutes period that is 100 times more per minute on average. In this case, we have probably witnessed an attempt of the so-called distributed denial of service attack (DDoS) whose aim is to exhaust network resources such that symbIoTe users cannot access their data and run their applications. Of course, this is a very simple example – when appropriately selected and configured, anomaly detection algorithms are able to detect much more subtle deviations. The anomaly detection engine, besides attacks, in certain cases may also support an early detection of system or network failures.

Conclusion

Detecting literally every threat is not yet possible, especially in IoT networks, however being aware of security threats and careful configuration of IoT network (especially – changing default passwords and upgrading firmware on sensors, actuators, gateways and other devices) increases significantly the chance that our data and network users remain safe.

Hopefully, platform owners and their users feel comfortable with symbIoTe and are not discouraged by the description above. Our specialists work constantly on security aspects and help to build network configurations of joining parties in a way that matches to symbIoTe technical requirements and remains secure under the various threats.

Michał Pilc, Gerard Frankowski (PSNC)

Task leaders of “Security and Access Scopes”