Monthly Archives

April 2020

Securing the IoT Edge (Part 2)

By Blog, Project EVE

Written by Jason Shepherd, LF Edge member, VP of Ecosystem for Zededa and active leader in Project EVE

This post originally ran on the Zededa Medium blog. Click here for more articles like this one. 

The computing landscape has long observed a swing between centralized and distributed architectures, from the mainframe to client-server to the cloud. The next generation of computing is now upon us, representing both a return to the familiar distributed model and a breakthrough in rethinking how we handle data. Many of the security lessons we’ve learned from past paradigms are applicable, yet the edge also brings unique challenges. In part 1 of this blog series, we covered some of the characteristics that make security different at the edge compared to the cloud. In this blog, we’ll be going over ten baseline recommendations for securing IoT edge deployments.

Coined by former Forrester analyst John Kindervag, the “zero trust” mindset is rooted in the assumption that the network is hostile. This means that every individual or device — inside or outside of the network perimeter — trying to access the network must be authenticated and all downloaded updates verified, because nothing can be trusted.

Key principles of zero trust security

At the foundation of your security approach should be a trust anchor in your edge devices based on a root of trust at the silicon level (e.g., Trusted Platform Module, or TPM). Due to fragmentation in edge hardware, as much support as possible for this trust anchor should be abstracted into the software layer and exposed to your applications through APIs. This trust anchor should be the foundation for key functions such as device identification and authentication, secure and measured boot, encryption, application updates, and so forth.

 The massive distributed denial of service (DDoS) attack that leveraged the Mirai botnet and took down a portion of the internet in 2016 involved millions of cameras that shared a very small number of common credentials. Back during the setup of these devices, their credentials either could not be changed or were not changed because it was easier to use the factory default. What can we take away from this incident? Rather than relying on field technicians or end users to change and manage countless edge device passwords, leverage solutions that automatically create and store credentials in the trust anchor based on a unique device ID during a zero-touch provisioning process. Field technicians should then only be able to access the device through a central controller. Additionally, establish the ability to set policies in your network that allow you to remotely disable any unused physical ports on edge devices in order to prevent unauthorized installation of software.

 Leveraging the key provided by your trust anchor, encrypt data both at rest on your edge devices and in motion across the network. Deploy compute immediately upstream of resource-constrained edge devices and legacy systems to encrypt data when they aren’t capable of doing it themselves.

With a growing number of devices at the periphery of your network, it’s more important than ever that you have full visibility into user activity, device location and status, and the routes your data is traveling between devices and your on-prem and cloud systems. Be sure to regularly review role-based access to make sure only the users who need access have it, and that this access is based on real-time context as part of your zero-trust strategy.

Network flow log in ZEDEDA’s controller

The U.S. Department of Homeland Security estimates that as many as 85 percent of targeted attacks are preventable due to exploitation of unpatched software. These updates need to be signed from a trusted authority and verified by the private keys stored in your edge devices. Given the implications of downtime in an operational technology (OT) environment, it’s important to enable the scheduling of vulnerability updates during maintenance windows. Also key is to have rollback capabilities in the event of failed updates, so that devices aren’t bricked in the field, which can take down a mission-critical process or result in an expensive trip to a remote location. Software should have extended support, offering the ability to patch applications and underlying runtime for 5 to 7 (or more) years.

Consider solutions that leverage machine learning to assess the steady state of your deployments and alert for anomalies, whether it be unusual network activity, signs of malware, or other indicators. For example, had active threat analytics been applied at the edge in the 2016 Mirai attack, the unusual network traffic could have been addressed at the source rather than snowballing into a much bigger problem. Consult with experts that understand the unique needs of OT-specific protocols — this includes defining what normal behaviors are and how to gracefully shut down processes in the case of any detected attack.

 It takes a village to develop and deploy IoT and edge computing solutions, with multiple different parties coming together spanning the necessary technologies and domain expertise. It’s key to invest in tools for securing and managing your infrastructure that are consistent regardless of the applications and domain expertise applied on top. Leveraging purpose-built, open edge orchestration frameworks that support cloud-native development and have clearly-defined APIs provides a transparent mechanism for getting all stakeholders on the same page, regardless of the combination of ingredients used in a given deployment.

It’s important to strike a balance between locking a solution down and making it usable across the various stakeholders involved. Many of the breaches we hear of in the consumer space happen because developers prioritized instant gratification and usability over security. This is where capabilities such as zero-touch provisioning are key, eliminating the need for expertise and awareness to securely onboard devices.

Security is about defense in depth, applying the right tools in layers based on security posture and risk. This includes utilizing segmentation when possible — while a zero-trust mindset eliminates a perimeter-based focus, micro-segmentation is still important to isolate critical networks and devices, especially legacy systems.Further augment your zero trust model with distributed firewall software to govern access across nodes on internal networks.

Not all edges are created equally; for organizations looking to implement edge computing, it’s important to first understand the unique challenges of securing and managing computing located outside of the confines of a traditional data center. However, adopting a distributed model for compute efficiency doesn’t need to bring tradeoffs in security. Being aware of the considerations that exist at the edge will help organizations be better equipped to protect field deployments and reap the benefits of edge computing. At ZEDEDA, we build off of a foundation that considers all the points above to enable enterprises to securely orchestrate IoT edge deployments with their preferred devices, applications and clouds.

Zededa is a LF Edge member and active leader in Project EVE. For more details about LF Edge members, visit here. For more details about Project EVE, visit the project page

Securing the IoT Edge (Part 1)

By Blog, Project EVE

Written by Jason Shepherd, LF Edge member, VP of Ecosystem for Zededa and active leader in Project EVE

This post originally ran on the Zededa Medium blog. Click here for more articles like this one. 

IoT adoption by the enterprise is on the rise. Yet despite interest in the space accelerating, organizations of varying sizes and verticals have run into several roadblocks in implementation. Previously, we discussed why IoT needs edge computing to realize its full potential. In this two-part blog series, we will review the unique security implications of a distributed edge and how organizations can secure the edge.

Over time, software-defined edge computing is only expected to become more sophisticated and we will begin processing more and more critical information in distributed locations. Many edge computing systems host their own web servers for remote maintenance and logins, making them a prime target as attack surfaces, especially for bad actors who could input or extract data and disrupt an entire ecosystem from a single unsecured system. Users need solutions to deliver new applications to the edge that drive efficient business outcomes while also maintaining an appropriate security posture.

Not all edge locations are created equally when it comes to security. Practices for securing deployments at the cloud edge and within secured telecommunications infrastructure (e.g., cell tower facilities), modular data centers, etc., tend to be quite similar to traditional data centers. Meanwhile, as edge deployments get closer to the physical world — in locations such as the factory floor, inside wind turbines, on trucks, or within rooftop HVAC systems, to name a few — unique security challenges are introduced. As we dive into what this entails, let’s take a look at what makes security for the distributed edge unique.

Scale: Part of IoT’s value stems from having numerous devices connected in order to understand the holistic picture of your operations. Over time, we will see device deployments scale to the trillions, which is numerous orders of magnitude larger than the volume of deployments in centralized locations. This translates into an unwieldy number of distributed edge assets that an organization must secure and manage. Solutions oriented towards securing and managing datacenter infrastructure typically aren’t set up for this kind of scale, which is why we can’t simply copy/paste them to solve the problem.

Lack of physical and network perimeters: Another key challenge for securing distributed edges is that there are often no physical (e.g., the four walls of a secure data center) or network perimeters. In operations out in the field, it is very common to rely on a backhaul network and parameters (such as NATs and proxies) that are owned or managed by someone else when not practical to create your own network (e.g., cellular backhaul). In general, solutions should not rely on having an owned network or firewall to protect them.

Heterogeneity: The IoT edge is inherently heterogeneous, comprised of a variety of technologies including sensors, communication protocols, hardware types, operating systems, control systems, networks, and so forth. Skill sets spanning IT and OT (e.g., network and security admins, DevOps, production, quality and maintenance engineers, data scientists, etc.) are necessary to realize IoT as a convergence of the physical and digital. Security solutions need to accommodate a wide variety of technologies and skill sets in order to be effective.

Varying priorities: In the IT world, it is typically acceptable to immediately shut down access to the network to isolate an affected system in the event of a security breach. Meanwhile, the impact due to information loss (e.g., credit card data or IP) plays out over a long period of time. In contrast, in the OT world, a security compromise can lead to immediate loss of production and risk to safety, so any issues need to be addressed gracefully. As such, your security solution needs to recognize these different priorities and strike a balance.

Constrained devices: Many IoT sensors and devices are too constrained resource-wise to employ security measures such as encryption. The same goes for legacy systems that were never intended to be connected to broader networks, let alone the internet. In order to protect these devices, we must rely on more capable compute immediately upstream to serve as the first line of defense, providing functions such as root of trust and encryption.

As we seek to reap the benefits of edge computing, we must realize the nuances it requires of our security approach. It can’t be the same as what we’re used to in data centers; instead, we must consider the edge’s characteristics to bolster a distinct approach. In part two of this series, we will share a foundational strategy for securing IoT edge deployments.

Zededa is a LF Edge member and active leader in Project EVE. For more details about LF Edge members, visit here. For more details about Project EVE, visit the project page