Unpacking IoT (Internet of Things), a Series

The complexity challenge and what you can do about it.

By Tim Szigeti, Cisco / December 23, 2019
Shutterstock/Jakub Krechowicz

The complexity challenge and what you can do about it

In my previous two blog posts, I explained how Cisco addresses the security and scalability challenges associated with an Internet of Things (IoT) deployment. In this post, I cover the final of the top three challenges: complexity. For an IoT initiative to be successful, the deployment and management of connected devices must be simplified.

The typical solution to address scalability is automation. Automation certainly helps expedite and scale out an IoT deployment, but it’s not enough. If you cut and paste, and deploy text-based device configurations, that will help speed up configuration, but it won’t simplify deployments. A network administrator still has to come up with an appropriate network configuration to meet the business needs, perform extensive testing and validation of these configurations on a platform-by-platform and software-image by software-image basis, and, finally, templatize these configurations to support device-specific variables (like device names, discrete interface IP addresses, location details, etc.). So, how do we make this entire process easier beyond just automation?

To simplify IoT deployments, Cisco has made a paradigm shift in terms of how we empower network operators to program network devices. This new approach is called intent-based networking. To realize the impact of this new way of thinking, you need to understand that there are essentially two main ways to “program”— that is, to provide a set of instructions. One way is called the imperative model and the other is called the declarative model. Any programmable thing — whether it’s a computer or a person being given instructions — can be programmed using one of these models. The best way to explain the difference between the two models is to use a simple analogy.

Imagine you’re taking a taxicab to the airport. One way you can ensure you get to your destination is by providing the driver with explicit turn-by-turn directions: turn left at the first signal, go down three blocks, turn right on Main Street, etc. You break everything down into discrete, very easy-to-follow directions, but they’re very complex. This approach illustrates the imperative model of programming, where every instruction needs to be provided in detail. Additionally, it should be noted that the imperative approach may even be sub-optimal and inflexible. For example, what if a particular street was closed for repairs and you didn’t know how to detour around the affected area?

An alternative approach, the declarative model, is to leverage the knowledge of the taxi driver and simply declare your intent: take me to the airport. You don’t need to explain how to get there or which route to take. You just express your intent — the business result that you want to achieve — and then rely on the driver to deliver on that intent. This is the paradigm shift we made at Cisco and what intent-based networking is all about.

Intent-based networking for IoT

Cisco DNA Center is the equivalent of that cab driver who knows how to get you from point A to point B without detailed instructions. We’ve embedded 30 years of networking knowledge into our solutions, enabling network operators to express their intent at the business level. For example, in the case of network security policies, a network operator can indicate these devices can talk to those devices. These people can access those applications. That’s business-level intent. There’s no need to specify all the rules of how that intent is delivered, which technology is utilized, what kind of access policy is applied, where it’s deployed, etc. The network operator allows the machine to translate that and then to scale that configuration using automation to the programmable physical and virtual network infrastructures.

But that’s not all. We close the loop by soliciting telemetry data from the infrastructure to confirm that indeed the stated intent was delivered. The system compares the data from the network with what was declared by the operator to make sure that the business intent is being delivered. Either it is, and you have confirmation and data to that effect. Or, it’s not, and that’s very important to know because then you can launch a troubleshooting workflow to investigate the root cause and take remedial action.

Intent-based networking is not new. We’ve been doing it within our data center with our application-centric infrastructure for quite a few years now, and more recently in the past five years we’ve been doing it in our enterprise networking. The expression of that is Cisco DNA Center.

What’s important now is that we’ve extended intent-based networking capabilities to the IoT edge. All IoT switches, routers, and wireless access points that run Cisco IOS XE can be managed by the same pane of glass you use to manage the rest of your network via DNA Center. Furthermore, you can extend the enterprise network to your IoT edge — wherever that happens to be: your parking lots, warehouses, distribution centers, manufacturing facilities, airports, seaports, utilities, power grids, etc. All of these places can be extended to using the same toolset.

The result: one intent-based network architecture for a consistent end-to-end experience and one set of security policies. IoT deployment is simplified, but it’s also scalable and secure.

The security challenge and what you can do about it

Network engineers face a number of challenges when deploying Internet of Things (IoT) initiatives. Come back to the Cisco IoT blog over the next few weeks as we dive into the top three IoT challenges, and best practices for conquering them. First up, the biggest challenge in IoT by a long shot: security.

IoT security threats differ significantly from security threats in traditional IT environments: in traditional IT, security concerns are focused first and foremost on protecting data. Attackers can steal data, compromise data, and hold it to ransom. Recently, they are just as interested in stealing compute power for malicious cryptomining activities.

While these security concerns exist in IoT, they also go further, extending beyond the data and into the physical world. At minimum, an IoT security incident can inconvenience people or interrupt operations, causing millions of dollars of damage within a few short hours. At worst, these attacks can damage systems that control a physical process and even put lives at risk. Consider the following examples:


  • The infamous Stuxnet attack in 2010 leveraged multiple zero-day flaws in Microsoft Windows software. The objective was to detect and corrupt PLCs running Siemen’s Step7 software so as to reprogram these with malware to cause the fast-spinning nuclear centrifuges under their control to literally tear themselves apart. The end result of this attack saw one-fifth of Iran’s nuclear centrifuges destroyed.
  • We saw the first successful cyberattack on a power grid in 2015 when cyberattackers gained control of multiple Ukrainian power stations, resulting in the loss of electricity to over 225,000 residents for periods of up to six hours. This complex and multi-phased attack not only gained control of SCADA systems, allowing foreign actors to remotely switch off substations, but also included a DoS attack on the call center so that consumers were unable to call in to report issues or to receive updates of the status of the blackout.
  • In 2017, an attacker deployed ICS malware, dubbed Triton, designed to manipulate industrial safety systems so as to cause operational disruption of critical infrastructure. The attacker’s specific targeting of the Safety Instrumented Systems (SIS) suggests an interest in causing a high-impact attack with physical consequences (an attack objective not typically seen from cybercrime groups). Analysis of the incident lead the investigators to believe this was the work of a nation-state preparing for a broader attack.
  • In 2019, a ransomware attack on Norsk Hydro, one of the world’s largest manufacturers of aluminum, forced the company to switch to manual operations in a bid to contain the breach. The attack cost the company $52 million and resulted in a worldwide increase of the price of aluminum.


These incidents show how critical — and challenging — security can be in IoT scenarios.

Preventing and Containing IoT Security Threats

In the examples above, security breaches could have been prevented entirely — or, at the least, significantly contained — using a network security best practice: segmentation. Segmentation is one of the most effective network design principles to deploy for security. It’s a universally accepted networking axiom — but, if so, why don’t organizations fully segment their networks?

The answer: it’s complicated.

To reduce costs, organizations have converged their data, voice, and video networks onto a shared physical infrastructure. More recently, IoT devices have also been added to the same IP network. However, it’s necessary to maintain logical separation between these services for security and management purposes. To do so, network engineers typically segment the network using VLANs. This process requires multiple steps, touchpoints, policies, and user interfaces. At a high level, network engineers must create groups in Active Directory, define policies, execute VLANs/subnets, and implement the policy.

The complex nature of segmentation not only makes the task a tedious one, it also increases the risk of human error. For example, access control lists (ACLs) on network devices are often tens of thousands of lines long. They are difficult to manage and understand due to poorly documented reasons for each line in the entry. If there’s one discrepancy for ACLs from one device to another, there’s a potential vulnerability and an attack vector that can be exploited.

Bringing Cisco Security to IoT

Given the key role network segmentation plays in protecting network assets, it’s critical that network administrators can segment the network efficiently and effectively. At Cisco, we simplify segmentation by applying intent-based networking to the enterprise network. This specific expression of intent-based networking is called Software-Defined Access (SDA).

Software-Defined Access eliminates the need for network administrators to speak the language of access control lists or group policies in order to identify which network devices can talk to each other. With a few simple clicks and drag-and-drops of the mouse, network administrators can establish separate virtual networks for voice, data, guest access wireless, BYOD, IoT, and more. This year, we extended these capabilities all the way to the IoT edge — so that parking lots, distribution centers, manufacturing facilities, airports, seaports, etc., can all be managed from the same single pane of glass as the carpeted enterprise, namely Cisco DNA Center.

Using Cisco DNA Center, a centralized management dashboard, network administrators can provision networks across the enterprise and ensure that devices assigned to one virtual network can’t talk to the devices on another virtual network. In fact, the devices on one virtual network can’t even see the other virtual networks. As far as they’re concerned, the virtual network they are connected to is the one and only network that exists or that has ever existed. That means IoT devices assigned to an IoT virtual network can only communicate with other devices assigned to the same virtual network and nothing (and no one) else. Such logical separation is called macro-segmentation.

However, SDA offers an even more granular policy option to network administrators.

In macro segmentation, any device within a virtual network can by default talk to any other device in that same virtual network. So, if video cameras, temperature sensors, and badge readers are all assigned to a single “IoT Virtual Network,” these devices — by default — would be able to communicate with each other. Such communication can present a security issue — if a single device is compromised, attackers will use that device to scan the network for other devices that may provide a further foothold into the organization (watch how this is done). That’s where micro-segmentation comes in.


In Cisco DNA Center, network administrators can easily create micro-segmentation policies that define which devices can speak to other devices within the same virtual network (watch the demo, Cisco Extended Enterprise with DNA-C). Administrators can also configure the policy to send an alert if those devices attempt to communicate with unauthorized devices, which could be indicative of a potential security attack. In our example above, video cameras can be configured to speak only to other video cameras, and if they try to speak to the temperature sensors or badge readers, an alert will be issued.

The ability to segment the network on both a macro and micro level with SDA is a great solution to both preventing and containing a security breach. It easily scales to address the needs of the enterprise network, and now Cisco customers can apply these same concepts to their IoT networks. Furthermore, they can do so efficiently and effectively using the same management interface they use for the enterprise network. Want to learn more? Check out our on-demand webinar, Cisco IoT: Drive Transformation in the Public Safety, Oil and Gas, and Manufacturing Sectors. And don’t forget to check back on the Cisco IoT blog for the other top challenges facing enterprise IoT.

The scalability challenge and what you can do about it

The Internet of Things (IoT) presents a number of challenges for network engineers. In my previous post, I explained how Cisco is helping to address the biggest IoT challenge by far: security. In this post, we’ll cover the next challenge: scalability.

As shown in the figure below, tens of billions of devices are coming online within the next few years, which presents tremendous IoT scalability concerns.

How can organizations possibly scale security and network policies to address all of these devices? If we have to configure IoT devices the way we’ve configured network devices for the last couple decades, then we won’t be able to meet the scalability requirements that IoT is driving. The “traditional” way — manual, box-by-box configuration — is slow and prone to errors. The answer? Automation. Deploying policies at scale using automation speeds up provisioning and makes software management far easier. This can be achieved with software-defined access.

Under the hood: Scaling IoT in Cisco DNA Center

Allow me to explain. Let’s say you want to apply a network policy to your IoT devices. All of the IoT devices must be on their own VLAN, separate from the rest of the devices on the network. The objective being to prevent an attacker from using an IoT device as a toehold into the rest of the enterprise network.

With Cisco DNA Center, adding a new virtual network is as simple as naming the network and selecting which groups of users, devices, and/or applications should be on it. These are represented as Scalable Groups. The network operator selects each of the groups that belong on the new virtual network by simply dragging and dropping the appropriate icons from the left to the right side of the screen and clicking “save.” With just a few clicks, IoT devices are effectively segmented so that they can only communicate with the other devices as specified in the virtual network. There’s no need to assign VLANs and DHCP scopes, program ACLs, etc. — as a network operator, you don’t have to speak the language of networking policies and access control lists to nearly instantly create your network.

The Scalable Group Tag (SGT) is what makes this process so easy. A Scalable Group is a logical policy object to “group” users and/or devices. The SGT identifies anything that you want to apply a policy to: endpoints, users, or applications. SGTs are used to manage IP address-independent “Group Based Policies.” That means policies are applied to the Scalable Group, instead of individual IP addresses. In the past, network operators would often apply policies to device IP addresses because they are ubiquitous, end-to-end and consistent, but that approach gets messy. By applying policies primarily to the SGT, in addition to the segmentation of the virtual networks, you can be scalable, effective, and flexible in policy expressions on software-defined access networks for IoT.

The process above is the same process used to manage devices on the enterprise network. IoT devices, however, don’t typically have all the higher capabilities and compute resources as, say, switches in a data center. They’re typically lighter in weight and have a smaller form factor, lower power draw, and smaller hardware capabilities.

In order to play in this software-defined world, we need to adapt and reconcile these two constraints: one of providing segmentation and policy, the other of allowing the hardware to remain as lightweight as possible. This is where Cisco Software Defined Access Extended Nodes come in. Here’s how they work:


  • Extended node connects to a single Edge node using an 802.1Q Trunk port (single or multiple VLANs) using static assignment
  • Switchports on the Extended node can then be statically assigned to an appropriate IP Pool in Cisco DNA Center
  • SGT mapping is accomplished by Pool to Group mapping in Cisco DNA Center on the connected Edge node
  • Traffic policy enforcement based on Scalable Group ACLs is performed at the Edge node


Scaling enterprise networks was hard enough when network operators had to manually configure individual boxes. It’s downright near impossible with IoT. Fortunately, Cisco has solved this challenge in enterprise networks using software defined access and automation. And now those same solutions can be applied to IoT. With Cisco as your partner, you can scale efficiently and effectively using the same management interface you use for the enterprise network.

Want to learn more? Check out our on-demand webinar, Cisco IoT: Drive Transformation in the Public Safety, Oil and Gas, and Manufacturing Sectors.

This content is made possible by our sponsor; it is not written by and does not necessarily reflect the views of e.Republic’s editorial staff.

Platforms & Programs