In October 2016, my column discussed the impact of Moore’s Law and Metcalfe’s Law on the internet of things, basically stating that IoT is in your future because the Law says so. For decades now, Moore’s Law has accurately predicted the steadily rising roadmap of new and more powerful devices, which has essentially been borne out by all the new sensors, devices and things that power IoT. Metcalfe’s Law predicted that the value of a network can be linked to the number of connections within that network — it directly relates to the value of context and data generated by things, devices, data and apps within an IoT-powered solution. However, are there negatives associated with the impact of Moore’s Law and Metcalfe’s Law on IoT? Do these negatives outweigh the positives? Yes. More connections represent the potential to collect new types of data, correlate data sets that were difficult to compare before and optimize user and device experiences with a myriad of contextual information.
Conversely, do these new connections, devices and things also represent a broader and more attractive attack surface that is harder to contain and secure? Unfortunately, we have already seen the potential for this broader attack surface unleashed in a barrage of unprecedented distributed denial-of-service (DDoS) attacks where the devices used in the attack were categorized as compromised IoT devices. These attacks served notice that unprotected IoT devices can cause major disruptions to the underlying infrastructure of the internet, and have many questioning if the security risks for the internet of things offset the benefits.
There is no question in my mind that a larger number of smaller, portable and more powerful devices combined with making it easier for things, apps, data and services to communicate with each other increases the security risk potential. This trend is similar in many ways to how the BYOD explosion increased the number and type of security risks an organization faced. With BYOD, more devices connecting from beyond the traditional network perimeter required an evolving approach to security, and with the internet of things, the security approach must also evolve. But how? This evolving IoT security paradigm is comprised of many elements, some which we have not even thought of, and the approach will need to vary depending on the IoT use case. Protecting IoT devices in use on a corporate network will be very different scenario than protecting your public web site. To capture some general elements of what an IoT security strategy should evolve to look like, I sat down with one of my colleagues — Jeffrey Sanderson, senior director, delivery networks at Citrix, and asked him his opinion on how IoT security will evolve in the enterprise. Here’s a look at our Q&A:
Securing IoT: The evolving security perimeter
Chris: Jeff, as the recent DDoS attacks leveraging compromised IoT devices has shown, the internet of things has the potential to increase the attack surface for businesses. From this perspective, how should an organization evolve or change its security strategy with IoT in mind?
Jeff: Firstly, defining an effective security perimeter greatly minimizes the risks of a malicious attack. We all should be very clear on that. If we consider the evolution of web-based services, where originally secure SSL sessions would natively terminate directly on the web applications — meaning the applications themselves would handle authentication, authorization and session decryption — this effectively shunted that perimeter directly into the application domain. We saw the role of traditional application delivery controllers (ADC) and firewalls adapt to bring greater efficiencies and enhanced protection. Effectively, it provided a security perimeter one step away from the “sensitive” application layers and enabled the ADC/firewall to become the ultimate arbiter for what sessions make it through to the application. This configuration allowed for finer granularity in application access as well as detecting and preventing malicious attacks.
Chris: This makes sense. I remember when organizations really started to open their network for remote workers this idea of shrinking your perimeter to the application itself really started to take off. Basically, a “trust no one, secure your communications and de-perimeterize your network” approach. With IoT, how does this approach change?
Jeff: The same evolution is in play. The exception here is that IoT has introduced some new components to contend with, and these new components offer new roles to play in your overall security strategy. One example that I want to focus on is the IoT message broker. The IoT message broker is important to IoT because much of what makes up an IoT solution is the communication and chatter that exists between all of the sensors, devices, things and applications, and this broker is what helps to manage the sending and receiving of messages to all of these different IoT solution components. Generally, the IoT message broker sits in a layer in front of the applications/cloud services and, because it sits here in front of the applications, many organizations are choosing to also use these brokers to provide the security perimeter (terminating SSL, handling authentication, etc.). Let’s be perfectly clear here though — these broker solutions were not designed to be a security perimeter. Pushing such capabilities onto them is simply a “convenience of architecture” decision in the mad rush to get early IoT services to market. An IoT message broker has enough on its hands doing its day job, and to suggest it is the best place to implement the security perimeter is not practical.
Chris: Are you suggesting something entirely new then to provide this layer of perimeter security in an IoT world?
Jeff: Not necessarily. I believe that the role of the application delivery controller will evolve to provide a security layer that is capable of managing and securing IoT event traffic. This is important because IoT traffic is not like conventional application traffic (web/HTTP for instance). First, we are likely talking a lot more sessions — a whole lot more. Second, IoT sessions are not like traditional web/app sessions. For example, when downloading a webpage there are multiple TCP sessions opened to render that webpage content (text, images, videos, etc.), these last only as long as they are required (opening and closing very quickly). Not so with IoT sessions. IoT sessions can last longer — much longer, hours, days, weeks… The nature of IoT transactions is also quite different. Rather than with the traditional web application model where a client or device initiates the dialogue (let’s call this “client-pull” mode), IoT is very much “push” and “pull” in nature. So it is not just things or devices “pulling” content when they need it, but it may be the applications themselves “pushing” content to things and devices. All this means you can’t simply repurpose an application delivery controller into something that can control and manage IoT events. Enabling your existing ADC with a smattering of new IoT protocols is also not enough. Optimizing the underlying platform architecture to handle IoT workloads is a must, then optimizing how the platform handles security functions like authenticating a much wider range of devices and things so they can exchange information with your applications is also a must.
Securing IoT: Secure the devices? Or secure the applications?
Chris: But what about securing the IoT devices themselves? Should organizations focus more attention on securing the applications and traffic? Or more attention on securing the devices?
Jeff: It is not either/or. Both aspects are incredibly important but both present different challenges. Securing the thing can be as much about physical security as it is network security. What is perfectly clear however is that the thing must be authenticated to connect to the IoT service. As stated above, authenticating devices is the critical first step in gating the thing’s ability to interact with the service. Given the spectrum of types of things this changes the somewhat more controlled scenarios of today’s device connectivity into a much more complex environment and will require a change in thinking for many current approaches.
Chris: So, it sounds like the foundation is there for what you are suggesting, but handling the different types of devices and protocols will require an evolution in current approaches and solutions. For this evolution, how important will analytics be as part of an IoT security strategy?
Jeff: While the security perimeter itself should prevent any malicious attempts to “break in,” if weaknesses are exposed then machine learning should kick in to perform real-time corrective measures to eliminate this exposure. This may be as delicate as changing configurations on-the-fly or as brutal as temporarily decommissioning the service. But let’s be perfectly clear here, initially there will not be a one-size-fits-all solution. Going back to the theme of device versus traffic security we discussed above, there will be limits on the ability to protect the things from direct attacks from the internet. What can be done however is the correlation of analytics from the devices with the analytics from the event delivery control concept we mentioned above. These correlations would allow an analytics/machine learning function to help establish whether there is anomalous behavior at the thing itself, and then prompt corrective measures against compromised things.
Securing IoT: Is enterprise IoT at risk to a DDoS attack?
Chris: OK, let’s bring this back to where we started. The recent DDoS attacks in the news were devices facing the public internet attacking public sites. How much does that type of attack extend to enterprise IoT where many of the devices will be on private networks?
Jeff: The recent attacks should be a wakeup call for anyone considering the deployment of an IoT service. DDoS attacks will remain a chief tool of the bad guys. The only way to lessen the impact potential of this happening to your service is to take the concept of establishing the type of security perimeter discussed above seriously, and I mean very seriously. At the end of the day, nothing is infallible. You can, however, significantly reduce the risk of your service being a target by making it much, much harder to penetrate. If someone manages to expose some flaw, ensure that you can signature that behavior before it becomes a real threat and do something about it fast — ideally without human intervention. Policy creation to automate and manage identity and access, instead of using simple passwords as authentication, will be critical in reducing risk.
Securing IoT: Summary
To wrap up our discussion, it is important to take away that there is not a one-size-fits-all solution, and today many are trying to push too much onto tools not designed for security, like IoT message brokers. And while firewalls and application delivery controllers are tools that can help at the application perimeter, these tools need to evolve to be more focused on IoT-specific events. This evolution includes a greater emphasis on machine learning and analytics to allow for organizations to learn and respond quickly to IoT security threats. The evolution of technology doesn’t have to be a scary thing. We believe that in 2017 we will see an increase in focus on securing IoT, and many new-and-improved solutions for organizations.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.