Anyone doing IoT would agree that security is paramount for safe and secure operation of devices. Devices are one of the most critical elements in the Internet of Things (IoT). Security breaches at the device level could result in severe damage including financial losses, loss of credibility and trust and in some extreme cases even human danger. However, a number of high profile cases with large scale organizations involved have indicated that these breaches are not the result of one access point getting compromised; rather it is a result of multiple points of failure. In this scenario ensuring that even one of these access points becomes impenetrable would mitigate these breaches and in turn minimize the damage caused. Although, there are several challenges in designing security measures within these devices; developers need to be able to identify “just enough” security measures that need to be put in place.
Devices are the point of contact for human interaction and are responsible for generating the data on which the system relies. The security of these devices can be difficult at times as these devices are vulnerable to not just network borne threats but to physical tampering as well. This makes it pivotal for developers to address security issues at the time of designing of these devices. Even though there might be many security measures that developers can put into place, it is important to identify the accurate amount of measures that would be most effective and should be put in place.
While designing security in devices, developers come across a variety of challenges; take for instance an embedded device, with a small footprint and limited computing resources, heavy security measures would hinder the performance of this device. However, too little security might leave loopholes for breaches. This makes it important for developers to be able to identify that specific security measure which would qualify to be “just enough”. In order to identify this “just enough” security, these developers rely on three criteria:
1. The environment where the device has been deployed? – is it within closed door in a secured location, or out in the open in a public environment.
2. How is the device connected and communicating with the network? – is it connected to a public or a private network, is it behind a firewall, is there any form of encryption employed.
3. The type of data the device is storing? – The sensitivity of the data been stored by the device.
Based on the answers to these questions, developers can identify the appropriate security measures to be integrated with their devices. However, it is always preferred to have access to an operating system that would enable the user to choose the most suitable security measures from a set of options given to them.
Although these criteria allow the developer to identify the security measures to be put in place, they also need to ensure that measures are implemented at every stage of the device lifecycle, from the initial design to the operational environment.
• Design phase: it is critical to ensure that no malicious code gets introduced while the development process is underway. This would be possible through signed binary delivery, assuring the authenticity and non-alteration of code, and developing on a software platform that has been certified under industrial security standards such as IEC 62443 and IEC 27034.
• Execute phase: the aim is to ensure that the right software is in place on the right hardware and that they trust each other. This root of trust can be established by using secure boot technology and cryptographic key signatures to prevent unsigned code from getting executed.
• Operate phase: multiple measures can be deployed to prevent malicious attacks in operation mode, including controls to prevent unauthorized access and securing networks using encryption.
• Power Down phase: when the device is at rest, measures such as encrypted storage and secure data containers should be in place to prevent on board data access.
A much talked about example for this is a recent security breach suffered by a major retailer in the US that resulted in the theft of millions of customers credit and debit card details. The breach took place by compromising the Point of Sale (POS) devices to gain access into the network and capture the customer data in real time. A thorough breakdown of the incident showed how the breach was possible because multiple access point failures, starting from the HVAC systems not being isolated which gave the hackers direct access to the POS systems that existed on the same networks. Through these POS systems the hackers gained unhindered access to the cash registers, where they reverse engineered the code to gain real time data of the customer’s credit and debit card credentials every time someone would make a purchase. The depth to which these hackers had gained access would have ensured they remained invisible had outside investigators not discovered the anomalies and alerted the retailer.
