By Thyaga Vasudevan, VP of Product Management, Skyhigh Security\n\nAs enterprises consider adoption of security service edge (SSE) solutions, they are raising questions about how best to secure data that touches the cloud in any way \u2013 whether data is accessed by or stored in websites, Software-as-a-Service (SaaS) applications, or private applications that reside in the cloud.\n\nWhen evaluating SSE vendors, it\u2019s critical to ensure their cloud-delivered security services provide consistent and unified data protection. And they follow the same corporate policies from managed and unmanaged devices and across every component \u2013 from the secure web gateway (SWG) to the cloud access security broker (CASB) to zero trust private access, and even on-premises devices.\n\nLet\u2019s take a look at some real-world examples of how various data protection technologies come into play in a data-aware, cloud-native SSE.\n\nUse case 1: medium- to high-risk unsanctioned IT applications\n\nYour executives go from meeting to meeting using note-taking software such as Evernote that syncs data to the cloud. Even though Evernote is not approved by IT and considered to be an unsanctioned application, you may still want to allow certain employees to use it in the interest of productivity. But you\u2019re worried about sensitive data being uploaded to or exfiltrated from a potentially risky application.\n\nThe best way to protect your data in this scenario is to tune your SWG policies so they are more granular or to introduce additional data security checks. You can use your corporate policy framework and apply it to an SWG, which operates inline at the network level and detects sensitive data flowing through traffic.\n\nUse case 2: sanctioned cloud applications\n\nEvery day, your employees access IT authorized, or sanctioned, cloud applications like Microsoft 365, Salesforce, Box, and other SaaS applications. In this situation, a cloud access security broker (CASB) that enforces your corporate policy offers the best protection. Even though you trust these sanctioned cloud services, you may not want users to share sensitive data across multiple applications. A robust CASB can detect sensitive data stored, in use, or in motion in the cloud and disallow sharing based on policy.\n\nUse case 3: proprietary applications in the public cloud\n\nMany DevOps teams create and deploy applications in public cloud platforms like Amazon Web Services (AWS). All too often, developers leave their S3 bucket in rewritable format, so if any sensitive data is used in that application, the data is exposed to the entire internet.\n\nLet\u2019s take a financial institution that builds an internal application deployed on a public cloud. A user accesses the application, which resides in an unsecured, rewritable AWS S3 bucket, and uploads their W2 form containing personally identifiable information (PII). If the data leaks out, the financial institution is ultimately responsible for the breach. The best way to prevent this is to leverage cloud-native application protection that blends in data context. This not only helps organizations gain visibility into sensitive data stored in the public cloud and identify vulnerabilities, risky behaviors, and malware in these applications \u2013 it also helps them automatically identify and remediate threats.\n\nUse case 4: remote access to private applications\n\nToday\u2019s work-from-home culture has proven that VPNs were never designed for tens of thousands of remote employees. Additionally, VPNs offer minimal data protection at higher costs.\n\nZero trust network access (ZTNA) solutions directly connect your users to authorized private applications by applying least privilege, zero trust principles. The problem is many of these solutions miss out on data context. For example, employees may be using their corporate-issued laptops to access GitHub, but they failed to update their antivirus, so their devices may have vulnerabilities. You don\u2019t want to block these users from being productive and doing their jobs, so you can route them to a remote browser isolation session. That way, to the user, it\u2019s seamless and they can view GitHub or other approved applications, but they cannot download anything. You can extend this technology to your on-premises endpoints and unmanaged personal devices and apply the same policies across the board.\n\nWhen you\u2019re evaluating an SSE vendor, make sure their built-in data loss prevention (DLP) technology protects data on the cloud, by device, and on premises through consistent policy enforcement and data classification. DLP technology needs to be cloud-native and incorporate unified policies that are integrated across SWG, CASB, ZTNA, and remote browser isolation (RBI). It needs to be intelligent enough to apply these unified policies and controls to block multiple attempts to exfiltrate data. \n\nIdeally, an SSE should provide a single DLP engine with a single centralized management and reporting dashboard, a single policy framework across all data exfiltration vectors, and a multi-layered set of security technologies that cover all possible use cases across your environment.\n\nTo learn more about Skyhigh Security\u2019s approach to DLP in the cloud, click here.