Continuous Access Evaluation and Session Management.

Check this video for an audio/visual version of this blog and a demo of the new features

A quick level set

Before we dive in, let's do a quick level set and discuss why people use mysocket:

Think of mysocket as a zero-trust (sometimes, clientless) remote access VPN replacement. It does this by providing the following:

1) authentication and identity, by integrating with existing identity providers

2) authorization, by specifying zero trust access rules, ie which identity (or groups of identities) have access to what resources.

3) network (data plane) access, provided by the secure, outbound only tunnel between the origin server and our anycasted edge servers.

In other words, we are combining the remote access VPN use-case with an Identity aware firewall that provides per-flow identity; access is determined based on identity, not based on IP addresses. Think of the Mysocket servers as a middle man, a bouncer that continuously checks who (identity) is allowed to talk to the private and protected resources.

Ok, with that out of the way, let's take a look at the latest features: Continuous Access Evaluation and Session Management.

‍

‍

‍

‍

Session Management

As a security administrator, it's crucial to answer questions such as: who visited what resource, when, and from where. These are often questions that need to be answered for practical reasons, but they're also mandatory for various security compliance programs.

I'm happy to announce that as of this week, you'll find a new tab on the socket details page. This tab shows a live list of all sessions, start time, end time, the identity, and from where the user was using the service. The session data is updated every few seconds, so administrators always have an up-to-date overview of ongoing sessions.

Finally, this information is available through the API at https://api.mysocket.io as well, making it easy to integrate with your compliance and monitoring tools.

‍

Continuous Access Evaluation

Sessions are created after a user successfully completes the authorization phase. One thing worth noting is that Mysocket edge servers are looking at every request and continuously evaluate whether access should be granted or not. So, access to resources isn't just set during the initial log-in, but evaluated at each request passing through our network. Why is this important?

Imagine the use case where somewhere along the way, the administrator is changing an access policy. When joe@contractor.com logged in at 9 am, he had access, but at 10 am, the administrator hears the engagement with the contractor has unexpectedly ended. As a result, the administrator is removing  joe@contractor.com from the mysocket zero-trust access policy.  A typical login session cookie is valid for a few hours, meaning the contractor would continue to have access until the session expires. It's easy to see why this is bad!

However, since mysocket is doing continuous access evaluation, every request is going through the authorization phase each time it passes through our network. This means that even though the login session is still valid, this merely informs the mysocket servers that we can be sure about the contractor's identity. Which is then compared to the latest authorization policies, and since the contractor was removed, access will be denied.  Best of all, the propagation of authorization policy changes is completed in a matter of seconds, ensuring your policy changes are enforced in real-time.

The problem of Long-lived session.

Great, every request is evaluated against the current authorization policies. I.e., every single HTTP request or any new TCP/TLS session is always checked. This leaves us with one corner case, long-lived sessions. Examples of long-lived sessions include SSH sessions or downloads of big files.

To solve this challenge, we've introduced the ability to terminate sessions.

The screenshot above shows all sessions for a socket. Users can 'end' and a session by clicking the "Terminate Session" link.

What happens under the covers is that as soon as this link is clicked, it will be marked as "to be terminated" in our back-end systems. This action feeds into our policy distribution engine, which will make sure the termination request is distributed to all edge servers. Typically it takes about two seconds for the termination request to be fully processed by all edge nodes globally.

We've further extended the Continuous Access Evaluation code, to also look at the "session termination status". This means that not only does a user need to have the correct permissions, it also requires the individual session to be in good standing. Termination of a session means the session is invalidated and as a result, the user is forced to log in again. Make sure to watch the video at the top of this blog to see this in action.

Network flow termination

Finally, when the edge nodes receive the termination request, it will also kill any live TCP sessions associated with this session. By doing so, long-lived sessions such as SSH are continuously evaluated and destroyed when requested by the administrator. You're indeed killing live TCP flows based on the user's identity and session status, with the click of a button, pretty cool, right?!

Looking forward.

Terminating a session from the portal is cool and useful, but it's just the beginning. The portal is completely stateless and all actions are directly handled by our underlying public API. This means that session management is a fully supported API feature and can be used by future, more advanced features. For example, one could imagine a future application, possibly custom to your organization, that is using our RESTful API to analyze all sessions in real-time and may terminate sessions when they're considered suspicious or otherwise out of policy.

‍

Wrapping up

In this blog, we looked at session management. We started by going over the continuous access evaluation features of mysocket. We saw how each request is evaluated to ensure the identity requesting access does have the correct permissions. Continuous access evaluation allows administrators to make permission changes and have them be live in real-time.

We saw how mysocket is logging all sessions in real-time and how they're accessible via both the API and the portal. Giving you the ability to have up-to-date information about who is accessing what resources, when, and from where.

Finally, we demonstrated the ability to terminate sessions from the portal. This is a great feature to help us terminate long-lived TCP sessions such as SSH sessions. Or revoke access to previously approved sessions, forcing a user to log in again.

I'm pretty happy with the results. Building this required quite a bit of architectural changes and made the service as a whole better and increasingly more reliable. I'm confident that the ability to make changes to sessions in real-time will continue to pay off going forward.

‍