Supporting (& paying for) the network segments that support IoT Systems

Network segmentation is often promoted as the answer to IoT device and systems management and risk mitigation for an institution, city, or corporation. While segmenting networks is important, a subtle problematic aspect is that:

  1. segmenting networks takes work, energy, and resources in the form of initial investment and ongoing management and oversight
  2. numbers of network segments growth may well track with IoT device count growth – which, at least for the next few years, appears exponential
  3. cities and institutions may not be planning for increased network management resources to support IoT Systems deployments

Success criteria for an IoT System implementation

I use a two overarching component criteria to define a successful IoT System implementation for a city or institution —

1. ROI – does the system perform as expected for the actual (vs projected) costs of deployment and subsequent management

2. Cyber risk – did the implementation of the IoT System make the city or institution worse off in the course of deploying and operating the system?

A key aspect to both of these criteria is system manageability. An unmanageable or difficult to manage system costs more in terms of staffing, rework, repair/updating, and operational disruption. At the same time, a difficult to manage system can create cybersecurity vulnerabilities — both seen and unseen — and divert limited institutional resources from existing operational, cybersecurity and risk mitigation activities.

Similarly, as IoT Systems need to be manageable to positively (at least not negatively) affect ROI and institutional risk profile, the network segments supporting IoT Systems also need to be manageable.

Managing the network segments that support IoT Systems

Networks are no longer, “make this thing talk to that thing,” or “make these things talk to those things.” Network management requires a robust set of supporting system services that support consistent connectivity, resilience, real-time health reporting capabilities, and rapid network diagnostic capabilities.

In addition to these core network support services, for IoT Systems deployments, there is another overarching criteria needed to successfully support and manage networks that support IoT Systems —

The IoT System owner should be able to measure, monitor, and determine performance of the IoT System(s) at any particular point in time. This supports both the effort of determining ROI as well as providing visibility for cyber risk mitigation.

In the case of a city, the IoT System owner might be the city’s transportation department while the network provision is provided by or contracted through the city’s central IT organization. In the case of an institution, such as a research university, the IoT System owner might be an academic department purchasing and deploying an IoT System to support a research grant while the underlying supporting network segment is supported by the university’s central IT organization.

The IoT System owner should not be relying on the network provider to provide IoT application/system management and diagnostic services. IoT Systems are evolving so rapidly, it is very unrealistic to expect the network services provider to have the resources or wherewithal to keep up with the nuances of each new IoT System deployment, much less manage the performance expectations for a rapidly growing number of different IoT Systems.

Examples of IoT System/application-specific network services include:

  • enumeration – how many things/devices are on this network?
    • Is this count different from yesterday? By how much?
  • identification – how many of these devices belong to my IoT System? Have I seen them before? Yesterday? a month ago? How rapidly is this changing?
    • Is what I am seeing different from what I was expecting?
      • (Did I know what I was expecting?)
  • Application-specific network device awareness and health
    • Device heartbeat – are you there?
    • Device performance specifics –
      • Is device characteristic 1 returning a result within acceptable constraints? e.g. voltage level
      • Is device characteristic 2 returning a result within acceptable constraints? e.g. device temperature,outside air temperature (OAT)
      • Is device characteristic 3 returning a result within acceptable constraints? e.g. response time
      • Is device characteristic n returning a result within acceptable constraints?

Accomplishing these requirements is not free. Some technology investment is needed, but more importantly, an organizational framework that supports this activity is necessary.

Growth of devices & growth of network segments

While we don’t know what the rate of growth of network segments is or will be, we can be pretty sure that it will continue to grow for the foreseeable future. This growth in network segments stems from at least two reasons, 1) network segments whether VRF’s, VLAN’s or other are easier to implement than they used to be, and 2) network segmentation is currently a popular strategy for addressing IoT Systems risk mitigation. (Regarding the latter, I believe that this is in part because we don’t know what else to do — when all you have is a hammer, everything looks like a nail).

There are multiple projections that IoT device count is growing at an exponential rate, such as this Ericsson Mobility Report that suggests a 23% annual rate of growth between 2015 and 2021 and this McKinsey report that suggests 15% – 20% annual growth by 2020. Related projections on IoT market growth can be even higher with annual growth over of 50%.

This ongoing steady (or more) growth year after year appears to be exponential growth. While IoT devices don’t compound each other like dollars do, the growth count curve still appears exponential. To borrow from the idea of compounding (exponential) growth in finance — we add 1 to the rate of growth and raise that sum to the number of years out that we want to project and then multiple that whole thing by the starting count —

(Wikipedia)

So, let’s say that we start with 10,000 IoT devices in a hypothetical city or institution and that the growth rate in IoT device count over the next few years is 20% . That growth curve looks something like this —

exponential device count growth @ 20%

(As a quick side note, we can see the Rule of 72 providing a rough estimate of the time it takes to double, about 3 1/2 years, at work here).

Now let’s say that there are currently 1000 network segments (VLANs, VRFs, etc) in that city or institution and consider two hypothetical growth trajectories — one exponential at the same rate as the device count growth rate and one linear growing at 1000 network segments per year.

Hypothetical exponential growth at 20% and hypothetical linear growth at 1000 segments per year

While don’t know exactly what the network segment growth rate or trajectory will be for cities and institutions in particular or in aggregate, we can expect that count to continue to grow for the next several years. With that growth comes an increased demand on institutional and city resources. The question is, are we planning to resource that increase in demand?

Network segmentation management — impacts on ROI & institutional cyber risk

As mentioned earlier, to manage network segments for successful IoT systems implementations, at least two components are required — manageability of the network segment itself and manageability of the specific IoT System(s) on that network. Without both of these, the likelihood of an IoT System’s success for the city or institution is low. Without both of these, the city or institution can expect to feel negative impacts to ROI, the city or institution’s cyber risk profile, or more likely both.

Because both of these success components require current resourcing (eg staffing and tool investment) and planning for future resourcing, success is not guaranteed. If we’re not thoughtful about implementation, we could end up with broad portfolios of a rapidly growing number of unmanaged or under-managed networks. And that’s not good for any of us.

 

Leave a Reply

Your email address will not be published. Required fields are marked *