Reading Time: ~3 min.

Part 1 and Part 2 of this series provided an overview of Threat Intelligence and hopefully offered some understanding as to what role it can play in helping secure an IoT infrastructure. For those familiar with cybersecurity and how to implement Threat Intelligence in traditional network appliances, the jump to securing an IoT Gateway is fairly straightforward. For those new to the space, trying to put a plan together for integrating Threat Intelligence may seem a bit daunting. This blog is intended to be a guide of questions to start the process.

The first question that should be addressed when building an IoT Gateway is, “What is your audience?” For example, if the given environment in which the gateway will be implemented is closed, meaning no interconnectivity with the Internet, then traditional IP reputation or URL Categorization won’t provide much help. These technologies are built around the expectation that a malicious actor will attack from, or ex-filtrate data to, locations on the Internet. Therefore, with no connection to the Internet these technologies provide little in the way of additional security to an appliance manufacturer. That being said, by definition an IoT Gateway should provide connectivity to the Internet, so the rest of this blog will assume that is the case.

So, what is needed to build an IoT Gateway?

Obviously, there is the interconnectivity that bridges a proprietary physical layer and converts it to TCP/IP traffic. This blog won’t help much with that aspect of the appliance as the respective vendors would know best how to achieve this part of the solution. However, once data has been converted to Internet compatible protocols, building a basic gateway with IP blocking and URL categorization requires: 1) IP packet inspection to extrapolate incoming IP addresses or outgoing URLs, 2) a Threat Intelligence module that allows for the scoring of an IP or URL, and 3) a user interface to manage the policies. Here is a breakdown of each component:

  • Deep Packet Inspection (DPI): Simply put, this is examining each data packet as it comes through the appliance, stripping out header information that contains the IP address for inbound traffic or the outbound URL. There are robust open source solutions such as nDPI from ntop that do a very good job analyzing traffic, but partnering with a provider such as Qosmos might be the right approach for those new to security. The problem isn’t in the ability to inspect packets but rather the ability to do it at line speeds. Those who aren’t experts or who are looking to go to market quickly would do well to find a partner in this space.
  • Threat Intelligence Module: There are several considerations in terms on selecting a provider, how best to implement a solution and how to implement Threat Intelligence in such a way that it becomes a differentiator rather than an “also have”. Take the time to become educated on cost to performance aspects a Threat Intelligence provider offers and understand the ramifications of the level of false positives and uncategorized lookups that a solution will have on the overall implementation of the final product.
  • Policy Management: Nearly as important as the Threat Intelligence itself is the ability for appliance administrators to configure and manage policies. Will there be a need to manage based on region, user, device type or some other granular method specific to an industry? Can the individual device management be done through a cloud-based interface allowing for quicker deployment and lower appliance resource requirements or will it need to be built into the operating system for a given appliance to be managed locally? Taking the time to ask these and other questions around the user interface is key to building a successful solution.

The intent of this post is to identify key considerations that must be addressed to successfully build a secure IoT Gateway. It is a complicated process with issues not limited to traffic management, threat identification at line speeds and the potential for complex policy and usage configurations. As daunting as this may appear, traditional appliance manufacturers have been addressing this need for Information Technology ecosystem for many years and bringing that technology to the Operational landscape is fairly straightforward. Part 4 of this series will push the edge of what is possible by walking through some theoretical configurations that bring Threat Intelligence down from the network appliance to the actual edge device.

David Dufour

About the Author

David Dufour

Vice President, Engineering

David Dufour is the Vice President of Engineering at Webroot. He has 25+ years of experience in systems integration and software engineering focusing on large-scale, high-performance, high-availability integration solutions.

Facebook Comments
Share This