Cyber security threat. Computer screen with programming code. Internet and network security. Stealing private information. Using technology to steal password and private data. Cyber attack crime

Software defined perimeter (SDP) A disruptive technology

 

software-defined perimeter

 

Software Defined Perimeter

In today’s digital landscape, where the security of sensitive data is paramount, traditional security measures are no longer sufficient. The ever-evolving threat landscape demands a more proactive and robust approach to protecting valuable assets. Enter the Software Defined Perimeter (SDP), a revolutionary concept changing how organizations secure their networks. In this blog post, we will delve into the world of SDP and explore its benefits, implementation, and prospects.

Software Defined Perimeter, also known as a Zero Trust Network, is a security framework that provides secure access to applications and resources, regardless of the user’s location or network. Unlike traditional perimeter-based security models, which rely on firewalls and VPNs, SDP takes a more dynamic and adaptive approach.

 

Highlights: Software Defined Perimeter

  • A Disruptive Technology

There has been tremendous growth in the adoption of software defined perimeter solutions and the zero trust network design over the last few years. This has resulted in SDP VPN becoming a disruptive technology, especially when replacing or working with the existing virtual private network. Why? Because the steps that software-defined perimeter proposes are needed.

  • Challenge With Todays Security

Today’s network security architectures, tools, and platforms are lacking in many ways when trying to combat current security threats. From a bird’s eye view, the stages of zero trust software defined perimeter are relatively simple. SDP requires that endpoints, both internal and external to an organization, must authenticate and then be authorized before being granted network access. Once these steps occur, two-way encrypted connections between the requesting entity and the intended protected resource are created.

 

For pre-information, you may find the following post helpful:

  1. SDP Network
  2. Software Defined Internet Exchange
  3. SDP VPN

 



Software-Defined Perimeter.

Key Software Defined Perimeter Discussion points:


  • The issues with traditional security and networking constructs.

  • Identity-driven access.

  • Discussing Cloud Security Alliance (CSA).

  • Highlighting Software Defined Perimeter capabilities.

  • Dynamic Tunnelling. 

 

Back to basics with Software Defined Perimeter

A software-defined perimeter constructs a virtual boundary around company assets. This separates it from access-based controls restricting user privileges but allowing broad network access. The three fundamental pillars on which a software-defined perimeter is built are Zero Trust:

It leverages micro-segmentation to apply the principle of the least privilege to the network. It ultimately reduces the attack surface. Identity-centric: It’s designed around the user identity and additional contextual parameters, not the IP address.

 

Benefits of Software-Defined Perimeter:

1. Enhanced Security: SDP employs a Zero Trust approach, ensuring that only authorized users and devices can access the network. This eliminates the risk of unauthorized access and reduces the attack surface.

2. Scalability: SDP allows organizations to scale their networks without compromising security. It seamlessly accommodates new users, devices, and applications, making it ideal for expanding businesses.

3. Simplified Management: With SDP, managing access controls becomes more straightforward. IT administrators can easily assign and revoke permissions, reducing the administrative burden.

4. Improved Performance: By eliminating the need for backhauling traffic through a central gateway, SDP reduces latency and improves network performance, enhancing the overall user experience.

 

Implementing Software-Defined Perimeter:

Implementing SDP requires a systematic approach and careful consideration of various factors. Here are the key steps involved in deploying SDP:

1. Identify Critical Assets: Determine the applications and resources that require enhanced security measures. This could include sensitive data, intellectual property, or customer information.

2. Define Access Policies: Establish granular access policies based on user roles, device types, and locations. This ensures that only authorized individuals can access specific resources.

3. Implement Authentication Mechanisms: Incorporate strong authentication measures such as multi-factor authentication (MFA) or biometric authentication to verify user identities.

4. Implement Encryption: Encrypt all data in transit to prevent eavesdropping or unauthorized interception.

5. Continuous Monitoring: Regularly monitor network activity and analyze logs to identify suspicious behavior or anomalies.

 

The Software-Defined Perimeter Proposition

Security policy flexibility is offered with fine-grained access control that dynamically creates and removes inbound and outbound access rules. Therefore, a software-defined perimeter minimizes the attack surface for bad actors to play with—small attack surface results in a small blast radius. So less damage can occur.

A VLAN has a relatively large attack surface, mainly because the VLAN contains different services. SDP eliminates the broad network access that VLANs exhibit. SDP has a separate data and control plane. A control plane sets up the controls necessary for data to pass from one endpoint to another. Separating the control from the data plane renders protected assets “black,” thereby blocking network-based attacks. You cannot attack what you cannot see.

 

The IP Address; Is Not a Valid Hook

We should know that IP addresses are lost in today’s hybrid environment. SDP provides a connection-based security architecture instead of an IP-based one. This allows for many things. For one, security policies follow the user regardless of location. Let’s say you are doing forensics on an event 12 months ago for a specific IP.

However, that IP address is a component in a test DevOps environment. Do you care? Anything tied to IP is ridiculous, as we don’t have the right hook to hang things on for security policy enforcement.

 

Software-defined perimeter; Identity-driven access

Identity-driven network access control is more precise in measuring the actual security posture of the endpoint. Access policies tied to IP addresses cannot offer identity-focused security. SDP enables the control of all connections based on pre-vetting who can connect and to what services.

If you do not meet this level of trust, you can’t, for example, access the database server, but you can access public-facing documents. Users are granted access only to authorized assets preventing lateral movements that will probably go unnoticed when traditional security mechanisms are in place.

 

 

Information and infrastructure hiding

SDP does a great job of information and infrastructure hiding. The SDP architectural components ( the SDP controller and gateways ) are “dark, ” providing resilience against high and low-volume DDoS attacks. A low bandwidth DDoS attack may often bypass traditional DDoS security controls. However, the SDP components do not respond to connections until the requesting clients are authenticated and authorized, allowing only good packets through.

A suitable security protocol that can be used here is single packet authorization (SPA). Single Packet Authorization, or Single Packet Authentication, gives the SDP components a default “deny-all” security posture.

The “default deny” can be achieved because if an accepting host receives any packet other than a valid SPA packet, it assumes it is malicious. The packet will get dropped, and a notification will not get sent back to the requesting host. This stops reconnaissance at the door by silently detecting and dropping bad packets.

 

Sniffing a SPA packet

However, SPA can be subject to Man-In-The-Middle (MITM) attacks. If a bad actor can sniff a SPA packet, they can establish the TCP connection to the controller or AH client. But there is another level of defense in that the bad actor cannot complete the mutually encrypted connection (mTLS) without the client’s certificate.

SDP brings in the concept of mutually encrypted connections, also known as two-way encryption. The usual configuration for TLS is that the client authenticates the server, but TLS ensures that both parties are authenticated. Only validated devices and users can become authorized members of the SDP architecture.

We should also remember that the SPA is not a security feature that can be implemented to protect all. It has its benefits but does not take over from existing security technologies. SPA should work alongside them. The main reason for its introduction to the SDP world is to overcome the problems with TCP. TCP connects and then authenticates. With SPA, you authenticate first and only then connect.

 

SPA Use Case
Diagram: SPA Use Case. Source mrash Github.

 

The World of TCP & SDP

When clients want to access an application with TCP, they must first set up a connection. There needs to be direct connectivity between the client and the applications. So this requires the application to be reachable and is carried out with IP addresses on each end. Then once the connect stage is done, there is an authentication phase.

Once the authentication stage is done, we can pass data. Therefore, we have the connect, then authenticate, and data pass a stage. SDP reverses this.

zero trust security
Diagram: Zero trust security. The opposite of the TCP: Connect Firsts and then Authenticate

 

 

The center of the software-defined perimeter is trust.

In Software-Defined Perimeter, we must establish trust between the client and the application before the client can set up the connection. The trust is bi-directional between the client and the SDP service and the application to the SDP service. Once trust has been established, we move into the next stage, authentication.

Once this has been established, we can connect the user to the application. This flips the entire security model and makes it more robust. The user has no idea of where the applications are located. The protected assets are hidden behind the SDP service, which in most cases is the SDP gateway, or some call this a connector.

 

  • Cloud Security Alliance (CSA) SDP
    • With the Cloud Security Alliance SDP architecture, we have several components:

Firstly, the IH & AH: are the clients initiating hosts (IH) and the service accepting hosts (AH). The IH devices can be any endpoint device that can run the SDP software, including user-facing laptops and smartphones. Many SDP vendors have remote browser isolation-based solutions without SDP client software. The IH, as you might expect, initiates the connections.

With an SDP browser-based solution, the user uses a web browser to access the applications and only works with applications that can speak across a browser. So it doesn’t give you the full range of TCP and UDP ports, but you can do many things that speak natively across HTML5.

Most browser-based solutions don’t give you the additional security posture checks of assessing the end user device than an endpoint with the client installed.

 

Software-Defined Perimeter: Browser-based solution

The AHs accept connections from the IHS and provide a set of services protected securely by the SDP service. The AHs are under the administrative control of the enterprise domain. They do not acknowledge communication from any other host and will not respond to non-provisioned requests. This architecture enables the control plane to remain separate from the data plane achieving a scalable security system.

The IH and AH devices connect to an SDP controller that secures access to isolated assets by ensuring that the users and their devices are authenticated and authorized before granting network access. After authenticating an IH, the SDP controller determines the list of AHs to which the IH is authorized to communicate. The AHs are then sent a list of IHs that should accept connections.

Aside from the hosts and the controller, we have the SDP gateway component that provides authorized users and devices access to protected processes and services. The protected assets are located behind the gateway that can be architecturally positioned in multiple locations such as the cloud or on-premise. The gateways can exist in multiple locations in parallel.

 

Dynamic Tunnelling

A user with multiple tunnels to multiple gateways will be expected in the real world. It’s not a static path or a one-to-one relationship but a user-to-application relationship. The applications can exist everywhere, whereby the tunnel is dynamic and ephemeral.

For a client to connect to the gateway, latency or SYN SYN/ACK RTT testing should be performed to determine the Internet links’ performance. This ensures that the application access path always uses the best gateway, improving application performance.

Remember that the gateway only connects outbound on TCP port 443 (mTLS), and as it acts on behalf of the internal applications, it needs access to the internal apps. As a result, depending on where you position the gateway, either internal to the LAN, private virtual private cloud (VPC) or in the DMZ protected by local firewalls, ports may need to be opened on the existing firewall.

 

Future of Software-Defined Perimeter:

As the digital landscape evolves, secure network access becomes even more crucial. The future of SDP looks promising, with advancements in technologies like Artificial Intelligence and Machine Learning enabling more intelligent threat detection and mitigation.

In an era where data breaches are a constant threat, organizations must stay ahead of cybercriminals by adopting advanced security measures. Software Defined Perimeter offers a robust, scalable, and dynamic security framework that ensures secure access to critical resources.

By embracing SDP, organizations can significantly reduce their attack surface, enhance network performance, and protect sensitive data from unauthorized access. The time to leverage the power of Software Defined Perimeter is now.

 

software-defined perimeter

Matt Conran
Latest posts by Matt Conran (see all)

3 Responses