IoT: are we grasping it or groping at it?




Some time ago I was passively listening to a discussion at my office about making our office building "smart" as part of the IoT initiative. It was an interesting discussion. People were discussing everything about data - what kind of data will be available, how much, the database used to store it, data mining, finding out patterns and trends etc. etc. However, none of them was interested or even curious about knowing or discussing about the "things"!

 Well, it was of little surprise to me as these days this can be seen almost everywhere. The use of acronym "IoT" has become very fashionable. Almost every company wants their product to be "smart" and "IoT ready" in someway or other. But the question is do we really understand or want to understand what IoT really means or are we just trying to rip benefits from the current hype about IoT?

 IoT is internet of "things" like sensors, actuators etc. So the hardware is an inherent part of it. An IoT solution has both hardware and software parts. Only having a good sensor network is not sufficient, at the same time just thinking about data mining does not make a product an IoT product. It is an end-to-end system - not just sensors or not just data mining. So what is the current scenario most commonplace with so called IoT products? If we scratch just below the surface we will most likely find a data mining and/or visualization software. However it is important to understand that only having the big data part is no different but just like another credit card history data.

 These days everybody seems to be interested in mining data, offer analysis, trend research etc. and there is nothing wrong in it. However, marketing a data analysis product as "IoT" product is the unethical. Most of the offerings are nothing but data analysis and presentation tools working at various speeds. There is nothing special with respect to IoT. Unfortunately many so called IoT product designers appear to be thinking about data only after it is delivered to them. There is no thought about gathering it leave aside controlling "things", rather there is general ignorance about it - "That is somebody else's job to deliver data to us {and our software is "smart" after that}!" Well, that's definitely hilarious! All these software products are just data analysis packages, nothing more and definitely not IoT products.

 Then what could be a true IoT product? I think a true IoT product is the one which truly interacts with the "things" or at least offers well defined ways to interact with them. This implies bi-directional communication, control and security. This also implies scalability. It is also true that having these capabilities does not make it a true IoT product. Having capability of interacting with thousands of sensors does not make a system "smart".  Having a lot of data does not mean getting true trends.

The converse is also equally true - just having a sensor/controller network and support does not make it a complete IoT product. It's just a network, not benefit can be ripped unless the data it generates is consumed for further analysis. So, here comes the other half - the data analysis part.

 If a product offers provides both these halves, it can be a true IoT solution. Even if a single half is being offered, as long as it is offering an easy integration and wide options of integration with the other half, the solution has a potential of being an IoT solution. But, I feel if somebody is trying to offer just a single half branding it as "IoT" offering, it really can not be called it that way!

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