Software Defined Perimeter

  • 1.  SDP, encryption and identity management

    Posted Jun 03, 2020 12:26:00 AM
    No matter whether a user is a person, a device or an application, network connections are only as secure as the weakest link.  Device ID, IP address, contextual geo-location are simply all easily spoofed.  AES ephemeral key field level encryption is required to support https, as TLS including TLS1.3 have systemic vulnerabilities.  TCP over IP is vulnerable to a variety of attack vectors including session hijacking, TCP sequence attacks, spoofing MITM (Man-in-the-Middle), SYN floods (e.g. DDoS, Replay), stolen cookies and credentials.  These attacks are happening every day. No matter what the type or source of attack, the average end-to-end cost of a data breach was $3.92 million in 2019 (IBM/Ponemon). 

    SDP if correctly implemented before  DNS resolution, TCP three way handshake, and TLS termination can validate whether a request is approved, (i.e. the authentication token validated), or is denied (auth does not succeed). 

    This is akin to the definition of Zero Trust.  Positive identification of a connection request at the Network Perimeter.

    There are a lot of "Zero Trust" and "SDP"​ products out there. But are they really?  So where can a data plane/control plane authentication be made?  To my mind, it has to be OSI Layer 4 load balancing during the TCP handshake.  

    Layer 7 load balancing (Application Load Balancer) usually includes TLS, HTTPS, REST protocol.  This is complex, and presents lots of opportunity for hackers.  Layer 4 load balancing deals with network layer protocols such as UDP and TCP.  

    SDP Working Group has just released a white paper on SDP and Zero Trust, putting forward the view that application layer Zero Trust and SDP is shutting the stable door after the horse has bolted. 
    https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-and-zero-trust/

    We have put out a call for interested parties to join in a proof-of-concept on how to do a Layer 4 SDP implementation without exposing the session and application protocol holes that are the easy targets for the usual suspects. 

    We'd like to demonstrate the SDP controller and an identity authentication in the context of a contemporary multi cloud deployment, meaning that it works as a Virtual Load Balancer able to communicate with cloud native load balancers such as AWS, Azure and GCP.  

    We'd welcome your participation in a proof-of-concept. 




    ------------------------------
    Nya Murray
    CEO
    Trac-Car
    ------------------------------


  • 2.  RE: SDP, encryption and identity management

    Posted Jun 09, 2020 01:31:00 PM
    Edited by Shamun Mahmud Jun 09, 2020 01:37:46 PM

    Nya,

    Thanks for sharing this thoughtful, well-written piece on SDP and the upcoming Proof of Concept (POC).  I have shared your insights with the LinkedIN community for supplemental traction.  The SDP WG looks forward to working with the entire SDP community on the POC.  

    Shamun



    ------------------------------
    Shamun Mahmud
    Standards Officer, Sr. Research Analyst
    Cloud Security Alliance
    WA
    ------------------------------