Zero Trust

 View Only
Expand all | Collapse all

Examples of application embedded zero trust using open source OpenZiti

  • 1.  Examples of application embedded zero trust using open source OpenZiti

    Posted Aug 26, 2022 07:54:00 AM
    Hey all,

    I work for the company behind OpenZiti, an open source private overlay mesh network built on zero trust networking principles. We have recently been doing some cool examples to show how zero trust networking can be embedded into the application layer using SDKs so that we build outbound, identity driven, E2EE tunnels from app user space to user space across any untrusted underlay networks (internet, LAN, even host OS network).

    Would be interesting to hear any feedback or questions... what do you think about putting zero trust networking inside the application?
    Regards

    ------------------------------
    Philip Griffiths
    Head of Business Development
    NetFoundry
    ------------------------------


  • 2.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Aug 30, 2022 11:58:00 AM
    Thanks for a useful post Philip.  And it looks as though you are plugging some big  gaps in existing development/engineering insecure code bases and practices. 

    You write -  "zero trust networking can be embedded into the application layer using SDKs so that we build outbound, identity driven, E2EE tunnels from app user space to user space across any untrusted underlay networks (internet, LAN, even host OS network)"

    So this is an application layer overlay of a set of tools?  

    With the Software Defined Perimeter Working Group, over the past 5 years, reviewing V1 and looking to update, we did come to the conclusion that fundamentally Zero Trust has to be applied as close as possible to the network layer ( e.g. IPSec VPN,) transport layer protocols (SSL VPN, TLS (HTTPS)) or session layer (cookies and session management coding practices, securing ftp ) to be effective. 

    I think the worry is further coding at the application layer may provide a larger attack surface, though I am sure you are fixing some vulnerabilities. 

    I've developed an Identity-as-a-Service product, Verviam, that reworks Identity Management so that it is applied as close as possible to the network layer. The product uses multi MFA, field level encryption, daily key rotation (or more often on demand), and a triple check to ensure that today's identity token has really been authenticated before allowing access, with an optional vpn for highly classified or insecure network remote access.  

    I am the first to admit this is not perfect or foolproof, but it provides an identity federation  to existing applications, to address the coding insecurities and application access weaknesses in increasingly hybrid connectivity.

    I think we really do need to revisit networking authn and authz protocols developed last century.

    In any case Openziti looks like a good solution for specific cybersecurity weaknesses in SDKs. 

    Best Regards

    Nya

    ------------------------------
    Nya Murray
    Director
    Trac-Car
    ------------------------------



  • 3.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Aug 30, 2022 01:33:00 PM
    Hey Nya,

    Thanks for the response and comments.

    We are agreed, Zero Trust and SDP need to be implemented close to the network layer; where we differ is in our opinion that the north star should be inside the application. The nuance is that we are actually embedding into the application the ability for it to participate in a private overlay network, instead of an application needing to trust its local host network (plus local network and internet) as well as know the port and IP to communicate over host OS network, instead the app only knows how to consume OpenZiti identity (x509 and JWTs) and outbound connect into the fabric which does not listen to unauthorised and unauthenticated connections. This effectively allows the organisations to embed claims-based authentication and authorization to layer 3 to block unauthorized sessions before they can get to your network - i.e., instead of whitelist/blacklist, VPNs, bastions etc.

    I would also point out that while SDK embedded is our north star, we have some wonderful tunnelers which allow OpenZiti to run on all popular OSs (e.g., Windows, Linux, OpenWRT, Mac, iOS, etc.) as well as edge routers to deploy and run in a DMZ/VPC/VNET etc. This allows us to deliver zero trust network, host, or application access. The more embedded the overlay is, the more the attack surface is reduced. The overlay explicitly does not control the underlay. Cognisant that understanding the network is important to delivering high performance and reliability, we have built in many features which allow us to control how traffic is routed and optimised for low latency, circumvent BGP and provide multiple paths. Further, we get visibility of the underlay so that operations can resolve issues in the underlay which impact the overlay if the overlay cannot fix them itself automatically.

    Verviam sounds very interesting. It kind of reminds me of a toolset within OpenZiti which we have been developing (and is still beta) for the last couple of years. It is called BrowZer and the objective was to deliver true clientless ZT connectivity, to give users the experience of a public application while the application runs in a private environment with no inbound internet access. We achieve it by having the user interact with an internet-based HTTP agent (which backends to your IdP of choice). Once they enter the correct username/password combo from the IdP, our system injects a Javascript SDK and X509 to run in their browser without them realising and having subsequent requests go to the private app. I would be curious to have your thoughts on it - https://github.com/openziti/ziti-browzer-runtime.

    I would love to chat more about this with you and others in the community... I have found this area infinitely fascinating for over 4 years now.

    Regards
    Philip

    ------------------------------
    Philip Griffiths
    Head of Business Development
    NetFoundry
    ------------------------------



  • 4.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Aug 31, 2022 01:11:00 AM
    Hi Phillip

    That is dense information, and I shall give it deep consideration. 

    I have been thinking that you could make some really strong contributions to the voluntary Zero Trust exploration/investigation being established by @Erik Johnson - particularly the Network workstream @Jason Garbis  can you follow up?  Unless I am being presumptuous and you already embedded    :)

    I infer you have bypassed some of the clunky protocols such as BGP and that you have a control plane virtualisation that interacts directly with services (such as Lambda).

    I certainly would like to know more and will think it through.  My first thoughts: 
    How do you ensure that you do not become a single point of failure, should a concerted attack seek weaknesses in your embedding of the overlay networking?

    I have always thought that the biggest weakness of a control plane network is independently securing access controls - if I were a hostile state sponsored threat actor, I would set up a commercial Openziti network and try to sell it, of course network mirroring any traffic in which I was interested - how do you ensure that your network itself is not compromised?

    Re Verviam, about 5 years ago, looking at business services that spanned public/private/on premises network as one transaction, and the current crop of identity services were so complex, with so many undisclosed and unpublished validation mechanisms that I decided to redesign sign up and sign in to at least provide a front door with multiple reliable locks prior to access to a network trust zone because this is where I would target the capture of identity credentials.

    OK, let me think about this further, however I would like to collaborate on defining best practice network and identity principles and practices, and I think it would be of great merit, without exposing any trade secrets, to elicit your opinion on which networking practices you prioritised and targeted to secure what appears to be a ubiquitous network control plane.

    Best

    Nya



    ​​​​

    ------------------------------
    Nya Murray
    Director
    Trac-Car
    ------------------------------



  • 5.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Aug 31, 2022 02:42:00 AM
    Hey Nya,

    We are not currently talking to @Erik Johnson or @Jason Garbis ... would be great to have a chat.

    We have not bypassed the underlay (e.g., BGP); the overlay mesh brings its own routing algorithm and calculation so that if it can pick a path which delivers better performance, it will. The better way to describe it (in my opinion) is to bypass the standard BGP path given by your underlay network (e.g., Telco A) when connecting to the destination. The overlay can effectively hop across different underlay networks. The control plan allows you to extract this information in human-readable metrics (think Cisco Thousand Eyes) for the paths taken, the performance of all the paths, and the network health of all the paths. The network health allows you to infer, from the overlay, the health of the underlay and, if a problem exists, where it can be fixed (e.g., did someone misconfigure a FW rule blocking an overlay connection). Everything described above is the OpenZiti fabric. It's the OpenZiti edge which is deployed at source and destination (e.g., AWS Lambda) and makes the outbound connections to the overlay based on the embedded identity.

    To your questions:
    • Single Point of Failure: We have built many points of high availability/scale to OpenZiti to ensure it is not a single point of failure. For example, the mesh network can operate with only 1 'router' to which the edge outbound connects, but we do not recommend this. Ideally, you would have at least 2 edge routers which operate the mesh in HA at source and destination and outbound connect (and 'see') into any of the fabric routers which sit on the internet as part of the mesh. These fabric routers should also be diverse so that there are multiple redundant paths in case of poor performance on one, an internet cable cut or a DDoS attack against a node. We have a contributor to the project who is currently building an AI/ML component to self-heal (i.e., destroy a node under attack and build a new one in a non-attacked location) capability. Today we have only a single control plane, but it is fully movable today, and we are about to release HA configuration so that both the control and data plane is HA/HS. If the application has multiple instances, these are all embedded with edge SDKs (or tunnelers on the host OS), allowing HA between the application and its dedicated private overlay network.
    • Control plane weakness: I agree; I would try the same thing if I were an attacker. From the perspective of OpenZiti, this is impossible if correctly implemented. For the data plane OpenZiti implements mTLS between every single hop and between SDK to SDK (even a tunneler running on host OS is an encapsulated SDK, e.g., Windows Tunneler uses C SDK) uses ChaCha20-Poly1305 end-to-end encryption (AES256 equivalent while being lighter weight). This ensures that data is fully encrypted from E2E; whoever is hosting the data plane cannot mirror and decrypt. This is further supported by the company that is using (rather than hosting) OpenZiti to bring its own CA and keys for the data and control plane. For example, I work for NetFoundry. We provide a SaaS implementation of OpenZiti. If a customer does not want to use the CA we can generate and run on their behalf, they can bring their own.
    It would be great to collaborate further on this. From our perspective, this is why we open-sourced OpenZiti. We want anyone and everyone to be able to benefit from and build secure private networking into their business, solutions and applications.

    Regards
    Philip


    ------------------------------
    Philip Griffiths
    Head of Business Development
    NetFoundry
    ------------------------------



  • 6.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Aug 31, 2022 04:12:00 AM
    I'll give this information deep thought.

    BTW by 'single point of failure' I mean cybersecurity breaches, not network performance.  I am sure you've done a great job ensuring availability.

    Yes further communication on this performance optimisation of networking would be really useful.

    best

    Nya

    Nya Alison Murray
    Trac-Car Technology
    UK +44 208133 9249
    Australia +61 73040 1637
    Switzerland +41 22548 1747
    ----------------------------------------








  • 7.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Aug 31, 2022 04:13:00 AM
    Edited by Nya Murray Aug 31, 2022 10:44:43 PM
    @Jason Garbis @Michael Roza @Erik Johnson  - at the bottom of this post is my reason for recommending that you involve Phillip or other NetFoundry people in defining Zero Trust Networking - this is because of my long term SDP Working Group membership, addressing many points raised over the past five years of my involvement.

    OK, here is my brief analysis of the OpenZiti architecture - responding to your very interesting information, Phillip. I could be misinterpreting, correct me if I am wrong.

    1. "the app only knows how to consume OpenZiti identity (x509 and JWTs) and outbound connect into the fabric which does not listen to unauthorised and unauthenticated connections"  - this is exciting because outbound comms could be monitored and managed without messy FW and config rules, requiring just TLS certs and JWTs.  Although I note there are vulnerabilities in TLS and JWTs that could be exploited by knowledgable insiders, of whom there are sadly increasing numbers of people.
    2. At first glance it seems you have used some algorithms to improve the performance of network overlay routing (calculating in advance the most efficient virtual route for packets to go from A to B). This may or may not bypass some public internet routing mechanisms, that we know are based on processes that were designed a couple of decades ago or more. (Nothing wrong with the first pass design, except that the world was not then beset with sophisticated malicious network attacks, and therefore the design was not defence in depth).
    3. "The overlay can effectively hop across different underlay networks."  We all know that changing ICT practice that is deeply embedded, particularly networking,  is really really difficult, so I like the architecture approach that makes use of current networking practices  however adds a security layer by virtue of having a control plane that does not automatically use existing routing, and therefore making it less viable for hackers to hang around the waterholes waiting for the prey to turn up. Ye olde Wrap and Embrace not Rip and Replace.
    4. I really like the fact that the overlay can report on the underlay network. This is definitely a good thing, particularly for telecommunications.
    5.  There is an Edge network, which I presumes works like a content delivery network? So that it is possible to propagate service endpoints to the edge closest to consumption? And then relay the endpoint URIs to the appropriate delivery service, then respond to the requester through the edge? So I am guessing that by providing specific connectors at the edge, the OpenZiti fabric allows for  more visibility on connectivity to and from third parties (devices, end user laptops, B2B, P2P etc). So network monitoring algorithms in the hands of experienced security analysts as well as AI could provide a good picture of anomalies in inbound/outbound connectivity e.g. attempts at DDoS, unusual traffic patterns, patterns of source IP addressing etc.
    6. OpenZiti is deployable to an on premises data centre and therefore I presume the network listens outwardly and only allows inbound access after authentication with x509 certs and JWT?
    7. The control plane separation from the data plane.  I agree that using mTLS between hops, and presumably denying access unless authed and reporting on any config change that might seek to bypass the end-to-end encryption,  ensures only legitimate access to client endpoints, bidirectionally.

    If I have interpreted you correctly, and apologies as I am deeply involved in developing electricity and carbon emissions monitoring software, and have not had my head in networking details for at least 6 months, almost an IT lifetime :), here are my thoughts.

    Advantages
    • I like the fact that you have released an open source implementation. 
    • The agility of network path finding is a real advance.
    • So the network security, once access is achieved, is very good.
    • If I have read you correctly, edge connectivity is easily monitored prior to a service being executed.
    • The network Control Plane and Data Plane, if operated independently, make it difficult to network mirror, and the encryption keys are not shared from plane to plane.
    Questions

    How do you prevent unauthorised people from gaining quasi legitimate access?
    How do you prevent a hostile actor from setting up both control plane and data plane themselves, then offering the networking as a commercial service?

    (BTW. Verviam IDaaS was built only to address the insecurities over public internet and unknown private networks e.g. wifi, for remote users, devices, applications or workers.  Verviam security stops where the secure network starts.  So Verviam has never tried to secure an organization's applications on their existing networks (although it can federate with IDAM e.g. AD).  Therefore the Southern Cross (pardon the pun) is to secure the last mile, from the consumer to the network over public and private networks of unknown security.  The Verviam JWT has daily rotation of public/private keypair to avoid token capture, double authenticated with an authlog, token timeouts, and optional payload encryption/decryption, meaning that in the offchance of a token capture, payload contents are field level encrypted as well as TLS encrypted. Credential theft is difficult with MFA requiring knowledge of the account, the account pin, the account user ID and the account password for the daily sign in. Nobody can stop people being forced to give their credentials to someone else, but we can make it much more difficult.

    Why is this relevant? Because I designed Verviam to address what cannot be addressed by and organization's internal security measures, my question is how do you manage to stop hostile actors acquiring a network identity? This is one of the great weaknesses of Cloud SaaS platforms, because credentials themselves are lost, stolen or strayed with great regularity.  And so many of the popular SaaS applications do not rotate tokens, and do expose credentials, keys and tokens inadvertently as well as to interception. )

    Your potential involvement in defining Zero Trust with CSA.

    So the reason I think you, Phillip and NetFoundry,  should be involved in a CSA ZT exposition based on the foundation pillars of Identity, Device, Network Environment, Application Workload, and Data, is that in my experience very few people have expertise, knowledge and experience in current best of breed technology services across these domains, and the weakest knowledge, particularly for those who do not have networking background, is Network Environment.  Clearly you have in depth knowledge and skills that would be extremely useful in determining what real qualifications are required for Zero Trust computing in the end-to-end deployment context, particularly in new and evolving network paradigms.  I would be very happy to pool knowledge with you to elicit some good, simple definitions, easily understood by complying organizations, as to what constitutes Identity, Device, Network, Application and Data ZT best practice, because in my view, you cannot really separate these foundational pillars as separate components, because they are deeply dependent.   Particularly intertwined are  Identity, Device and Network.

    Please note that I think this depth of detailed knowledge is required to come up with a meaningful ZT Architecture Guide that is not just another set of observations that do not have enough technical depth to be definitive, useful and able to be deployed.  We do not need another conceptual framework, there are plenty of those already. 

    Best Regards
    Nya


    ​​​​


  • 8.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Sep 01, 2022 07:11:00 AM
    Hey Nya,

    Good summary, a couple of additions:
    1. Correct. While OpenZiti requires outbound ports 80 and 443, you could further limit to the specific IP addresses which are part of the fabric too. Then nothing can be in or out unless it is part of the overlay according to the micro-segmented policies defined.
    2. Yep, and in fact it's a great defence against things like BGP highjack (e.g., ones done recently and somehow all the traffic went to China)... the fabric would ignore that route as the latency would increase to which fabric would choose another path automatically.
    3. Similar to point above.
    4. Healthchecks and session visbility related to the specific endpoint identity (and x509) is key to giving really rich visibility as to exactly who accessed what, where and for how long etc.
    5. Re-cap, there is no communication into an OpenZiti overlay from outside. You can only participate in the overlay if you have an endpoint (SDK or tunneler, which are part of the OpenZiti 'edge') with an identity (x509 with JWT to bootstrap - https://ziti.dev/blog/bootstrapping-trust-part-1-encryption-everywhere/) which has explicitly been trusted through the bootstrapping process. Once you participate, the overlay administrator defines what services and applications you can access. The are no anomalies in inbound/outbound connectivity. A skilled operator (or user of our SaaS solution) could build further visibility of what is happening on the service / session-level. Any attempts to externally disrupt the overlay (e.g., DDoS) can be dealt with by self-healing we already have and are building. You could also build a capability to see/log anyone that fails in their attempts to access the private overlay.
    6. Outbound connectivity is established from the edge to the fabric using authentication/authorisation of bootstrapped endpoints. Once these outbound mTLS connections are established (together with mTLS between any used fabric nodes), the E2E connectivity can be initiated outbound from the source which goes inbound to the destination - i.e., it's a tunnel inside a tunnel).
    7. Agreed.
    Questions
    • How do you prevent unauthorised people from gaining quasi-legitimate access? The only people who can control the creation and bootstrapping of the edge as well as defining policy for access across the overlay (which is closed-by-default) is the operator/administrator of the control plane. This is a topic which can get very technical very quickly so probably best in a chat.
    • How do you prevent a hostile actor from setting up both the control plane and data plane, offering the networking as a commercial service? That is more difficult to defend against, but even if they did, there are mechanisms to protect an organisation using the overlay *if they use their due diligence*. There is probably some further mechanisms which can be wrapped; I am thinking along the lines of blockchain or certain RoT techniques, which could help further.
    I think also there is some potential collaboration between Verviam and NetFoundry/OpenZiti... I need to wrap my head around the architecture better... would be best to discuss live.

    Funny you mention that. We explicitly have a hiring policy for people who have strong domain expertise across security, application development and networking. While we are doing things in a different way to how many understand networks today, having this expertise is crucial to develop the future.

    Creating a meaningful ZT Architecture Guide with real world recommendations and next steps, I believe, would be advantageous to the world. I would be happy to work with @Jason Garbis @Michael Roza @Erik Johnson and the SDP Working Group on this.

    Regards
    Philip

    ------------------------------
    Philip Griffiths
    Head of Business Development
    NetFoundry
    ------------------------------



  • 9.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Sep 07, 2022 09:17:00 AM
    Edited by Erik Johnson Sep 07, 2022 09:19:43 AM

    Phillip,

    We'd love to have you and other SMEs from your organization join our recently revamped ZT Working Group, either as leaders and/or contributors. It sounds like the Network Pillar workstream might be most appropriate, but I'll leave that to you.

    The revamped Zero Trust Working Group's kick-off meeting on August 18, 2022. We discussed plans for the working group and the various workstreams we'll be spinning up to address the broad scope of Zero Trust. Participating is a great way to meet industry peers and experts who are also focused on developing and discussing zero-trust strategies, architecture and implementation guidance. Meeting Recording:   https://cloudsecurityalliance.zoom.us/rec/share/M0KeaL3HmHuy4BHUaQzHmgijfIJnK4pc3ZfiS34hQRyIsbWQPFQ7Zv__Fj6pY9oO.lFMzqGYBIa8k_pGX   - Access Passcode: CSAZTWG22!

    Kickoff DeckCSA Zero Trust 2022 Kickoff.pptx

     The kickoff initiates a 30-day public review period for the draft workgroup charter: CSA Zero Trust Working Group Charter 2022.doc

     This working group aims to help develop and socialize Zero Trust standards and guidance for secure cloud, hybrid and mobile endpoint environments. This group will have nine distinct workstreams that address specific aspects of an end-to-end ZT architecture and implementation.

    1. Zero Trust as a Philosophy & Guiding Principles 
    2. Zero Trust Organizational Strategy & Governance
    3. Pillar: Identity*
    4. Pillar: Device
    5. Pillar: Network/Environment
    6. Pillar: Applications & Workload
    7. Pillar: Data
    8. Automation, Orchestration, Visibility & Analytics
    9. Zero Trust Architecture, Implementation, and Maturity Model

    New workgroup members can sign up at https://csaurl.org/zt-signup, whether you have years of experience or want to participate as a fly on the wall, we greatly encourage you to get involved. SMEs with ZT experience are encouraged to volunteer for a leadership role for one or more workstreams if you have the bandwidth. (BTW Registering requires creating or signing into your CSA Circle or Google account.). 

    After you've signed up to join the working group you can volunteer for specific workstreams and express interest in leadership roles by emailing zt@cloudsecurtyalliance.org (if you haven't already). (We're working on a more sophisticated signup page that will enable workstream and role election at signup time but it's not yet available.)

    CSA ZT Slack:     csa-public.slack.com - #zero-trust-working-group 

     Coming events:



    ------------------------------
    Erik Johnson CCSK, CCSP, CISSP, PMP
    Senior Research Analyst
    Cloud Security Alliance
    ------------------------------



  • 10.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Sep 11, 2022 05:38:00 AM
    Hey Erik,

    Thanks. I believe I have signed up to join the working group. Will look out for the email and then volunteer for specific workstreams and express interest in leadership roles. I will also join the slack channel. Looking forward to working with you all.

    Regards
    Philip

    ------------------------------
    Philip Griffiths
    Head of Business Development
    NetFoundry
    ------------------------------



  • 11.  RE: Examples of application embedded zero trust using open source OpenZiti

    Posted Sep 15, 2022 09:48:00 AM
    Thanks. Glad to have you with us.

    No need to wait for anything to express your interest in specific workstreams and/or leadership roles.