By Philip Griffiths, VP Business Development at NetFoundry
Magic and Pasta
I had always had trouble explaining to my eldest daughter what I did for my job and how our technology would change the world. She did not understand OpenZiti, but she loves Ziggy (our pasta mascot, here he is dressed as a wizard – learn about 10 of the best facts about Ziggy’s life). Then we began reading Harry Potter together, and I was reminded of Arthur C. Clarke’s Three Laws, and most memorably the third law: “Any sufficiently advanced technology is indistinguishable from magic.” And it hit me; I could use magic and Harry Potter as a way to have my daughter understand what opensource OpenZiti did and, therefore, what my job was.
Castles and Cities
Let’s start with some background. “Castle-and-moat” is a network security model in which no one outside the network can access data on the inside, but everyone inside the network can. Imagine an organization’s network as a castle and the network perimeter as a moat. Over the last few years, this model has become outdated. Businesses have evolved into ‘corporate cities’ with open trade routes (APIs), apps, and users distributed everywhere with various security systems using the public internet as an information superhighway. While cities are drivers of innovation, they have a fundamental flaw; you cannot secure networks, only isolate them. Anyone can get between our cities microseconds – kind of like the Floo Network. As a result, they are riddled with crime, a trillion-dollar drag on the global economy. Surveillance techniques known as scan-and-exploit have become the No. 1 attack vector for cyber-criminals. In recent years, Zero Trust has found significant industry adoption based on the principles laid out by NIST.
- Enhanced identity governance.
- Policy-based access controls.
- All connectivity is micro-segmented.
- Implementing software-defined perimeters and supporting hardware root of trust.
But not all zero trust is made equal. Together, my daughter and I settled on categorizing non-magical, partially-magical, and magical zero trust to help explain the differences. Now she understands what I do and how our technology works.
Non-magical Zero Trust
At the most basic level, we have vendors (commonly firewalls or VPN providers) who have applied a ‘zero trust’ label to their products. These products act as a proxy point for the user and device verification to achieve principle 2, and possibly but not always 3, as defined by NIST. They have public IPs, inbound ports, and link listeners, subject to external network-level attacks. My daughter understands this as adding guards and ID verification to buildings (network), floors (host), and, maybe rooms (apps), within our cities. It’s better than a VPN, but there are still many attack vectors as the silly Muggles don’t believe in magic.
Partially-magical Zero Trust
Non-magical zero trust has a problem; my daughter best describes it: “Imagine if any Muggle could walk into Kings Cross platform 9 3/4 by accident!!“. A few vendors introduced principle four and built a software-defined-perimeter (SDP) into their product. The attack surface massively reduces from external network attacks (and witches or wizards from muggles). SDP can use various techniques, including single packet authentication (or port knocking) or authentication and authorization-before-connectivity using strong identity and least-privileged access. This is a significant improvement for the security of our cities; apps can be “invisible like Diagon Alley or 12 Grimmauld Place“. Now malicious actors (and silly muggles) cannot find or attack your applications or cities. We didn’t stop there though…
Magical Zero Trust
While reading Harry Potter, my daughter became bewitched with the idea of Portkeys, ‘magical objects which can instantly bring anyone touching it to a specific location’. She kept touching random objects around the house, expecting to turn up at the toy shop. But that does not sound much like a network traditionally bolted between our apps and users. However, this is *exactly* what happens when you embed an open-source OpenZiti SDK into your application! Now, regardless of where your endpoint is, it’s magically transported to the destination through the OpenZiti fabric. My daughter tells me it’s like putting a powerful spell of concealment and a Portkey directly into your app.
This software-powered OpenZiti network is configured using identities, services, and policies. It ensures there is no other way to reach your app as we have zero trust in the wide-area, local-network and even OS network. Embedding zero trust into your apps makes them immune to network-based side-channel attacks [1]. Even if malicious actors or ransomware tried to attack the application from a device, they cannot – muggles cannot enter. They do not have the Portkey (or ‘port key’; wink, wink); it’s inside the app. Your APIs are dark, and your users have no idea. This magical, invisible network is concealed inside the application; it’s completely transparent. The application becomes multi-cloud native with absolutely no lock-in to cloud or telco ‘secure connectivity’ products. The app only needs commodity internet with a few outbound ports.
What is most magical about OpenZiti and NetFoundry is we built it as a platform that supports any use cases from hybrid/multi-cloud to edge and IoT; across user access (incl. DevOps or user remote access) and app-embedded. Now every business connectivity requirement can be magical.
As my daughter keeps telling her friends, “my dad does magic with technology,” and now she (sort of) knows what I do for my job.
[1] Phishing is a technique malicious actors use to trick users into installing malware on their devices. This malware might then look for servers or applications running on the device with listening ports and exploit them. This is an example of a side-channel attack that OpenZiti can render absolutely impossible
