Guest Author: Shakthi V
Anyone who is by any stretch a stakeholder in the IoT scene will tell you that there are two major issues, one is overall security that we discussed in my previous article and then there is the device angle to security. After all, if the device isn’t ready to scale, even the most thought out security schemes will fali miserably. So it is very relevant and important that we touch upon this angle in our second discussion about the IoT that is just around the corner. Let us discuss device level issues now.
There is need for carefully thought out measures at three levels for IoT to make sense, the device, network, and system levels. Here we shall talk about the device level. There is still no broad consensus on the best implementation of security at all levels. But, how do we protect deeply embedded endpoint devices that usually have a very specific, defined mission with limited resources available to accomplish it? That is the challenge. This calls for a structured approach to induct, add and enable a device into the IoT network.
That being said, there is no “silver bullet” or magic solution to solve this. We have to fall back on to the time tested learnings of security and extrapolate, innovate and implement a solution. And this approach can be just as effective for IoT—provided we can adapt them to the unique constraints of the embedded devices that will increasingly comprise networks of the future.
So we see that there needs to be a strict process adhered to, in order to get the device level security right. The main point to note here is that security must be addressed throughout the device lifecycle, from the initial design to the operational environment. It should not be an end or compartmental part of the process. It needs to be over-arching the whole device lifecycle, from manufacture to activation to operation in the IoT scheme of things. Here are some relevant points that can make this process secure and scalable.
- Secure booting: When a device powers up for the first time, the authenticity and integrity of the software on the device is verified using cryptographically generated digital signatures. Similar to the way that a person signs a check or a legal document, a digital signature attached to the software image and verified by the device ensures that only the software that has been authorized to run on that device, and signed by the entity that authorized it, will be loaded. This enables initial trust for the device in the IoT. There is still possibility of malicious intent and attack.
- Access control: To prevent malicious attacks, different forms of resource and access control are applied. Strictly role-based access controls built into the operating system limit the privileges of device components and applications so they access only the resources they need to do their jobs. If any component is compromised, access control will cut off that component and compartmentalize the access of that component to the system so that the rest of the system is safeguarded from similar issues. This is analogous to network-based access control systems such as Microsoft® Active Directory®. Even if someone managed to steal corporate credentials to gain access to a network, compromised information would be limited to only those areas of the network authorized by those particular credentials. And when a component is tagged as compromised, even that access is revoked.
- Device authentication: When the device is added to the network, it should authenticate itself before receiving or sending data. These devices do not have users sitting behind keyboards, waiting to input the credentials required to access the network. How can we ensure that those devices are identified correctly prior to authorization? Just like how user authentication allows a user to access a corporate network based on user name and password, machine authentication allows a device to access a network based on a similar set of credentials stored in a secure storage area that is enabled with communication and handshake protocols. Hence the possibility of device spoofing to attack a system is considerably nullified here. Understood assumptions here are that this level involves smart hashing and key rotation too.
- Firewalling and IPS: The device also needs a firewall or packet inspection capability to control traffic that is destined to terminate at the device. Embedded devices have unique protocols, distinct from enterprise IT protocols. For example, the smart energy grid has its own set of protocols governing how devices talk to each other. That is why industry-specific protocol filtering and packet inspection capabilities are needed to identify malicious payloads hiding in non-compliant protocols. The device needn’t bother itself with filtering higher-level, common Internet traffic—the network appliances should take care of that—it needs to filter the specific data destined to terminate on that device, that way, the limited resources that the device has are also not overloaded.
- Updates and patches: Once the device is in operation, it will start receiving patches and software updates. Device or Network Operators need to roll out patches, and devices need to authenticate them, in a way that does not consume bandwidth or impair the functional safety of the device. It’s not like when Microsoft sends updates to Windows® users and ties up their laptops for 25 minutes. It’s very risky and dicey when thousands of devices in the field are performing critical functions or services and are dependent on security patches to protect against the inevitable vulnerability that escapes into the network. Updates and patches need to be delivered using a mechanism that does not hog the network bandwidth which is intended for critical data. They should also take into account the type of device and its capabilities when updates are delivered
So we can clearly see that, we cannot just make a device, put it on the network and enable it to serve the IoT scheme. There is a lot of thought and diligence that goes into making devices smart, and then the smart devices need to be secure and trustworthy to be added to IoT. The point above are just rough outlines that the sector is grappling with now, they will flesh out into more granular details with the passage of time. Let us know what you think!