Bringing the Second Netskope Patent to Life: The Life of a Cloud Transaction

Today, we announced that we have been issued our second comprehensive CASB patent for delivering granular visibility and enforcing granular policy and data security for cloud delivered services. This patent complements the first by recognizing our unique ability to enforce cloud policy controls at a granular level, enabling IT to move beyond a coarse-grained “allow” or “block” approach to cloud services toward enforcing fine-grained policies based on a variety of conditions including deep cloud context and the the associated activities and data. In this blog, I’ll walk you through the life of a cloud transaction to help bring this patent to life with a real-world example.

If you Google the term “life of a packet,” you get almost 50 million results, explaining everything from how routing works to the ins-and-outs of a SYN flood attack. For decades, a large part of our security conversation has been focused on network traffic.

Today, we are focused on cloud security. Forrester predicts that companies will spend more than $2 billion over the next five years to secure data in the cloud, while Gartner names cloud access security brokers its number one information security priority.

The cloud (and a lot of the web) has moved beyond the language of the network. Rather than speaking in HTTP gets, HTTP POSTs puts, and bytes up and down, the cloud and web speak the language of APIs. The beauty of APIs is – besides being incredibly useful for integrating services faster and more efficiently – they are reflective of the activities we actually do in the cloud. This means that when we view, share, download, upload, approve, edit, post, or create in a cloud service, we are actually doing those things via API calls.

So why are many security vendors (including some cloud access security brokers) still speaking that old language? At Netskope, we have perfected the skill of decoding this language, whether it’s being used in a sanctioned or unsanctioned app and whether it’s originating from a desktop, remote laptop, or mobile device. By decoding APIs, we’re able not just to see activities in a handful of sanctioned apps, but across all apps, as well as also ascertain a host of additional contextual metadata about users, devices, apps, times and locations, and content. Beyond decoding APIs, we also normalize them across cloud apps. When you “share” an object such as a file from a cloud app, that activity may result in different API calls depending on the app implementation. Even the wording could be different – it could be “share” in one app, “Create a share link” in another, and “Invite to collaborate” in yet a third. If you’re enforcing policy in just one app, that’s fine, but if you want to enforce a policy such as “Don’t share content outside of the company from ANY file-sharing app,” you need to set it at a category level to have it apply across the dozens of file-sharing apps you have running in your organization. That’s why not just decoding the “share” is important, but normalizing the “share” across many different types of apps is also critical.

Let’s look at the life of a cloud transaction in four simple steps:

We’ll start with a user login to a website or cloud app. In your proxy logs, that login activity consists of small byte transfers associated with a secure handshake and passing of credentials. But you can’t see this. In fact, those byte transfers could be a simple website visit or even a triggered tracking link in an app from a website the user visits when they didn’t even go to the app. In contrast, in the Netskope Active Platform, we tell you it’s actually a login. Moreover, we’ll give you all of the context about that login that you’d care about as an IT or information security professional: Who is the user? What enterprise directory group are they in or attributes are associated with their identity? What website or app are they logging into? What category of service is it? What is its risk level? Why is knowing the user activity and its context important? For one thing, a login versus a simple website visitation shows intent and signals the beginning of a transaction that you may care about. Also, context matters! What if the cloud app in question is your company’s benefits and payroll app containing sensitive information, and the user is not even in HR? What if the app is your payment authorizations app and subject to Sarbanes-Oxley, and the user has three failed logins? When you have context, knowing that the activity is an actual login becomes important.

Next, let’s look at a download. Your user just downloaded something from the website or app. In your proxy logs, that download looks like a series of HTTP “GETs” and has some “bytes down” associated with it. That GET could be the user accessing an important file or…a cat video. You don’t know. In a proxy log, a cat video can look similar to your mergers and acquisitions plan. In the Netskope Active Platform, we tell you not only that a download happened, but also what the downloaded object was (a file, report, database extract, etc.), its name, who downloaded it, to what device, on what browser, at what time and location, and whether the content is sensitive based on your DLP profiles, as well as take a hash of the content. We have done the work to determine not just what the activity “download” looks like in a single app, but across all apps because we have decoded the API and know what it looks like across thousands of apps. So, whether a user is downloading from a social media website, file-sharing, or business intelligence app, Netskope knows it’s a download and can tell you all about the transaction. Netskope can also help you stop it in its tracks with a real-time policy. But for this exercise, let’s assume you don’t and keep going…

Now, let’s take a look at an upload. Remember that download that just happened? Well, let’s assume it’s a highly sensitive document containing next year’s product plans, and that the user has just uploaded it to an unsanctioned, personal file-sharing app. In your proxy logs, that activity looks like a “POST” and has some “bytes up” associated with it. That’s useful if you care about bandwidth, but not so much if you care about security and want to follow up on suspected data theft incidents. Is that upload related to the download from before? You can’t tell. In fact, since you are unaware of the download in the first place, much less whether the content was sensitive, neither transaction would be on your radar. You’d be in the dark about whether there was content transferred at all, whether it is sensitive, and whether the download and upload transactions are related. In the Netskope Active Platform, since we take a hash of the file during download and know exactly who downloaded it and when, when the user re-uploads the same sensitive content, we know it and flag it for you. Now you’d know that a download occurred, followed by an upload of the same content, the fact that the content is sensitive, and you’d know who did it, as well as dozens of other details about the two transactions.

Finally, let’s look at a share. Remember that sensitive content upload? You know the one – next year’s product plans that were, just minutes ago, safely at rest in your sanctioned app. Well, guess what! The user just shared them with your company’s biggest competitor competitor. In your proxy logs, that share activity would have some very small bytes transferred up and down, and would completely fly under your radar. Not only would you not know it’s a share, but you wouldn’t even know to look for it because you didn’t even know the download nor the upload happened, and that they were related. In the Netskope Active Platform, since we take a hash of the file during download and know exactly who downloaded it and when, and the fact that it’s sensitive based on your DLP profile, when the user re-uploads the same sensitive content, we know it and flag it for you. Then, when the user shares it, we tell you that, as well as who they shared it with. You could even start with the share and ask to see all shares, or all shares with a particular competitor. We do this whether the share is in your sanctioned file-sharing app or a completely unknown, unsanctioned app in any category. Now you’d know that three related events happened: a download, followed by an upload, followed by a share of your most sensitive content…and shared with your primary competitor, no less! You’d know who did it, and have all of the context about the user, device, app, and content.

This is what it means to decode and normalize the language of today’s cloud – APIs – and to track the life of a cloud transaction from beginning to end.