In the 1960’s TV show The Prisoner, the lead character is kidnapped by unknown forces, imprisoned, and given the enigmatic name “Number 6”. He stubbornly resists his unrelenting interrogators and shouts: I am not a number! I am a free man!
Networking and security systems rely heavily on numbers, or more specifically on IP addresses. These temporary IDs assigned to machines are an essential part of the way corporate networks work today. But like the mysterious “number 6”, they aren’t a true representation of identity.
The problem with IP addresses
IP addresses constantly change. They are reused and assigned to other users and machines, making it very hard to follow an IP address across time and over multiple systems. It gets even more complicated when trying to correlate between the information about identity and permissions kept in an enterprise user store like Active Directory, and the user’s ever-changing IP address as he/she traverses the fragmented corporate network.
A user’s identity should dictate exactly what services, apps and networks they are allowed to access. To manage risk, they should generally include crypto-based proof and multiple factors for confirmation.
The problem is that generally IP addresses cannot be directly associated with this kind of user identity, or in order to do so, a lot of configuration and management is required. This is especially complex when you are dealing with remote access and have multiple ingress gateways distributed around the world. So for access control and enforcement, networks often have to settle for using the ephemeral IP address as a means of identification, despite the risks.
Today’s trust-based network topology is organized around sites and segments rather than around user identity. Firewalls, VPNs, and NACs (to name just a few) are carefully setup to prevent unauthorized access, yet once authenticated, the user is considered ‘trusted’ and usually has access to more data on the network than really necessary.
This approach not only increases the attack surface, it also increases the risk of security holes due to configuration errors that are inevitable given the difficulty correlating and synchronizing multiple tools, users and devices.
The new Software Defined Perimeter paradigm addresses these inherent flaws. It shifts the focus from network topology to the user, specifically defining which network resources a user can access, and verifying the access according to a reliable indicator of identity. According to Gartner a software-defined perimeter “defines a logical set of disparate, network-connected participants within a secure computing enclave. The resources are typically hidden from public discovery, and access is restricted via a trust broker to the specified participants of the enclave, removing the assets from public visibility and reducing the surface area for attack.”
But with SDP we still need to manage the user’s identity. Whether users access the corporate network via an IPSec/SSL client-based solution, or an agent-less browser-based solution, the challenge of managing millions of identities and their associated security and routing policies in a scalable way, without excessive processing, is the same.
How is theory turned into practice? Here’s an introduction to our approach, and as you may have guessed, it is user-centric.
User-centric access enforcement
In a ‘traditional’ network, once a user is authorized to enter the network, restricting and controlling access can be tricky. For example, a user may connect remotely via a mobile device; the traffic then passes from a VPN concentrator to another appliance such as an NGFW that is tasked with segmenting the internal network and restricting access.
Meta NaaS, on the other hand, is based on a zero-trust paradigm that revolves around users rather than physical topology. Each user-plus-device combination has a unique, fixed identity regardless of where and how they connect to the network. That identity is the basis for defining, enforcing and auditing access to corporate applications and networks at every stage – not only during the initial connection and authentication. Additional factors can also be applied to mitigate the risk of a stolen device.
As illustrated below, granular one-to-one network connections are defined between user devices and specific applications or network elements.
The zero-trust architecture restricts the access of Employee A to one application in the data center and one in the cloud. Employee B can access one application at HQ.
Access policies are defined centrally through a cloud-based Admin console, eliminating complexity and the need to synchronize policies among different products and locations.
This model enables dynamically provisioned, secure network segmentation and provides the flexibility to connect and isolate anything you need in a secure enclave, whether it’s users to a corporate application, a hybrid data center/cloud, or the DevOps team to a public cloud.
Packet-level traceability and auditing
The user-centric technology enables not only access enforcement and policy governing, but also packet-level traceability of all traffic.
Meta NaaS logs all traffic, all the time, regardless of where a user device connects. Unlike other systems, Meta NaaS identifies all traffic in terms of the user device – with no correlation required. Audit logs are always accessible and available and can be consumed by analytics tools, forensic tools, and compliance audits.
To summarize – our identity-centric network eliminates the security drawbacks resulting from the reliance on temporary IP addresses for authentication. With Meta Networks, the mysterious “number 6” prisoner wouldn’t be just a number, but would be given a name and true identity. As to access rights, that would depend on the network administrator.