The 3D approach to User Identity

Most of us are certainly familiar with the notion of 3D video.  It has gained tremendous popularity over the last decade, with more and more blockbuster motion pictures being screened in 3D.  Why is 3D gaining such popularity, and what is the main benefit that 3D adds over traditional flat 2D?  The answer is simple – it’s all about the depth perception.

The ability to take user identity into account while granting access to applications has been a core staple of the Zero Trust security principle, as well as a feature of many next-generation firewalls (NGFWs), for many years. Secure Web Gateways, or SWGs, also have similar functionality to identify users that are accessing web traffic in order to:

• Provide visibility and mapping between users and the applications they use/sites they visit
• Enforce policy control by allowing certain users to access certain applications
• Increase efficacy of forensics by analyzing which applications are accessed based on user information rather than just IP address

However, the approach that all these security products take focuses on the user identity that is associated with the endpoint itself, like an Active Directory username that is logged into that Windows or Mac device.  But is that enough to successfully achieve the objectives outlined above?  Does a single-dimensioned user identity give you enough visibility and control to safeguard sensitive data that is moving from your enterprise to the cloud?

If we go back and look how enterprise applications were structured and consumed 10 years ago, we realize that the vast majority of applications were hosted within the customer’s perimeter.  On-premises versions of Exchange, Sharepoint, Skype For Business, PeopleSoft, Oracle, etc. – that is what the enterprise used for their day-to-day activities.  As such, NGFWs were an effective tool in controlling access and providing visibility around enterprise application usage.  This was possible because the apps resided within the enterprise perimeter, making it possible to identify users who went to their own application instance for email, collaboration, HR, CRM, ERP, etc. 

However, the application delivery and consumption model has rapidly shifted over the last 5-7 years, and Netskope research shows the average number of cloud services has surpassed 1,000.  Even after accounting for the fact that some services are embedded by others, as well as a number of applications that allow unauthenticated/anonymous access or execution, the number of unique authenticated application services the average enterprise sees on their network is growing.  And your NGFW or SWG is showing which endpoint users are accessing those applications (although many are not able to identify all of the applications in use). 

But let’s assume that we are going to equalize things as much as possible to compare apples-to-apples scenarios.  Pretty much all NGFWs and SWGs can identity mainstream SaaS applications such as Office 365, Box, Dropbox, Salesforce, Oracle HCM, Workday, etc.  However, when it comes to identity, all they can do is report the user identity associated with a particular endpoint has accessed Box, Office 365, Dropbox, etc.  All those applications have their own logins that don’t always easily correspond to the network identity of the user.  There are still a fair number of enterprises who make their user network ID something cryptic, such as abc123 – which is not easily mappable to the user account in the SaaS applications. 

Furthermore, as applications such as Salesforce become de facto standards in their space, enterprise users find themselves using multiple instances of those applications.  For example, a company that’s using Salesforce.com as their primary CRM tool will have its user accounts mostly formed as corporate email addresses in their Salesforce instance tenant. However, because of its power, flexibility, and popularity, the Salesforce platform is used by many enterprises to collaborate with other B2B partners – by requiring them to log in to the partner’s Salesforce instance. So, when a NGFW or SWG reports that a user mkoyfman went to Salesforce.com, it has no idea if the user accessed the corporate sanctioned instance of Salesforce, or one of their partners, or one of their competitors (if they just accepted a job there and are trying to exfiltrate customer data).

Before we go further, let’s try to draw a parallel analogy to how identities are tracked in the real world outside of IT.  As we enter our car and embark on traveling the network of roads and highways, our identity (driver’s license) has been granted access to drive a vehicle.  That vehicle is moving from point A to point B via roads (the network). The law requires the vehicle have a license plate, which can obviously be traced to the registered owner of the vehicle (network user logged into the endpoint). 

Now imagine that the car commits a moving violation, such as running a red light or speeding.  Many of these violations are enforced by automated cameras that capture – you guessed it – the license plate number of the car.  The citation is then sent to the registered owner of the vehicle.  But who was driving the car at the time of the violation?   There isn’t any proof or guarantee that the registered owner of the vehicle was the one driving the car at the time of the violation if enforced/cited only via the automated camera method.

We are faced with a similar challenge in enforcing an identity-based security approach.  All solutions are able to tie [network] user identity (the registered owner) to the endpoint (the car).  But how do we know what identity/account they use to access SaaS applications?  Did they log in and upload documents to a personal or corporate instance of Office 365, Box, etc.? 

Netskope inline capabilities with CloudXD allow us to provide customers with three-dimensional user identity-based policies.  What does it mean?  First and foremost, Netskope leverages endpoint-based user identity and applies policy based upon it, and also provides visibility into all the applications being used by that endpoint user.  However, this is where the similarities between Netskope and any other inline real-time security vendor end, and the next-generation user identification abilities kick in. Netskope CloudXD is further able to extract two very important user identity parameters – the user identity of the actual application the user is using, and, for relevant actions, the user identity of the application action that is being directed. 

How does this look in action?  For example, let’s assume that I am logged in to my corporate-issued laptop with my Active Directory username mkoyfman.   I then access and login to my personal Box account (despite the fact that I have corporate-issued Box account) with the username [email protected].  I then upload some files to Box, and decide to share them with [email protected].  The application event log action that Netskope CloudXD captures would reflect the exact details of this action – that endpoint with IP address x.x.x.x associated with username mkoyfman had access to Box while authenticated to Box as [email protected] (let’s call this from user)and shared a particular exact file or folder with [email protected] (let’s call this to user).  So, at the end, all application actions and page events are logged either in two-dimensional (endpoint user identity and logged-in application identity) or three-dimensional (endpoint identity + logged-in application identity + identity of whom the action is directed at).

I hope you can easily see how such rich multi-dimensional approach to tracking and authorizing access based on user identity can help you succeed with safely adopting cloud services for your organization, and if you want to see this in action, feel free to request a live demo of this capability today.