Along with the growth of edge applications comes the risk of increased attack surfaces for malicious actors. It’s imperative to have a security-by-design solution when deploying edge applications. Izuma Edge builds on years of experience and development of the Izuma Cloud product and its zero trust security principles.
Our cloud services provide true end-to-end security for all devices, including edge servers, helping ensure the secure deployment of edge applications and configuration data. APIs allow users to revoke individual or groups of gateways or servers in the case of a potential breach. Our services take advantage of secure hardware when available, such as TPM 2.0 silicon, other cryptographic security modules or HSMs.
Deployed applications can also leverage the built-in SD-WAN services and provide secure transport to other pods running in the cloud portion of their Izuma Cloud instance, configure ingress and egress to their own cloud services or to specific interfaces at the edge. These services all communicate using mutual TLS (mTLS) with certificates we can trust; a root-of-trust established during the manufacturing or system imaging process using Izuma Factory Flow or the Izuma Edge installer.
Edge computing is a sophisticated paradigm, which involves machines both in the cloud and at the edge. Those edge machines could be anywhere, and they are usually highly decentralized. This being said, having a well-thought-out defense-in-depth strategy for security at the edge is critical. Let’s walk through the key layers of our Edge-as-a-Service security design:
What is device identity? Like in the identity of end-users, such as those available through various identity-as-a-service platforms (think of the many SSO providers) - where we verify individuals or accounts, in device identity we are verifying that the device which says its a given device is indeed that device.
Note: Below we explain the factory flow and boostrap process. Images show Izuma Edge, but these processes apply to both Izuma Edge and Izuma Connect.
All other edge or IoT security measures are pointless if you can’t ensure that the edge box / IoT device you are talking to is truly the device you deployed. This starts with strong identity security which requires a secure process for device identity creation.
A unique and secure identity starts with a root certificate authority (CA). This can be a CA self-generated by the owner of the service. By the owner of the service, we mean the organization that controls its Izuma Cloud instance. This unique CA certificate will be provided to Izuma when you create your cloud instance. Izuma networks will never need or ask for the CA’s private key. We can also create a CA for you and protect its keys using robust HSMs stored at a secure facility.
Typically, an organization will then create an intermediate CA certificate, which the Izuma Factory Flow tools can use to generate unique certificates for each machine/device. Along with the unique certificate are additional immutable fields that will uniquely identify the machine. With each unique certificate also comes a unique fingerprint identifying the machine.
The certificate installed is not the final certificate the machine will use. This certificate is used during the next step: bootstrap. During the Factory Flow tool setup, you can choose between either using your Izuma Cloud instance bootstrap service, solely or using the global bootstrap services. By default and our recommendation in most cases is to use the global bootstrap services. This will allow your machines, should you wish, to switch to another Izuma Cloud instance as necessary. For instance, if you are running two or more Izuma Cloud instances, or have deployed a new, replacement instance.
Machines that have the bootstrap certificate on them are ready to be onboarded as soon as connected to a network that can reach the global bootstrap services (if applicable) and your Izuma Cloud instance. The cloud itself does not yet know about the machine. It is entirely fine for machines to sit unused, in a holding area or warehouse for an indefinite period of time before onboarding. If during this time, it’s decided these machines are not valid - or you simply don’t want anyone to ever onboard them, the identity of the machine can be added to a list to prevent onboarding. In a worst-case scenario, every machine signed by a specific intermediate certificate could also be voided.
In many installations, installing Izuma Edge and running the Factory Flow tools (integrated into the install process depending on your installation method), may be immediately followed by deploying the machine. In these cases, the bootstrap process can seem unnecessary. However, it still provides a significant purpose. Because of bootstrap, any machine can be reset to a state just like when it was first installed. In these cases, the machine can assume a new identity and switch to a different cloud (if you chose to use the global bootstrap system). Certain immutable fields such as serial number, etc. will always remain the same - so hardware can always be identified.
Onboarding: Initializing Bootstrap
Onboarding is the simple process of telling the cloud that a unique machine, identified by a cryptographically unique fingerprint, is welcome to attach to a specific cloud. In its simplest form, this is a basic, but privileged, API call to our services. The fingerprint itself is unique and should be protected just like the physical hardware itself would. A straightforward way might be attaching a sticker on the machine and an insert into the box if dealing with machines being created at a factory. A stolen machine could still not be onboarded without having the appropriate credentials to make the API call. The Factory Flow tools will also record all fingerprints generated.
Once the API call is made, and the machine connects to the bootstrap service, it receives back new credentials in the form of a new certificate, which cloud to talk to - in the case of global bootstrap - and some ancillary information, including which namespace (also termed “account”) in the Izuma Cloud instance to use. Certain tasks may also be “hooked” at bootstrap, such as a notification from Izuma Cloud to inform another service an onboarding has occurred. Namespaces allow Izuma Cloud to easily be used as a multi-tenant service where edge machines and users in the Izuma Cloud can be segmented.
Methods vary in ways of accomplishing onboarding. If you are deploying Izuma Cloud for your own internal IT needs, then just keeping the fingerprints in a secure location and using our admin interface may be enough.
If you are deploying machines en-masse, and expect third parties or even a significant amount of non-IT / non-operations personnel to deploy your machines (such as a global field engineering team, as an example) - then you may want a more dynamic system. We have example software that will, for instance, help you build internal or customer-facing mobile apps to onboard devices by scanning a QR or bar code.
Once a unique identity is created and stored on the edge machine, it is critical that comprising this identity is an immensely difficult task. The goal is that the task is so difficult that no one could accomplish it in a timely fashion, especially if they do not have physical access to the machine.
Izuma Edge and Izuma Connect both take advantage of cryptographic secure storage when available. The most common form of this is TPM 2.0, available on many gateway class machines and an optional component on most server class machines. Some chipsets include TPM as part of the chipset. Other forms of root-of-trust hardware include Arm PSA-compliant hardware, as well as a vTPM, such as might be available in a virtual machine or in a cloud instance.
In order to make support of different types of cryptographic hardware flexible, Izuma Edge takes advantage of PARSEC, a CNCF project, which can take advantage of many different types of TPM or HSM modules.
Security mitigations
Because each device has a unique identity, and this identity is very difficult to forge, it can generally be trusted that edge machines who say they are can be trusted to be what they say.
This considered, there may be times when operations teams no longer have faith in certain systems’ integrity. Machines can be placed on a deny list by their fingerprint. Doing so will prevent the machine from communicating with the cloud services.
Because of the Izuma Edge and Izuma Cloud work, even if a machine was compromised, it could not access the entire cluster. Edge machines that belong to a specific account can only talk to pods in that account unless specifically configured otherwise.
Trusted identity and the certificates received on the machine during bootstrap allow the machine to use mTLS encryption for all communication.
In short, mTLS, or mutual TLS, allows the edge machine to always verify that it is talking to the correct server, and it allows the server to verify that it is talking to this unique edge machine.
All communication from Izuma Edge or Izuma Connect uses mTLS. In the case of Izuma Edge, almost all communication uses HTTPS outbound from the machine running Izuma Edge to an Izuma Cloud instance.
SD-WAN for deployed applications
Additionally, Izuma Cloud provides an SD-WAN service that works with any machine using Izuma Edge. This SD-WAN allows k8s pods, deployed at the Izuma Edge machine, to ride the SD-WAN to a specific service in the Izuma Cloud cluster (such as a pod running in the cloud portion of the Izuma Cloud instance) or onto the open Internet. This means that firewalls / WAFs at each Izuma Edge deployed location do not need any specific rules for applications. Instead, traffic always routes through specific egress points on the Internet.
Since Izuma Edge and Izuma Cloud are built on Kubernetes and have an SD-WAN interface for outbound traffic, it’s possible to significantly limit your attack surface at the edge by limiting network interfaces to only the traffic pods need.
Deployed pods at the edge should have appropriate network policies. This makes sure applications deployed at the edge can’t speak to services or rogue clients on the local LAN or risk being probed through the WAN.
Deployed pods can also have network policies that deal with specific physical interfaces at the edge. For instance, a gateway class device might have an “OT” network - or control network - on one interface, and a type “IT” LAN on the other interface. Outbound traffic, to Izuma Cloud would route out the LAN interface, whereas the control network would only be used by specific pods - pods that would never talk to the Internet.
