The deployment of millions of Edge devices means that each of those devices are potential entry points for hackers and security breaches.

Managing the number of devices and their dispersed nature is a security nightmare. Come to think of it, that very scenario has been problematic with the Internet of Things (IoT) approach because of the centralized nature of the solution and cloud-based control systems.

Potential customers are right in asking how the edge is secured. How can an enterprise best guard edge workloads and data against possible attacks? Can a device that has been tampered with be detected and prevented from causing further damage? Is there a way to address rogue edge nodes? Customers want to know if any special precautions need to be taken or if there are new processes to follow when operating at the edge.

In attempting to answer these questions, this blog has become a story of two parts: general description in the first part, with technical underpinnings in the latter. Such is the nature of security in IT.

The nature of an edge solution means that there is rarely a full-stack solution. The solution typically includes software from an IT technology vendor, servers from a hardware vendor, sensors and devices from more than one device manufacturer, and (possibly) the network from a telecommunications company. Naturally, the current thinking of securing IT environments dominated by data centers and cloud-based services has to evolve.

As an example, normally all the devices inside a manufacturing plant are sealed off and live in an air-gapped environment. This has led to very proprietary device management solutions by the manufacturing equipment vendors. Driven by Industry 4.0 and IoT, we needed to open up those environments to deliver more flexibility, making them vulnerable to hackers and security breaches in the process.

Please make sure to check out all the installments in this series of blog posts on edge computing:

• Part 1: “Cloud at the edge”
• Part 2: “Rounding out the edges”
• Part 3: “Architecting at the edge”
• Part 4: “DevOps at the edge”
• Part 5: “Policies at the edge”
• Part 6: “Models Deployed at the edge”
• Part 7: “Security at the edge”
• Part 8: “Analytics at the edge”
• Part 9: “5G at the edge”
• Part 10: “Clusters at the edge”
• Part 11: “Automation at the edge”
• Part 12: “Network slicing at the edge”
• Part 13: “Data at the edge”
• Part 14: “Architectural decisions at the edge”
• Part 15: “GitOps at the edge”
• Part 17: “Storage services at the edge”
• Part 18: “Cloud services at the edge”
• Part 19: “Distributed cloud: Empowerment at the edge”
• Part 20: “Data sovereignty at the edge”
• Part 21: “Solutioning at the edge”
• Part 22: “Connected products at the edge”
• Part 23: “Foundational models at the edge”

Non-functional requirements (NFRs) related to security at the edge

Listed below are some of the non-functional requirements (NFRs) related to security in an edge solution. It is not a comprehensive list, but enterprises are thinking about these:

• The enterprise should have the ability to check whether the edge nodes are operating properly by comparing the current configuration of various resources against the desired state.
• The communication between an edge agent and management hub should be signed and encrypted.
• Each container run on an edge endpoint should be verified against the official container to check for tampering.
• Each container should be running in its own “docker” network with self-regulated (application dependencies) connectivity between the components.
• Each edge agent should check that it is running the latest version of the container when the endpoint is connected to a network.
• The enterprise should create a cryptographic signing key pair and have a plan to rotate them.

The control plane

In IT, the control plane is the part of the software that configures and protects the movement or forwarding of data. What if we have a control plane where each role in the architecture has a limited scope of authority? That way, each role will have only the minimum level of authority needed to complete associated tasks. No single authority can assert control over the entire architecture—that is probably the most important requirement. A user or role cannot gain access to all nodes in the architecture by compromising any single host or software component. That is essentially a decentralized or distributed control plane, which is offered by IBM Edge Application Manager (IEAM).

In an earlier blog post entitled “Policies at the Edge,” we discussed agents, agbots, exchange, and switchboard. We also mentioned the Model Management System (MMS) in “Models Deployed at the Edge.” The first four software entities make up the distributed control plane in IEAM. The agents and agbots are the primary entities and act autonomously to manage the edge nodes. We mentioned an agent runs on each of the managed edge nodes and, more importantly, each agent has authority to manage only that one, single, edge node (device or cluster). At registration time, the agent advertises its public key in the exchange and negotiates with remote agbot processes to manage the local node’s software.

The illustration below depicts the various security artifacts and protocols a solution architect has to think about when laying down an edge solution:

The switchboard, exchange, agbots, and agents

Rather than repeat what has been described in the earlier blog, in this section, the key security features are listed below:

Agent

Key security feature

Local authority—an agent runs on each of the managed edge nodes and has the authority to manage only that one, single edge node.

Within the overall system-wide security for IBM Edge Application Manager (IEAM) for Devices, the agent has no authority beyond the edge node where the agent is running.

What if it is compromised?

A compromised agent does not have any authority to affect any other edge node or any other component of the system.

If the (node) host operating system or the agent process on an edge node is hacked or otherwise compromised, then only that edge node is compromised. All other parts of IEAM for Devices (clusters) system are unaffected.

Agbot

Key security feature

Individual agbot coverage—each agbot is responsible for only the deployment patterns/policies assigned to that agbot. As noted earlier, deployment patterns consist primarily of policies and software service definitions.

What if it is compromised?

A compromised agbot has major implications. It can attempt to propose malicious agreements with edge nodes and deploy a malicious pattern or even remove them.

However, the edge node agents accept agreements for only the deployment patterns requested through registration and match the policies set on the edge node. The agbot has no authority to force any edge node or agent to accept the software that it is offering.

Also, as mentioned earlier, IEAM for Devices uses policies to determine where and when to autonomously deploy services and machine learning models. Policies are an alternative to deployment patterns.

Exchange

Key security feature

Centralized component—a centralized but geographically replicated and load balanced service that enables distributed agents and agbots to join and negotiate agreements.

It also provides a shared database of metadata for users, organizations, edge nodes, and all published services, policies, and deployment patterns.

What if it is compromised?

A compromised exchange can maliciously offer false information to agent and agbot processes, but any impact is minimal due to the verification mechanisms that are built into the system, it operates on signed messages.

The exchange does not possess the credentials that are required to maliciously sign the metadata. A compromised exchange cannot maliciously spoof any user or organization.

Switchboard

Key security feature

Centralized component—mediates and secures all communications between the agents and agbots via a mailbox mechanism. Agents and agbots share their public keys to enable secure and private communication.

What if it is compromised?

Switchboard is incapable of eavesdropping on messages because it lacks the necessary private keys to decrypt the messages.

A corrupted switchboard has no visibility into the communication between participants and is incapable of inserting malicious communications into any conversations between participants.

DOS attacks and asymmetric key cryptography

Centralized services like the exchange and the switchboard are prone to denial of service (DOS) attacks. In the case of IBM Edge Application Manager (IEAM), the distributed and autonomous agent and agbot processes use these centralized services only when the processes must complete discovery, negotiation, and update tasks. Once the agreements are formed, the system can continue to function normally even when those centralized services are offline. This ensures that IEAM for Devices will continue to operate even if there are attacks on the centralized services.

Asymmetric key cryptography is mostly used in IEAM. That involves generating crypto keys and exchanging those keys when deploying services. Agents and agbots cryptographically sign their messages to each other by using their private keys. The receiving component uses their counterpart’s public key to verify the messages they receive. The agents and agbots also encrypt their messages with the other party’s public key to ensure that only the intended recipient can decrypt the message with its own private key. In case a key is compromised, only the artifacts that are under the control of that entity are exposed.

Role-based access control

When an IBM Edge Application Manager (IEAM) cluster is created, the name of the cluster is used as the name of the organization, and an organization is used to separate access to resources. Resources for an organization can be viewed by only that organization. Resources that are marked public, however, are the only resources that can be viewed across organizations. This is how role-based access control (RBAC) is enforced.

The available roles in IEAM are admins, non-admins, and owners who create a given resource. Listed below are different kinds of credentials that one of those roles might use for authentication:

• Root user: Set within the config.json file used on device side
• IAM/LDAP user: Used for accessing the (Hub management console)
• IAM API keys: For use with the (Horizon) hzn CLI in the node Agent
• Local exchange user: This role is seldom used
• Admin user: Users can be given administrative privileges, such as for use as the super user of an organization.

Note that the user that creates a resource—such as services, patterns, and business policies—is the owner of that resource. Other users can only view that resource.

Security-related processes and tasks in IEAM

Whether it is a developer pushing code to the devices, an agent finalizing an agreement with an agbot, or a device getting registered with the Horizon exchange, security is pervasive in all tasks and processes related to IBM Edge Application Manager (IEAM). Either crypto keys or certificates are created, used, and exchanged between components, and all communication takes place using a secure protocol like HTTPS and TLS 1.3. Key generation commands are described below:

• SSH key: SSH keys, used by developers, are generated on the Linux host using the ssh-keygen command. They use a passphrase and are always generated in pairs wherein the pair consists of one “public” key and one “private” key. The private key is kept on the generated host and the public key is copied to the remote component/device. The recommended command is:

  ssh-keygen -t rsa

• API key: API keys are obtained from the IAM component in the hub. They are used for authentication with IEAM for using the devices’ command line interface (i.e., the hzn commands). They can be generated using the cloudctl command:

  cloudctl iam api-key-create "<choose-an-api-key-name>"

• Crypto key: Cryptographic keys are another key pair that enable you to sign services when publishing them to the Horizon Exchange. Note that you need to do this step one time. The hznam command is:

  hzn key create “<companyname>” “<youremailaddress>”

  In the command, companyname is used as the x509 organization, and youremailaddress is used as the x509 CN.

All keys should be actively managed. We recommend following the CIS guideline 5.4.1.1 of rotating keys every 90 days and to not use the same passphrase across the solution. Enterprises tend to store the private key in a secure location.

The diagram below shows the keys involved when registering an edge device with the Horizon Exchange:

To reiterate, in order to meet security standards, all communication between components is done in a secure manner—a secure communication protocol like TLS 1.3 is used, messages are encoded, the sender and receiver are verified, and only the recipient can read a message based on the keys exchanged.

Lastly, the table below shows where the different security items are stored. Note that since these items operate in pairs, having one without the other is quite harmless:

• Self-signed cert: On the device
• Public key: In the Exchange Database
• Private key: Computer file system of the DevOps engineer

Conclusion

In this article, we have attempted to address security concerns about edge computing solutions and show how various security techniques can be employed to lock things down. We have discussed how to prevent common attacks by providing encrypted and signed messages, container tampering, and update verification. As things mature, we are bound to come up with a set of best practices in securing such edge solutions.

The link to instructions on how to deploy workloads to the edge with specific policies that make them secure can be found in the references section.

The IBM Cloud architecture center offers up many hybrid and multicloud reference architectures. Check out the newly published edge computing reference architecture.

Thank you to Ivan Portilla and Dennis Lauwers for reviewing the article, David Booz for filling in the gaps, and Joe Pearson for providing his perspective.

Learn more

Please make sure to check out all the installments in this series of blog posts on edge computing:

• Part 1: “Cloud at the edge”
• Part 2: “Rounding out the edges”
• Part 3: “Architecting at the edge”
• Part 4: “DevOps at the edge”
• Part 5: “Policies at the edge”
• Part 6: “Models Deployed at the edge”
• Part 7: “Security at the edge”
• Part 8: “Analytics at the edge”
• Part 9: “5G at the edge”
• Part 10: “Clusters at the edge”
• Part 11: “Automation at the edge”
• Part 12: “Network slicing at the edge”
• Part 13: “Data at the edge”
• Part 14: “Architectural decisions at the edge”
• Part 15: “GitOps at the edge”
• Part 17: “Storage services at the edge”
• Part 18: “Cloud services at the edge”
• Part 19: “Distributed cloud: Empowerment at the edge”
• Part 20: “Data sovereignty at the edge”
• Part 21: “Solutioning at the edge”
• Part 22: “Connected products at the edge”
• Part 23: “Foundational models at the edge”
• Cloud adoption
• IBM Edge Computing Manager for Devices
• Center for Internet Security
• Platform AbstRaction for SECurity (Parsec)
• Edge security: There are lots of attack surfaces to worry about
• Enhanced security at the edge
• How data security at the edge can future-proof your agency
• Security at the Edge
• Watch the video