Security architecture for the Internet of Things

By: Prakash Chakravarthi

Security is one of the key drivers of the Industrial Internet of Things. Hacking and privacy are hot topics in the context of IoT and concerns run high in terms of the security of various product offerings in the market. These concerns are real and much damage can occur if systems are not architected correctly to achieve maximum levels of security. There have been many publicized cases of hacks into water and electric utility systems in the media. For many companies, this has led to a fear of moving away from the legacy SCADA systems. However, there are well-known security methodologies and best practices that can be employed. If security is implemented correctly, the risk of security breaches in Industrial IoT can be comparable to other aspects of modern IT.

prakash.jpg

The figure above illustrates three different architectures for industrial IoT.

  1. The first is the series of dark blue circles connecting sensors/controllers to back-end enterprise systems. This is the legacy connectivity that’s existed for the last four decades or more. This model represents a non-scalable and non-secure architecture because it was never designed with these two considerations in mind. The sensors/controllers either cannot implement modern IP-based security schemes due to constrained resources, or they have legacy protocols in them that don’t lend themselves easily to modern security practices.
  2. The second type of IoT architecture is implemented by cloud services companies that rely on providing business analytics to displace legacy back-end systems for collecting and analyzing data. More than 100 cloud services companies have emerged in the IoT space – both general purpose ones, like Amazon’s AWS or Microsoft’s Azure or others focused on specific vertical markets such as energy efficiency in buildings. The problem is that they connect to sensors/controllers in the same legacy way, not adding very much to the security. While the cloud side is implemented securely, the link from sensors/controllers to the cloud remains insecure.
  3. Machfu addresses this problem through a third type of architecture: Security is implemented right at the edge. The functions of the traditional programmable logic controllers (PLC), COMMs (modems or routers) and middleware are coalesced into gateways (like the Machfu Gateway). Note that the Middleware is actually purpose built software for each back-end application or cloud platform that a solution designer may choose. This makes it hard to migrate from one vendor to another easily and thus acts as a barrier to innovation through vendor lock-in. The Gateway platform is based on a Security Enhanced Linux kernel (SELinux) running on industrial spec’d hardware. The platform provides network connectivity over cellular, Ethernet, WiFi, 802.15.4 (6LoWPAN / Zigbee), and other technologies.

The Linux kernel also includes a recent ‘netfilter’ implementation, which serves as the basis for best-practice firewalling and traffic policy implementation. This particular feature allows for expressive and complete application of rules to all traffic which flows across IP interfaces within the system. Such expressiveness is not generally needed for consumer facing applications, but it is very relevant for industrial applications and Machfu brings out and exposes these capabilities. Using the IP based traffic architecture and the generic routing abstraction provided by the Linux kernel and netfilter, a variety of policy-based security rules can be dynamically applied and maintained within the system.

Users can independently develop and deploy applicants onto the platform, leveraging sandboxing, isolation, and security features. Application modules can be independently managed and upgraded, including provision for signed code and delegation of access to OS resources, including network and device access on an a-priori basis. Thus, an application that does not need access to, for example, a Modbus interface can be denied access to that interface per the OS policy. There is a granular means to separate applications from each other and to extend only the functionalities needed to each application – again, maximizing security and protecting against data breaches.

Applications may further implement security schemes for local storage (e.g. encrypted files, encrypted database, etc.). Access to local storage for a particular application is by default constrained to those resources created/owned by that application. Thus ‘cross application’ manipulation of data at rest is by default sand boxed and prohibited. In addition, Secure Boot can be supported depending on the particular underlying hardware.

Such an industrial grade hardware/software/security platform should ease concerns on implementing industrial IoT securely. Few other embedded platform solutions offer such out-of-the-box breadth of security features.

Prakash Chakravarthi is the Chief Executive Officer of US-based IoT company Machfu.

All views/opinions expressed in this article are that of the author. This Website may or may not agree with the same. Image supplied by the writer.

Save

Save

Save

Save

Save

Save

Save

Save

Save

Leave a Reply

Click here to opt out of Google Analytics