About nine months ago, I posted the first blog post on the mysocket website, announcing mysocket. The mysocket service has continued to evolve over the last year, both in the underlying technology, vision, and use cases. I figured it's time for a bit of a refresh and clear articulation of what Mysocket is, what problems it is solving, and where it is heading.
About nine months ago, I posted the first blog post on the mysocket website, announcing mysocket. The mysocket service has continued to evolve over the last year, both in the underlying technology, vision, and use cases. I figured it's time for a bit of a refresh and clear articulation of what Mysocket is, what problems it is solving, and where it is heading.
Mysocket is a Zero-trust Private Access solution that replaces the existing remote access VPN solutions with an Identity based zero-trust style alternative, similar to Google Beyond Corp. Private access, without the frictions and downsides of the traditional VPN.
I think of Mysocket as an identity-aware firewall, where every network flow has an identity attached to it. While traditional firewalls allow or deny access based on IP addresses and port numbers, Mysocket uses actual user identities and service definitions, which are much more intuitive! On top of that we also, provide session application recording and session management. This is how we make sure every connection is secure in the context of each interaction.
The problem with traditional VPNs is that the level of access is often much too high. Imagine an example where a particular user needs access to the wiki and a Git server that happens to run in one of your private networks, either on-premise or in a cloud VPC.
By connecting to the VPN, the user becomes part of that remote network and can suddenly access everything on that network. While in an ideal world, the user should only have access to just those needed services, something that's not easily achieved with your traditional VPN. In fact, typically, when the user is connected to the VPN, you have no idea and little control of the lateral movement.
Then there are the additional challenges of 3rd party contractors or business-to-business type use-cases. For those types of users, you'd need to onboard a contractor to your local (active) directory or IDP service. This can be a burden on your team while making things slower and harder. Now, these external users suddenly have corporate credentials, and ooh btw, who will make sure those users get removed at the end of the assignment?! Not ideal...
Identity is the new perimeter, so ideally, we'd easily integrate with existing 3rd party identity providers and allow even for clientless access methods (ie. no VPN client needed), making it easier to use while maintaining an appropriate security posture. This is exactly what Mysocket aims to provide.
Mysocket operates a fleet of custom and anycasted, application-aware proxies that take care of authentication and policy enforcement (authorization). These proxies are currently hosted in the cloud, as a service, for customers. Think of mysocket as a bouncer that checks your Identity and stands between the resource and the users, only traffic from authorized users is passed through. Because these proxies are application-aware, they can provide application-specific policy enforcement and session recording. One example is the ability to replay the recording of an SSH session.
Authentication is achieved by integrating with existing Identity providers, either through the OpenID Connect protocol (Google, Github, Microsoft) or the existing enterprise directory service with SAML.
The connection between the proxy and the protected resource is an encrypted outbound connection initiated by the protected resource, or an intermediary node acting on behalf of the protected resource(s). As a result, the protected resource doesn't need to accept any inbound network connections and only accepts authenticated and authorized connections via the encrypted Mysocket tunnel. This means that the resource can be behind strict firewalls or even behind NAT, like in a private VPC scenario.
When a client connects to the protected resource, it's prompted for authentication and can log in with the organization's Single Sign-on credentials; once successful, the mysocket proxy will facilitate the connection on behalf of the resource while monitoring the session's behavior.
So how are we building this? The picture below is a representation of what we’re using as our architectural north star.
On the top, we see the end-users. These are the users trying to access private resources, for example, your corporate wiki or git server. Depending on the type of resource and authorization requirements, access can be completely clientless, or access is established with the help of our client mysocketctl.
To get access to the private resources, we'll need to determine the user's identity first. This is what the identity-based firewall does. Here we make sure that the user is authenticated and authorized by policy to access the private resource. The user's identity is verified by leveraging your current Identity provider. Today we support OpenID connect with the common Single Sign-on Providers and soon will add SAML support.
Next up, traffic is handled by one of the application-aware proxies. This can be a TLS proxy for generic TCP services or application-level proxies such as HTTP, or SSH, and soon SQL.
At the bottom, we have the Secure dataplane tunnel service. This component is responsible for the encrypted tunnel between the private resources and Mysocket. Only authorized flows with established user identities are proxied between the end-user and the private resource. And since the secure tunnels are initiated by the private resource, this means that the resource can be hosted in private VPC's, behind strict firewalls and even NAT, where they're not directly accessible from the Internet. In other words, your private resources can be made available to mysocket users and replace your traditional VPN.
Finally, we have the Policy Engine on the left. This informs the Identity-based firewall and application-aware proxies who has what type of access to the resources. On the right, we have the reporting engine responsible for logging all network connections, identities, and session recording (for example, SSH session replay).
Depending on the level of visibility and enforcement needed, traffic is routed through one of the supported application-aware proxies. We currently support HTTP(s) and SSH proxies and have started work on an SQL proxy. For any other application, we support the generic TLS proxy. You can think of this as a per-application TLS VPN tunnel.
The advantage of these application-aware proxies is that we actually understand the traffic that’s passing through. This means we have the opportunity to do application-specific logging and allows us to record things like:
User Joe made an HTTP POST request to wiki.corp.com/private/account at 3 am while visiting from an ISP in Russia, geolocated to Moscow. Or in the case of SSH, we can record the complete SSH session, which can later be replayed. In other words, it allows administrators to answer typical compliance questions such as: who did what, when and from where.
Another advantage of application-aware proxies is that we can start to enforce application-aware policies. Examples include: user Todd is allowed to do HTTP GETs on wiki.corp.com/private/ but should never be allowed to do a POST request. Similarly, for SSH, user jane is allowed to SSH to bastion.corp.com as user support but not as user root, and no SSH port-forwarding is allowed. These are all simple examples, and it’s not hard to imagine what is possible when we start to combine these policies with dynamic context-aware parameters (where is the user coming from, is this normal, on what device, posture assessment, etc.).
By now, it’s clear that we aim to enable the administrators to define detailed access policies, integrate with existing Single Sign-on providers, and provide the resource owners with detailed access logs. All on a per-resource/application basis.
Policies can change at any time, and so it’s important that access to resources is continuously evaluated. Not just at the session start or during the log-in phase like many other solutions. This is especially important when taking into account dynamic policies such as device or user posture assessment.
Mysocket provides Continuous Access Evaluation. This means access to resources is evaluated at each request, not just during the log-in phase. This allows for changes to access policies to be immediately active, improving the security agility.
In addition, the administrator can see all sessions in real-time and can terminate sessions from the dashboard. Sessions are logged and recorded so that the administrator can see all the access logs and can replay ssh terminal sessions when needed.
The continuous access Evaluation feature allows sessions to be killed at any time, either through the portal or with an API call. This allows for some interesting integrations with existing Threat Intel systems or SIEM systems that can at any time decide to kill a user's connections in real-time when these systems believe that connection or user's device can no longer be trusted. That's a really powerful feature! Also, see our blog post on Continuous Access Evaluation and Session Management.
As more organizations embrace hybrid-cloud and now multi-cloud architectures, workloads are running in different regions, using multiple cloud providers and on-prem data centers. With the rise of the cloud and the explosion of more data sitting in more places and more people needing access, the traditional approaches to control access have stopped working. There is no more perimeter. Access control policies, Identity management, and monitoring are challenging to do uniformly and consistently. The result is that the overall security and compliance posture are negatively affected.
Using Mysocket, we can take back some of that control. By moving to a zero-trust architecture, organizations are improving their security posture and accelerating their compliance journey. It's like Google Beyond-corp but for your environment.
Common challenges these users face include shared passwords, periodic key rotation, session recording, and knowing who did what, when. These challenges are all taken care of by using Mysocket. This will free up valuable time for the engineering teams, allowing them to focus on customer value without being bogged down by the weight of compliance and security.
We'll continue working towards our vision and make it super easy to deprecate the use of the traditional VPN in favor of moving to a zero-trust, beyond-corp model. Making it easy for you, your employees, and third-party contractors to access private resources deployed in the various infrastructures your company may use, including on-premise, in private data centers, and the public cloud.
Keep following our blog, or feel free to reach out if you have questions, ideas, or just want to share experiences on this topic. I’m always happy to chat!