Security starts with the identification of risks that in turn defines actions that are required. IoT devices range from simple sensors to embedded intelligence in sophisticated machines, and their deployment covers the whole spectrum of industries, and applications, as such there is not a single standard answer. It would seem unnecessary to consider imposing IT security practices to pilot a handful of simple monitoring sensors in a building, but a pilot should be the opportunity to learn about the technology and security aspects as well as the business benefits.
Current risk justification often focuses on the obvious difference in the security risk profiles; using as a simple example Building Management IoT deployment downstream data flows from IoT temperature monitoring points are seen to have low to minimal risks against upstream command responses to activate power, heating or other building functions.
But this misses the risk to the Enterprise from each and every IoT sensor as a network access point that could be compromised. Eurecom, French Technology Institute, discovered 38 vulnerabilities in the Firmware of 123 IoT sensing products. Hundreds moving to thousands of IoT connected devices multiplies the risk of security breaches to new levels.
Experts believe it likely that many Pilots and initial IoT deployments will occur without an adequate understanding of the security risks, and require expensive retro attention. A blogs cannot provide in depth coverage of the topic, but it is an excellent format to draw attention to the issues and to provide links to more in depth papers. For simplicity, and inline with the popularity of IoT for Building Management, this blog refers to IoT sensor deployment in Buildings as an illustrative use case.
Before considering new security capabilities that have been, or are being, developed for the IoT market place, it pays to understand the basic architectural model. The so-called Final Mile Architecture described in some detail in the blog the importance of using Final Mile Architecture in an IoT Pilot stressed the importance of understanding the use of Connection, Asset Data and Mapping, and Data Flow management. However this blog did not mention the need to consider security aspects, as an example the importance of Firewall protected ‘safe’ location of the IoT Asset Data and Mapping Engine together with the Data Flow Engine.
Whilst Network Connection management is understood from its role in IT systems there is very little understanding of the use, and role, of IoT Gateways, Asset Data and Mapping, or Data Flow engines as core building blocks in IoT deployment, let alone how to use each to reducing security risk and vulnerability.
Most IoT sensor deployments will make use of one of the specialized physical network types, such as Zigbee, that interconnect low value sensor points and will connect to the main ‘Internet’ through an IoT Gateway. IoT Gateways come in all forms from simple physical interconnection of different physical network media to those with sophisticated intelligent management that introduce security capabilities. Intel publish a good guide to IoT Gateways in general with Cisco offer a useful FAQs on the topic.
The choice of an IoT Gateway product for a simple/pilot deployment level tends to focus on the primary physical network function of a Gateway, rarely recognizing that a Gateway is a key access point to an Enterprise, or public network and should be secure.
The IoT Gateway coupled with Network Connection management should be considered as the first major security point in IoT architecture. Some IoT Gateways add encryption to traffic forwarded across the network as a further security feature. Citrix publish a useful guide to the security implications of IoT Gateways. and Intel offer a guide to the implementation of security profiles in IoT Gateways. IoT Gateway physical locations are usually decided by the transmission capabilities of the sensor side network, but the physical location of the next two functional blocks, the Asset Data and Mapping Engine and Flow Data engine, is a critical security consideration.
The IoT architectural question relating to where, and how, processing power is related to network architecture was outlined in the blog; IoT Architecture. But the arrangement and physical location of the key functions of Asset Data and Mapping engine and the Data Flow engine in relation to security will be dependent on individual deployment factors. Therefore the following statements are general principals applied to the Building Management example.
As the role and capabilities of an Asset Data and Mapping engine, and Data Flow engine are not well understood it might be desirable to read a previous blog IoT Data Flow Management, the science of getting real value from IoT data. The white paper Data Management for IoT provides more detail in the use of IoT data together with its differences to conventional data. However the best explanation of Asset Data and Mapping with its function in adding context data and location to simple IoT sensor event data comes from watching the Asset Mapping Explainer video on Building Management.
It is good security practice to keep sensor event traffic across the network semi anonymous and not append the critical contextual data that identifies the sensor, location and complete data file from the Asset Data and Mapping engine until securely within the Firewall/Data Center and ready for processing.
Just as few pilot installations appreciate the full role of the IoT Gateway beyond physical functionality, few pilots include the means to manage large numbers of IoT sensors beyond a simple recognizable representative number on a dedicated GUI screen. Good practice will use an IoT Gateway with encryption to ensure that all data traversing the network to the Asset Data and Mapping engine has low vulnerability. After the full data set is appended to the sensor event data by the Asset Data and Mapping engine it becomes an important architectural consideration to limit where on the network this data is accessible.
Similar considerations apply to the Data Flow engine in terms of its location, but also as to its role and use as a part of the IoT security architecture. A Data Flow engine, as its name suggests with its functionally described in the blogs previously referenced, can ensure that not all data is flooded across the entire network.
Cleverly positioned IoT Data Flow engines can control and manage data using elements of the data payload to direct to required destinations. Avoiding all the data being available over the entire network is another basic security good practice in IoT architectural design.
IoT Architecture incorporating basic security elements in its design is a new discipline, and as such really should be incorporated into proving pilots to gain experience in these new functional building blocks before moving to scale deployments.
As IoT gains momentum and increasingly intelligent devices are interconnected Security becomes an increasingly issue, witness the challenges with Mobile Phones and Tablets today. Developing a full understanding of the all the elements and vulnerabilities requires an effort to master the topic, and the rest of this blog is devoted to providing the necessary links.
The development of both new security risk and protection methodologies and new technology capabilities is under way and there are several different initiatives driving or coordinating efforts that provide interesting details.
Two good starting points are; 1) The International IoT Security Foundation for a general appreciation of the subject broken down into the various elements and issues in a multipart series. 2) The ambitious OWASP (Open Web Application Security Project) Internet of Things Project describes itself as designed to help manufacturers, developers, and consumers better understand the security issues associated with the Internet of Things, and to enable users in any context to make better security decisions when building, deploying, or assessing IoT technologies. The project looks to define a structure for various IoT sub-projects such as Attack Surface Areas, Testing Guides and Top Vulnerabilities.
A more commercial view comes from WindRiver, an Intel company, whose products are embedded into Intel processors, and from there into other products, in their white paper on Security in the Internet of Things with the interesting sub title ‘Lessons from the past for the connected future’. All these references provide both methods and architectural appreciation of the challenge with solutions using current technology. There are however two new technology approaches, one aiming to authenticate process interactions and the other to authenticate actual processor functions.
BlockChain has suddenly gained a big following for its possibilities in ensuring that ‘chain’ reactions, or interactions, can be tested and established as secure in their outcomes. Though somewhat infamous for its relationship to Bitcoin Internet currency, nevertheless it has much wider applicability in the ‘any to any’ environment of IoT. IBM has built a complete Blockchain demonstrator reported by CIO online under the headline of IBM Proof of Concept for Blockchain powered IoT
PUF standing for Physically Unclonable Function is the technique for using the variations introduced during chip production to be read as a unique ‘signature’ for the chip as part of establishing its authenticity. This unique signature is used to create a unique encrypted checksum reply to an identity challenge enabling several different possible uses. Wikipedia provides a good description of the basic technique and its principle applications.
In conclusion the following quote is taken from the concluding summary of the Telefonica White paper ‘Scope, Scale and Risk as never before’
The networks IoT creates will be some of the biggest the World has ever seen. And that makes them enormously valuable to attackers . . . it is apparent that the Internet of Things is growing far faster and with a higher user knowledge base than its predecessor – The Internet itself. And this raises significant concerns.
What is a pilot today, and a closed IoT network tomorrow, one day will be part of the biggest network the World has ever known so in planning a pilot, or a deployment, it is absolutely necessary to understand the security dimension.