Software-defined perimeter: Zero-Trust

There are many companies attacking the same problem by using SD-WAN and multiprotocol label switching (MPLS) based architectures. However, the application is changing which requires a shift in these architectures. Application developers and software as service providers want to take more control of their sessions.

The next generation of applications is mobile, in the cloud, software as a service (SaaS), and the internet of things (IoT) based. It is literally everywhere and does not stay in the walled garden of the enterprise. You could say it’s completely distributed but certainly not dark and hidden from the Internet.

Solutions are needed that focus on connecting the application endpoints together wherever they are and whatever they are allowed to do. What we are seeing is a new type of perimeter, some are calling this a software-defined perimeter. A perimeter that is built from scratch by the application and employs a zero-trust model.

The perimeter should now be at the application. This is already common in microservices environments where the application programming interface (API) is the perimeter but we should now introduce this to non containerized environments, especially when it comes to IoT endpoints.

Fundamentally, the only way to secure the new wave of applications is to a) have reliable end-to-end reachability and b) assume a zero-trust model. You have to assume that the wires are not secure. For this, you need to have the ability to integrate the security solution more deeply within the application.

A collaborative model is needed that tightly integrates with the application providing the required security and network path control. Previously the traditional model separates the application from the network. The network does what it wants and the application does what it wants. The application would simply throw its bits so to speak over the wire and hope that the wires are secure. The packets will eventually get to their destination.

You need a solution that works more closely with the application to make sure of the end-to-end security. This can either be done by installing client software on the mobile app or by using some kind of software developer’s kit (SDK) or API. SD-WAN vendors have done a great job of backhauling security to the cloud and responded to the market very well. However, security must now become a first-class citizen within the application.

You can’t rely on tunnels on the internet anymore. From the application, you need to take the packet, readdress, encrypt it and send it to a globally private network. This private network can provide all the relevant services by either using standard Pops with physical/virtual equipment or by using containerized packed forwarders that can be spun upon demand. Containerized packed forwarders sound that little bit more interesting.

Each session can then get distributed to find the best route where a number of routers can be spun up all over the globe. The packet forwarder is spun up on different networks and different autonomous systems (AS) in the world enabling the maximum number of diverse paths between point A and point B i.e. different backbone providers, different AS, peering, and routing agreements.

The application endpoint can then examine all those paths for their given session and direct the packet to the best-performing path. Within seconds if a path is showing unacceptable performance, the session can be changed to a different path. Performance metrics like jitter, latency, and packet loss should be analyzed in real-time. And throughput for certain applications. You can do a linear optimization from all those variables.

Essentially you should do cold potato routing on the private network as opposed to hot potato routing. Cold potato routing keeps the packets on the network for as long as possible to take advantage of all the required optimizations.

Ways to integrate with the application

You can start by integrating with the application IAM (identity, access, and management) structure and then define what the application is allowed to talk to. For example, the port and protocols enable the business policies to govern the network behavior of the application.

If a packet comes from the internet address towards let’s say an IoT endpoint in the home, it needs to be authenticated and authorized so it will fit the business policy. These endpoints could then be streamlined into a distributed ledger like a blockchain. All of a sudden with proper machine learning and collaborations, you may be able to identify some of the DDoS attacks before they create massive problems.

In some cases, the policies can be tied to hardware router trust i.e. the silicon. This is often seen in the IoT-connected car use case. The silicon itself is creating a unique identifier, not a defined identity but an immutable one. The identity is generated by the unique conditions of the silicon itself. In this case, you don’t care about the IP addresses anymore. As we move further with technology, we are becoming less reliant on the IP address.

Within the software, you need to include a certificate and public key infrastructure (PKI) system so now you have a bidirectional, authenticated, and authorized certificate exchange, so again you don’t care about the IP address itself as you are working at an upper level.

Comments are closed.