Cloud Forensics in Offline Modes: You Don’t Have to Run Faster than the Bear

Cloud Access Security Broker (CASB) solutions can be deployed in many modes, ranging from offline log ingestion, TAP, or API access to in-line forward or reverse proxy with or without thin agents. They are all legitimate deployments that satisfy a plethora of use cases.

Many customers deploy first in offline modes to get a lay of the land. Offline can be great for discovering what apps you have in use in your environment and evaluating the risk of those apps. If you go beyond log-based discovery to Introspection using API access, you can peer into a sanctioned app to understand the content within it and whether that content violates your DLP policies like protected health information (PHI), personally-identifiable information (PII), payment card industry information (PCI), source code and more.

However, it’s not great if you want to understand exactly what’s going on in your environment and say deterministically whether there’s been an event, e.g., data exfiltration, theft, or exposure.

So what do you do if you’re only in log mode? Here are three things I look at when helping our customers sort through their data. The thing to remember, though, is that in absence of the full visibility you get with inline deployments, you can learn an awful lot and you know where to dig next or whom to ask those important questions. And because you can filter down to the most relevant risky issues, you don’t have to deal with an overwhelming amount of data. In other words, you don’t have to run faster than the bear; you just have to run faster than your friend.

1. Sensitive content that’s externally shared. When our customers deploy Netskope in Introspection mode (use APIs to scan content within sanctioned apps), they can find sensitive content and usually see an audit trail of that content, including whether it was downloaded or shared, and by whom. This is deterministic in that the customer will definitely know who did what, and can immediately remedy the situation by removing external links or locking down the content with encryption.  
2. Significant downloads from sanctioned or business-critical apps, followed by similarly-sized uploads to personal apps. One thing our customers often find when performing analysis using log data is large downloads (they usually start with the arbitrary query, “Show me all downloads from Cloud Storage, HR, Infrastructure, Finance…[or another important app]… larger than 10MB,” and by filtering down to a manageable number of activities, they easily query to understand what users did next. Did they have a similarly-sized upload to personal Dropbox or personal Gmail? If so, that’s interesting. It may be perfectly legitimate, but it narrows the field from millions of potential violations to a handful of interesting events on which to follow up.
3. Regular backups to unsanctioned apps, preceded by downloads from apps that contain sensitive data. The opposite of Cloud Storage, in which a share or a download is interesting, and where the next question you’d want to ask is “Then what?,” is Cloud Backup. In Cloud Backup, upload is interesting, and the question to ask is “What before?” A common scenario is that users procure Cloud Backup solutions (often with the best of intentions – to protect data from corruption or loss in the event of computer loss or failure). Cloud Backup apps are almost always unsanctioned by the organization, and users sometimes “set it and forget it” to back up their entire computer incrementally over time, which means the apps nearly always fly under the radar. What people don’t think about is that, no matter what those users download – a .CSV extract from an HR app to perform compensation analysis, a customer list from a CRM app, or next year’s M&A plan from SharePoint or OneDrive – all of that sensitive content will get backed up to the Cloud Backup app. One way to understand the risk of sensitive data in Cloud Backup apps is to query to understand whether sensitive data were downloaded to a user’s device prior to a backup. This is easy. One customer found a user had downloaded several files from DocuSign – an app containing only proprietary contracts – just prior to a backup to a poorly rated, unsanctioned Cloud Backup app…on multiple occasions.

Possible remediation steps can range from a tap on the shoulder to the potential violator to an offline policy instantiated in Introspection (such as “no sharing PHI”) to an in-line, activity-based policy such as “Only upload PCI if it’s to my corporate-sanctioned app; otherwise block it from being uploaded to any other Cloud Storage app at a category level.”