Need for a re-evaluation of the Security model with IOT

-              Is a singular model for Enterprise IT+ OT possible?

Internet of Things (IoT) as the next wave of technology disruption first came into the limelight  at the  2009 Intel Developer Forum as the “continuum of computing” from PCs, tablets, smart phones to other devices or “things” that were to be connected to the internet. Indeed, IoT is now well past its peak of inflated expectations reached in 2011 (Gartner Hype curve) and many claim this wave will be as profound as the internet itself.

Gartner, forecasts that 6.4 billion connected things will be in use worldwide in 2016, up 30 percent from 2015, and will reach 20.8 billion by 2020. In addition nearly $6 trillion will be spent on IoT solutions over the next five years!  

However, we have challenges ahead of us.  It is acknowledged by most technology pundits and CIOs that Security is by far the #1 impediment to mass scale adoption of IOT solutions and will gate the lofty projections cited by Gartner and others.

To address this challenge, the security model for enterprises needs a re-evaluation with a holistic view of both IT+OT as the total protection boundary.

Given this requirement -- is there a singular and unified architectural approach to deploying a next-generation security system?  Or should we treat IT and OT as fundamentally different landscapes with their own architectures but build “secure integration bridges” between them? 

To answer this question, we need to address multiple dimensions of the IOT security challenge. Most significant here is that a number of the foundational security architectures that have matured in enterprise IT over the past two decades just do not fit well into the OT landscape. In addition, the lines of decision making between the operations groups managing OT (eg. Industrial controls) versus the IT/CIO function have historically been independent of each other. This results in a lack of an “end-to-end” blue print for security and potentially opening a backdoor for breaches from the OT environment inside the IT infrastructure.  

So how different is the IOT environment from IT?  There are five factors that stand out:

1.     Visibility (lack of) of IOT devices on the network - 50% of the security operations personnel surveyed (Forescout 2016 survey) expressed they had “little to no confidence” that they were aware of ALL the IOT devices on their network.  This is a serious problem as any breach from one of these compromised devices can have no trace-path as it is invisible to the security administrator.  This is reminiscent of the first time we had an extensive enterprise-wide security attack over the internet in 2001 with Code Red & Nimda viruses in rapid succession.  It took us two weeks, with a brutal 24x7 schedule to physically account for ALL servers (we did not have a central asset management system back then) at a large multi-site IT infrastructure. This nerve-racking intervention required us to take them offline and patch them individually. A scenario like this in the OT environment has the potential to be 10x worse given the sheer scale, heterogeneity and lack of visibility that could take months to root cause the breach and remediate.  

2.         Machine to Machine (M2M) connected network – IOT devices in general have very long persistent sessions once they are authenticated into the network. This is in contrast to traditional IT infrastructure components which have a high element of human – machine interaction and the sessions are short lived. The persistent nature of the M2M session at scale (1000’s of devices) and heterogeneity (many different models, some with no in-built security) offer multiple attack surfaces and a perfect source for an exploit that can go unnoticed for a long time.

3.    Traditional Enterprise security models do not scale and will not fit – Identity “measurement” (example: x86 based platform trusted boot) and authentication mechanisms using a centralized Public Key infrastructure & certificate of authority (CA) for binding identities are ill-suited for deployment in OT environments. Many of these sensors run on 8/16/32bit CPUs with limited RAM and battery power and don’t have the ability to support a trusted boot model (at least in current times). Moreover, given the distributed and at-scale nature of the OT network we need a distributed “PKI” equivalent model enabled as a network service (versus a central instance).

4.         Lack of communication standards – The Enterprise has moved to an IP world and this enables the formulation of a scalable and rich fabric of communication and data services on this protocol stack. The OT world by comparison is the “wild west” and by last count had 15+ communication protocols (& growing). This poses a significant challenge to both interoperability & integration services that are needed for a singular SIEM system that can bring IT+OT under the same management and orchestration environment. 

5.         Legacy – Yes there are a ton of IOT devices (before the word IOT was coined!) especially in industrial control systems (manufacturing, oil & gas, utilities/power generation etc). A majority of these devices have been installed in the 70’s and 80’s, have no intrusion detection or prevention systems and are expected to be around for a long time. Security has been managed through “moats” and proprietary management environments. These customers do not want any agents or software installed on these systems for fear of introducing risk and a new variability. Any new IOT system therefore has to encapsulate the legacy infrastructure to create one unified framework.  This has to be accomplished while ensuring flexibility of security zones that are needed to protect individual environments from each other. 

Given these key challenges, we will need to temper our assumptions on how fast the B2B environment will adopt IOT. The progression will certainly start with green field environments (smart homes, connected cars for example) but the uphill task for a majority of the Industry running today’s infrastructures will be to overcome the constraints discussed earlier. More on how to overcome these constraints and build viable solutions in my next blog. 

Prasad