The Security of Your Edge Infrastructure ...
"Blue Lake Snodonia", "I climb, to see thee, but wait", "Art thou brimming too" ...

The Security of Your Edge Infrastructure ...

The haiku above is incidental. A haiku is a snapshot - of a moment in time. So how can we paint such a snapshot of the security for your Edge Infrastructure. Is the snapshot one big picture, like a modern art capturing the essence, or several smaller ones that build a composite picture and where details matter. Lets find a middle ground - by creating a vocabulary and then get down to applying it in telling the story.


A quick introduction to the topic and its taxonomy:

  1. An Edge Infrastructure or Edge Cloud: It is a computational infrastructure (infra) close to either the source of data or its point of consumption. It's a wide deployment region between your OT (Operational Technology or Cyber Physical System / IoT) Infra and your IT (Information Technolgoy or Backend) infra, and may span On-prem, Telco and Colo Data-center. Some refer to it as ET (Edge Technology).
  2. An Edge Node: It's the basic unit of Edge Infra, usually a hardware server that can run one or more applications, but it could also be a virtual machine. It could be providing networking services (facilitiating the transmission of data), application services (running data processing, inferencing or generative AI), or control plane services (helps in the management of the infra).
  3. A Fleet: All the Edge Nodes together make a Fleet. This term on its own comes up in references to Fleet Management, viz. in secure onboarding of a new Node, and management of security and ownership policy related to those Nodes.
  4. A Cluster: The Edge Nodes that have a common control plane which decides what applications run on which server - form a Cluster. Some clusters could be single node, and in some other cases multiple virtual nodes could be running on a single physical machine.
  5. Management and Ochestration Function: This is a global SaaS Controller that provides services related to Infra Management, Control Plane Management (e.g., Cluster Orchestration) and Application Services Management (Life Cycle Management).
  6. A Blueprint: This is the platform package consisting of OS, Networking and other application support services that together give a personality to the Edge Node, making it suitable or optimal for running certain kinds of workloads say Industrial, Smart-ports, Health-services, or private wireless infra use cases.
  7. Hosted Infra Services: These are global SaaS providers from the ecosystem that help solve key problems needed Edge Infra. Example services could be related to Identity Management, Trust and Certificates, Security Vulnerability and Malware detection/cloud-hosted services etc.


Next, let's understand the context of Edge Indra security; security is always a critical consideration but why it is such a basic hygiene factor for the Edge ecosystem. Consider the following set of problem statements:

  1. The Legacy of Cloud: The Edge Ecosystem application and platform software developers come from Data center and Cloud legacy where physical security is a given. The Edge infra, on the other hand, could be deployed in the field, on a lamp post, in malls, high rise buildings and similar enterprise settings. Hadware tampering attempts can't be discounted (a physical limitation).
  2. A Heterogeneous Environment: The Edge nodes could be added based on business needs and solution availability; it could thus consist of different platforms.
  3. Limited Computational Power: There is only limited computational power available at most of the edge location. The attacker can easily overwhelm the safety applications or otherwise take advantage by forcing a network connection outage etc. An attack could originate on the weakest part of the infra, say an obsolete or unpatched system from an inadvertent user click, to spread to more valuable part of the infra that is otherwise protected. The best strategy for Edge deployments is to decrease the attack surface, ideally disappear from the radars of attackers (defence without fighting).
  4. A Distributed Environment with Centralized Control: Edge nodes and their central controllers connect over a network that could be untrusted (e.g., a WAN). So, each operation, whether between the microservices running on peer Edge nodes, or between Edge node and the central controller, must be authenticated and authorized, i.e. the identity of the endpoints is established and the privilege to run the commands is confirmed. This is Zero-Trust based operation (broadly covered under Zero Trust Network Access).
  5. The Human Element: Most Edge deployments lack skilled technicians at hand to bring up take any action, needing costly truck-rolls. Automation is key to removing a significant pain-point in successful deployments (Zero-Touch Provisioning).
  6. A Hardware Root of Trust in the Edge Infra: Todays malwares and Advanced Persistent Threats are so sophistication that they can hide themselves effectively from software based defences on the Edge nodes. A Hardware Root of Trust has a better chance of weeding out such threats.
  7. The Shadow of Regulations: Edge is where true benefits of Artificial Intelligence would be seen. Whether this is in healthcare, retail, smart cities and transport, and defence. There are increasingly stringent requirements on Data-governance, privacy etc and the ecosystem must come together to help meet the challenges.


With the above understanding, let's talk about the key security problems facing Edge Infrastructure that I keep coming across:

  1. How to securely onboard a new Node into the Edge Infra? This could be extended to remote management (securely) of the underlying hardware and firmware across WAN. This is Day -1 and Day 0 problem.
  2. How to give a deployment specific platform personality to an Edge Node. This is the Provisioning Problem. It starts where Secure Onboarding finishes, but the hardware is not yet primed to be handling data. This is a Day 0 problem. The services are now being brought up. Integrity of the blueprint, and presence of Vulnerabilities (CVEs) is scanned through SBOM (Software Bill of Materials) check at the minimum.
  3. How to make a new Edge Node part of a cluster, with a common control plane? This could include upgrades and provisioning of platform security credentials. This is a Day 0 problem.
  4. How to deploy, patch and scale applications and the Edge Infra, so that it can take advantage of the underlying hardware security and data-processing capabilities. This is the problem of Application Life Cycle Management (LCM) and meeting Service Level Agreement (SLA) performance requirement. It's partially Day-1 and partially Day-2 problem.
  5. How to integrate or leverage a software development tool-chain, whether to bring DevSecOps capablity or to leverage existing AI/ML capabilities with security features, from solution providers.


That's it for this article. I'll keep updating the taxonomy as I gather and develop the concepts, while also using it to describe the thoughts - in a bootstrap process, if you please.

Great job, Anurag! A pithy introduction to start thinking about security @Edge that deserves attention _now_.

Eugene Yarmosh

Strategist, Technologist, Chief Architect and Product Lead focusing on scalable distributed and decentralized/DLT systems, edge/IoT to cloud solutions and applying Confidential Compute to the federated usages and ZTA

1y

Nice and clear writing! Plus it is the most romantic take on the edge security :). Thank you for sharing.

To view or add a comment, sign in

More articles by Anurag Ranjan

Insights from the community

Others also viewed

Explore topics