Software Defined Perimeter Solutions

 

 

Software Defined Perimeter Solutions

The following post discusses the Software Defined Perimeter solution, the need for a new software perimeter solution, and how this can be integrated. Many companies use SD-WAN and multiprotocol label switching (MPLS) based architectures to attack the same problem. However, the application is changing, which requires a shift in these architectures. Application developers and software service providers want to take more control of their sessions. And we are seeing this with the rise of Open networking. The next generation of applications is mobile, in the cloud, software as a service (SaaS), and the internet of things (IoT) based. It is everywhere and does not stay in the walled garden of the enterprise.

You could say it’s wholly distributed but not dark and hidden from the Internet. Solutions encompassing a zero trust network design are needed to connect the application endpoints wherever and wherever they are allowed. We are seeing a new type of perimeter, which some call these software defined perimeter solutions. A perimeter that is built from scratch by the application and employs a zero-trust model, much of which is derived from cloud security alliance software defined perimeter.

 

Before you proceed, you may find the following posts helpful:

  1. Distributed Firewalls
  2. Software Defined Internet Exchange

 



Software Perimeter Solution.

Key Software Defined Perimeter Solutions Discussion points:


  • Discussion on Software Defined Perimeter ( SDP ).

  • The challenges with traditional perimeters.

  • Changes in the environment are causing a need for SDP.

  • SDP and end to end security.

  • Ways to integrate the application.

 

 

 

 

software defined perimeter solutions
Diagram: Software-defined perimeter solutions: The changing landscape.

 

Software-defined Perimeter solutions: Right at the Application

The perimeter should now be at the application. And with network traffic engineering, this is already common in microservices environments where the application programming interface (API) is the perimeter. Still, we should now introduce this to non-containerized environments, especially regarding 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 that tightly integrates with the application provides the required security and network path control. Previously the traditional model separated the application from the network. The network does what it wants, and the application does what it wants. The application would throw its bits over the wire and hope the wires are secure. The packets will eventually get to their destination.

software defined perimeter solutions
Diagram: Software-defined perimeter solutions: The TCP/IP model issues.

 

End-to-end security 

It would be best to have a solution that works more closely with the application to ensure end-to-end security. This can be done by installing client software on the mobile app or using some 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 using standard Pops with physical/virtual equipment or containerized packed forwarders that can be spun upon demand. Containerized packed forwarders sound a little bit more interesting.

Each session can then get distributed to find the best route where several routers can be spun up all over the globe. The packet forwarder is spun up on different networks and autonomous systems (AS) worldwide, 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. If a path shows unacceptable performance within seconds, 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 specific applications. You can do a linear optimization from all those variables.

Essentially you should do cold potato routing on the private network instead of 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 can talk to. For example, the port and protocols enable the business policies to govern the application’s network behavior.

A packet from the internet address towards an IoT endpoint in the home must be authenticated and authorized to fit the business policy. These endpoints could then be streamlined into a distributed ledger like a blockchain. Suddenly, with proper machine learning and collaborations, you may be able to identify some of the DDoS attacks before they create massive problems.

Sometimes, 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 unique conditions of the silicon itself generate the identity. In this case, you don’t care about the IP addresses anymore. As technology progresses, we are becoming less reliant on IP addresses.

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

 

Matt Conran
Latest posts by Matt Conran (see all)

Comments are closed.