Patent Application
20250202926
The present disclosure is a continuation-in-part of the following U.S. patent applications, the contents of which are incorporated by reference in their entirety:
The present disclosure relates generally to networking and computing. More particularly, the present disclosure relates to cloud-based Data Security Posture Management (DSPM).
As enterprises increasingly adopt cloud computing models, sensitive data becomes distributed across multiple platforms, including Software as a Service (Saas), Infrastructure as a Service (IaaS), hybrid and on-premises deployments, databases, object stores, and other proprietary environments. Traditional security solutions, such as Cloud Access Security Brokers (CASBs), often focus on controlling access to cloud applications rather than providing deep visibility into how data is stored, accessed, and handled. The complexity of multi-cloud ecosystems and the proliferation of sensitive information pose significant compliance and security challenges. Organizations must ensure that sensitive data is discovered, classified, and continuously monitored for potential threats, misconfigurations, and compliance violations. These organizations require more holistic approaches to security posture management, ensuring that sensitive data remains properly protected, access is restricted to authorized users, and compliance with regulatory frameworks is consistently maintained. Therefore, there exists a need for improved systems that provide a data-centric view of security, enabling continuous risk evaluation, automated policy enforcement, and comprehensive reporting. By shifting from an access-focused to a data-focused model, organizations can effectively safeguard their sensitive data and reduce the risk of breaches, unauthorized disclosures, and non-compliance.
In an embodiment, a method, instructions in a non-transitory computer-readable storage medium, and a cloud-based system are presented to perform steps. The steps include discovering and classifying any of data discovered by inline cloud inspection, data stored across one or more cloud services, and data stored across one or more endpoints; continuously monitoring access to and usage of classified data, wherein the monitoring is performed in real-time and includes analyzing data access patterns, user behaviors, and application interactions; evaluating a security posture of the classified data by identifying misconfigurations, compliance violations, excessive permissions, and vulnerabilities; and enforcing one or more security policies based on the evaluated security posture.
The steps can further include generating compliance reports and audit logs reflecting data handling practices and security policy enforcement. The compliance reports can include dashboards and visual analytics tools for reviewing detected anomalies, remediation actions taken, and overall compliance posture over time. The discovering and classifying can include identifying sensitive data based on predefined or customizable classification policies. The policies can include at least one of restricting access, encrypting data, or alerting security personnel. The discovering and classifying can further include scanning data assets in one or more of Software as a Service (Saas) platforms, Infrastructure as a Service (IaaS) platforms, on-premises data stores, databases, object stores, or private applications. The monitoring can include utilizing machine learning to establish baseline data access patterns and detect anomalous behavior that indicates insider threats, unauthorized access, or data exfiltration attempts. Enforcing one or more security policies can further include applying Data Loss Prevention (DLP) to block or redact sensitive information, and automatically implementing encryption or revocation of access privileges in response to detected anomalies. The discovering and classifying can include integrating with Cloud Service Provider (CSP) Application Programing Interfaces (APIs) and native connectors to scan storage services, databases, containers, and virtual machines for data. Evaluating the security posture can include identifying misconfigurations in cloud storage buckets, improper Identity and Access Management (IAM) settings, or ineffective encryption measures.
The present disclosure is illustrated and described herein with reference to the various drawings, in which like reference numbers are used to denote like system components/method steps, as appropriate, and in which:
Again, the present disclosure relates to cloud-based Data Security Posture Management (DSPM). Various embodiments focus on discovering and classifying sensitive data, continuously monitoring data usage, identifying misconfigurations and compliance violations, enforcing policies to protect and control access, and generating compliance reports and audit logs for regulatory adherence.
Also, the present disclosure relates to systems and methods for Data Loss Prevention (DLP) expression building for a DLP engine. As described herein, a DLP service or system can utilize one or more dictionaries. A DLP dictionary is a set of data that includes specific kinds of information that are monitored for in user traffic. A DLP engine can include one or more DLP dictionaries that are used for detection. The present disclosure includes utilizing expressions to combine one or more DLP dictionaries in the DLP engine to provide an aggregate result. The DLP dictionaries can include predefined dictionaries and custom dictionaries. The present disclosure includes a user interface for users to enter expressions, evaluate the expressions, and store the expressions in a database for use in production.
Also, the present disclosure relates to systems and methods for Data Loss Prevention (DLP) via Indexed Document Matching (IDM). As described herein, IDM is the ability to identify and protect content that matches the whole or some part of a document from a repository of documents. This feature provides data leak protection for unstructured documents. Specifically, techniques include identifying exact document matches, identifying the same text in a document as in an indexed document, identifying content that contains a subset of text in an indexed document, and identifying content that is similar but not exactly the same as the text in an indexed document. Customers can index files into multiple user-defined profiles or categories. The results of the identification can yield a score that can be matched to a threshold for detection. The technique can be summarized as similarity detection (i.e., same file, same text, similar text, etc.) and fragment identification (i.e., partial content match) to provide a score that is indicative of a match to an indexed document. As described herein, IDM means performing matching of a target document to indexed documents. The objective is to flag (detect) documents that are close, but not exact to the indexed documents.
The cloud-based firewall can provide Deep Packet Inspection (DPI) and access controls across various ports and protocols as well as being application and user aware. The URL filtering can block, allow, or limit website access based on policy for a user, group of users, or entire organization, including specific destinations or categories of URLs (e.g., gambling, social media, etc.). The bandwidth control can enforce bandwidth policies and prioritize critical applications such as relative to recreational traffic. DNS filtering can control and block DNS requests against known and malicious destinations.
The cloud-based intrusion prevention and advanced threat protection can deliver full threat protection against malicious content such as browser exploits, scripts, identified botnets and malware callbacks, etc. The cloud-based sandbox can block zero-day exploits (just identified) by analyzing unknown files for malicious behavior. Advantageously, the cloud-based system 100 is multi-tenant and can service a large volume of the users 102. As such, newly discovered threats can be promulgated throughout the cloud-based system 100 for all tenants practically instantaneously. The antivirus protection can include antivirus, antispyware, antimalware, etc. protection for the users 102, using signatures sourced and constantly updated. The DNS security can identify and route command-and-control connections to threat detection engines for full content inspection.
The DLP can use standard and/or custom dictionaries to continuously monitor the users 102, including compressed and/or SSL-encrypted traffic. Again, being a cloud implementation, the cloud-based system 100 can scale this monitoring with near-zero latency on the users 102. The cloud application security can include CASB functionality to discover and control user access to known and unknown cloud services 106. The file type controls enable true file type control by the user, location, destination, etc. to determine which files are allowed or not.
For illustration purposes, the users 102 of the cloud-based system 100 can include a mobile device 110, a headquarters (HQ) 112 which can include or connect to a data center (DC) 114, Internet of Things (IoT) devices 116, a branch office 118, etc., and each includes one or more user devices (an example user device 300 is illustrated in
Further, the cloud-based system 100 can be multi-tenant, with each tenant having its own users 102 and configuration, policy, rules, etc. One advantage of the multi-tenancy and a large volume of users is the zero-day/zero-hour protection in that a new vulnerability can be detected and then instantly remediated across the entire cloud-based system 100. The same applies to policy, rule, configuration, etc. changes-they are instantly remediated across the entire cloud-based system 100. As well, new features in the cloud-based system 100 can also be rolled up simultaneously across the user base, as opposed to selective and time-consuming upgrades on every device at the locations 112, 114, 118, and the devices 110, 116.
Logically, the cloud-based system 100 can be viewed as an overlay network between users (at the locations 112, 114, 118, and the devices 110, 106) and the Internet 104 and the cloud services 106. Previously, the IT deployment model included enterprise resources and applications stored within the data center 114 (i.e., physical devices) behind a firewall (perimeter), accessible by employees, partners, contractors, etc. on-site or remote via Virtual Private Networks (VPNs), etc. The cloud-based system 100 is replacing the conventional deployment model. The cloud-based system 100 can be used to implement these services in the cloud without requiring the physical devices and management thereof by enterprise IT administrators. As an ever-present overlay network, the cloud-based system 100 can provide the same functions as the physical devices and/or appliances regardless of geography or location of the users 102, as well as independent of platform, operating system, network access technique, network access provider, etc.
There are various techniques to forward traffic between the users 102 at the locations 112, 114, 118, and via the devices 110, 116, and the cloud-based system 100. Typically, the locations 112, 114, 118 can use tunneling where all traffic is forward through the cloud-based system 100. For example, various tunneling protocols are contemplated, such as Generic Routing Encapsulation (GRE), Layer Two Tunneling Protocol (L2TP), Internet Protocol (IP) Security (IPsec), customized tunneling protocols, etc. The devices 110, 116, when not at one of the locations 112, 114, 118 can use a local application that forwards traffic, a proxy such as via a Proxy Auto-Config (PAC) file, and the like. A key aspect of the cloud-based system 100 is all traffic between the users 102 and the Internet 104 or the cloud services 106 is via the cloud-based system 100. As such, the cloud-based system 100 has visibility to enable various functions, all of which are performed off the user device in the cloud.
The cloud-based system 100 can also include a management system 120 for tenant access to provide global policy and configuration as well as real-time analytics. This enables IT administrators to have a unified view of user activity, threat intelligence, application usage, etc. For example, IT administrators can drill-down to a per-user level to understand events and correlate threats, to identify compromised devices, to have application visibility, and the like. The cloud-based system 100 can further include connectivity to an Identity Provider (IDP) 122 for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 for event logging. The system 124 can provide alert and activity logs on a per-user 102 basis.
The enforcement nodes 150 are full-featured secure internet gateways that provide integrated internet security. They inspect all web traffic bi-directionally for malware and enforce security, compliance, and firewall policies, as described herein. In an embodiment, each enforcement node 150 has two main modules for inspecting traffic and applying policies: a web module and a firewall module. The enforcement nodes 150 are deployed around the world and can handle hundreds of thousands of concurrent users with millions of concurrent sessions. Because of this, regardless of where the users 102 are, they can access the Internet 104 from any device, and the enforcement nodes 150 protect the traffic and apply corporate policies. The enforcement nodes 150 can implement various inspection engines therein, and optionally, send sandboxing to another system. The enforcement nodes 150 include significant fault tolerance capabilities, such as deployment in active-active mode to ensure availability and redundancy as well as continuous monitoring.
In an embodiment, customer traffic is not passed to any other component within the cloud-based system 100, and the enforcement nodes 150 can be configured never to store any data to disk. Packet data is held in memory for inspection and then, based on policy, is either forwarded or dropped. Log data generated for every transaction is compressed, tokenized, and exported over secure TLS connections to the log routers 154 that direct the logs to the storage cluster 156, hosted in the appropriate geographical region, for each organization.
The central authority 152 hosts all customer (tenant) policy and configuration settings. It monitors the cloud and provides a central location for software and database updates and threat intelligence. Given the multi-tenant architecture, the central authority 152 is redundant and backed up in multiple different data centers. The enforcement nodes 150 establish persistent connections to the central authority 152 in order to download all policy configurations. When a new user connects to an enforcement node 150, a policy request is sent to the central authority 152 through this connection. The central authority 152 then calculates the policies that apply to that user 102 and sends the policy to the enforcement node 150 as a highly compressed bitmap.
Once downloaded, a tenant's policy is cached until a policy change is made in the management system 120. When this happens, all of the cached policies are purged, and the enforcement nodes 150 request the new policy when the user 102 next makes a request. In an embodiment, the enforcement node 150 exchange “heartbeats” periodically, so all enforcement nodes 150 are informed when there is a policy change. Any enforcement node 150 can then pull the change in policy when it sees a new request.
The cloud-based system 100 can be a private cloud, a public cloud, a combination of a private cloud and a public cloud (hybrid cloud), or the like. Cloud computing systems and methods abstract away physical servers, storage, networking, etc., and instead offer these as on-demand and elastic resources. The National Institute of Standards and Technology (NIST) provides a concise and specific definition which states cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud computing differs from the classic client-server model by providing applications from a server that are executed and managed by a client's web browser or the like, with no installed client version of an application required. Centralization gives cloud service providers complete control over the versions of the browser-based and other applications provided to clients, which removes the need for version upgrades or license management on individual client computing devices. The phrase “Software as a Service” (SaaS) is sometimes used to describe application programs offered through cloud computing. A common shorthand for a provided cloud computing service (or even an aggregation of all existing cloud services) is “the cloud.” The cloud-based system 100 is illustrated herein as an example embodiment of a cloud-based system, and other implementations are also contemplated.
As described herein, the terms cloud services and cloud applications may be used interchangeably. The cloud service 106 is any service made available to users on-demand via the Internet, as opposed to being provided from a company's on-premises servers. A cloud application, or cloud app, is a software program where cloud-based and local components work together. The cloud-based system 100 can be utilized to provide example cloud services, including Zscaler Internet Access (ZIA), Zscaler Private Access (ZPA), and Zscaler Digital Experience (ZDX), all from Zscaler, Inc. (the assignee and applicant of the present application). The ZIA service can provide the access control, threat prevention, and data protection described above with reference to the cloud-based system 100. ZPA can include access control, microservice segmentation, etc. The ZDX service can provide monitoring of user experience, e.g., Quality of Experience (QoE), Quality of Service (QOS), etc., in a manner that can gain insights based on continuous, inline monitoring. For example, the ZIA service can provide a user with Internet Access, and the ZPA service can provide a user with access to enterprise resources in lieu of traditional Virtual Private Networks (VPNs), namely ZPA provides Zero Trust Network Access (ZTNA). Those of ordinary skill in the art will recognize various other types of cloud services 106 are also contemplated. Also, other types of cloud architectures are also contemplated, with the cloud-based system 100 presented for illustration purposes.
The processor 202 is a hardware device for executing software instructions. The processor 202 may be any custom made or commercially available processor, a Central Processing Unit (CPU), an auxiliary processor among several processors associated with the server 200, a semiconductor-based microprocessor (in the form of a microchip or chipset), or generally any device for executing software instructions. When the server 200 is in operation, the processor 202 is configured to execute software stored within the memory 210, to communicate data to and from the memory 210, and to generally control operations of the server 200 pursuant to the software instructions. The I/O interfaces 204 may be used to receive user input from and/or for providing system output to one or more devices or components.
The network interface 206 may be used to enable the server 200 to communicate on a network, such as the Internet 104. The network interface 206 may include, for example, an Ethernet card or adapter or a Wireless Local Area Network (WLAN) card or adapter. The network interface 206 may include address, control, and/or data connections to enable appropriate communications on the network. A data store 208 may be used to store data. The data store 208 may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, the data store 208 may incorporate electronic, magnetic, optical, and/or other types of storage media. In one example, the data store 208 may be located internal to the server 200, such as, for example, an internal hard drive connected to the local interface 212 in the server 200. Additionally, in another embodiment, the data store 208 may be located external to the server 200 such as, for example, an external hard drive connected to the I/O interfaces 204 (e.g., SCSI or USB connection). In a further embodiment, the data store 208 may be connected to the server 200 through a network, such as, for example, a network-attached file server.
The memory 210 may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.), and combinations thereof. Moreover, the memory 210 may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory 210 may have a distributed architecture, where various components are situated remotely from one another but can be accessed by the processor 202. The software in memory 210 may include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. The software in the memory 210 includes a suitable Operating System (O/S) 214 and one or more programs 216. The operating system 214 essentially controls the execution of other computer programs, such as the programs 216, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The one or more programs 216 may be configured to implement the various processes, algorithms, methods, techniques, etc. described herein.
The processor 302 is a hardware device for executing software instructions. The processor 302 can be any custom made or commercially available processor, a CPU, an auxiliary processor among several processors associated with the user device 300, a semiconductor-based microprocessor (in the form of a microchip or chipset), or generally any device for executing software instructions. When the user device 300 is in operation, the processor 302 is configured to execute software stored within the memory 310, to communicate data to and from the memory 310, and to generally control operations of the user device 300 pursuant to the software instructions. In an embodiment, the processor 302 may include a mobile-optimized processor such as optimized for power consumption and mobile applications. The I/O interfaces 304 can be used to receive user input from and/or for providing system output. User input can be provided via, for example, a keypad, a touch screen, a scroll ball, a scroll bar, buttons, a barcode scanner, and the like. System output can be provided via a display device such as a Liquid Crystal Display (LCD), touch screen, and the like.
The network interface 306 enables wireless communication to an external access device or network. Any number of suitable wireless data communication protocols, techniques, or methodologies can be supported by the network interface 306, including any protocols for wireless communication. The data store 308 may be used to store data. The data store 308 may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, the data store 308 may incorporate electronic, magnetic, optical, and/or other types of storage media.
The memory 310 may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, etc.), and combinations thereof. Moreover, the memory 310 may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory 310 may have a distributed architecture, where various components are situated remotely from one another, but can be accessed by the processor 302. The software in memory 310 can include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. In the example of
Data Loss Prevention (DLP) includes detection of potential data breaches/data ex-filtration transmissions and prevention by monitoring, detecting, and blocking sensitive data while in use (endpoint actions), in-motion (network traffic), and at rest (data storage). Note, the terms “data loss” and “data leak” may be used interchangeably. In various embodiments, the cloud-based system 100 is configured to perform DLP functionality for a tenant. Data At Rest (DAR) includes the ability to scan file shares, SharePoint, or other cloud services providing file storage, and the like. Data in Motion (DIM) includes the ability to monitor data leaving the organization via multiple protocols, including SSL traffic. The multiple protocols can include, without limitation, Simple Mail Transport Protocol (SMTP), Instant Messaging (IM), File Transport Protocol (FTP), FTP Secure (FTPs), Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), and the like. The Data at Endpoint (DAE) monitors via an agent to monitor the data store 308 at the user devices 300.
The cloud-based system 100 can provide DLP functionality to inspect all traffic, including encrypted traffic, no matter where, how, when, etc. the user 102 connects. This provides identical protection whether the user 102 is located on or off-network. The cloud-based system 100 provides the same level of security to all the users 102 by moving security to the cloud, located between the users 102 and the Internet 104 and the cloud services 106. Cloud DLP policy follows users 102 where they work—on-or off-network—and provides the same level of protection to all users 102 at all times.
The cloud-based system 100 provides a full SSL inspection of all traffic. Of note, most traffic is encrypted, and no subject to inspection by traditional DLP approaches. The cloud-based system 100 is a proxy by design system, with the enforcement nodes 150 in between and performing SSL inspection on all traffic, without the inspection limitations of appliances. Further, the cloud-based system 100 is architected inline so it can block sensitive information before it leaves the tenant's network, instead of focusing on damage control after a compromise. The cloud-based system 100 is user-based, not capacity-based, allowing cloud-based DLP scale elastically. The cloud-based system 100 is configured to offer DLP as a service, eliminating redundancies of managing various appliances, reducing the resources needed to stand up and maintain point products.
The DLP functionality via the cloud-based system 100 can include content matching, Exact Data Match (EDM), granular policies, and flexible remediation. The content matching can utilize preconfigured and/or custom DLP dictionaries supporting Regular Expressions (Regex), keywords, etc. Content detection can include numeric detection, trained dictionaries/fuzzy search, and Boolean logic. The numeric detection can detect Social Security Numbers (SSNs), medical numbers (CCNs, insurance numbers, etc.), pattern matching, etc. The trained dictionaries/fuzzy search can match financial data, source code, medical data, names, adult content, CRM data, gambling, weapons, etc. The Boolean logic can combine context and detection with logical operators, keywords, and phrases. The DLP functionality can also support context detection based on people (users, groups, departments, etc.), location (country, branch office, etc.), and reporting.
The DLP functionality via the cloud-based system 100 can provide real-time visibility, contextual reporting, and auditor workflow, secure Internet Content Adaptation Protocol (ICAP) forwarding, and SIEM integration. The real-time visibility provides IT administrators with instant visibility of violations as they occur for remediation and compliance. The contextual reporting and auditor workflow can provide notifications with DLP incidents. The secure ICAP forwarding supports integration with third-party DLP solutions. The SIEM integration can stream real-time logs to the system 124.
The DLP dictionaries include a set of data that are designed to detect specific kinds of information in the user traffic. Predefined dictionaries can include bank routing numbers, adult content, credit cards, financial statement, gambling, illegal drips, medical information, names, Salesforce data, SSN, source code, etc. In addition to the predefined dictionaries, tenants can provide custom dictionaries, such as via the EDM system 400. A custom DLP dictionary can include alphanumeric patterns that match a wide variety of data types. For example, one can define patterns to detect data like phone numbers, driver's license numbers, or credit card numbers for specific issuers.
A DLP engine is a collection of one or more DLP dictionaries. When one defines DLP policy rules, one must reference DLP engines, rather than DLP dictionaries. By using a DLP engine, one can create rules to detect content that encompasses more than one dictionary. For example, if an organization wants to protect social security and credit card numbers, one would create a rule using the PCI Engine, which contains the Credit Cards and Social Security Numbers dictionaries. When a DLP engine uses two or more dictionaries, the DLP service 500 can block content only if all of the dictionaries in the engine are triggered. The DLP engines can scan files with a maximum size of 100 MB. The DLP service 500 can provides four predefined engines:
HIPAA: This engine is designed to detect Health Insurance Portability and Accountability Act (HIPAA) violations, using the Social Security Numbers (US) and Medical Information dictionaries.
GLBA: This engine is designed to detect violations of the Gramm-Leach-Bliley Act (GLBA), using the Social Security Numbers (US) and Financial Statements dictionaries.
PCI: This engine is designed to detect Payment Card Industry (PCI) compliance violations, using the Credit Cards and Social Security Numbers (US) dictionaries.
Offensive Language: This engine is designed to detect offensive language, using the Adult Content dictionary.
The DLP engines can be used to detect data, allow or block transactions, and notify an organization's auditor when a user's transaction triggers a DLP rule. If an organization has a third-party DLP solution, namely the ICAP server 502, the DLP service 500 can forward information about transactions that trigger DLP policy via secure ICAP.
In an embodiment, by default, the Subject line for the notification uses the text DLP Violation: with the $ {TRANSACTION_ID} and $ {ENGINES} macros. These macros will list the ID of the transaction that triggered the DLP rule, as well as the DLP engines that triggered. However, this text can be modified as described herein and can include the $ {USER} and $ {URL} macros as well.
a) a notification includes a name.
b) a subject line of the notification by default can use the text DLP Violation: with the ${TRANSACTION_ID} and $ {ENGINES} macros. These macros will list the ID of the transaction that triggered the DLP rule, as well as the DLP engines that triggered. However, this text can be modified, and one can include the ${USER} and ${URL} macros as well. For a complete list of macros, see step e below.
c) the violating content can be included, such as via an attachment of the violating content added to the notifications emailed to auditors.
d) a TLS connection can be used to send the notification email. Here, the email recipient's SMTP server must support TLS. It is recommended that TLS is used to send an email that might contain sensitive content. Also, the attachments and the violating content are never stored in the cloud-based system 100 or the DLP service 500. Once sent, all such data is deleted from memory.
e) In the Message as Plain Text or Message as Hypertext Markup Language (HTML) sections, one can create a customized message detailing why the content was blocked. This message is delivered via email (Delivery Status Notification) to the auditor when a policy triggers and blocks content.
The following macros can be used in the message body and subject line:
ICAP—DLP service communication
When the DLP service 500 sends information to the ICAP server 502, it does not do so from an enforcement node 150 on the cloud that initially inspects the users' 102 transactions. If an enforcement node 150 finds that a transaction violates a DLP policy rule and further, the rule specifies that the DLP service 500 sends violation information to the organization's DLP server, that enforcement node 150 will forward the transaction information to a second enforcement node 150. The second enforcement node 150 is on a different cloud that the DLP service 500 uses for sending communications to the ICAP server 502.
In an embodiment, the second enforcement node 150 sends the following information about the transaction to the ICAP server 502:
The process 600 includes a user 102 attempting to send data, with the cloud-based system 100 providing monitoring (step 602). An enforcement node 150 finds a DLP violation and forwards the transaction information to a second enforcement node 150 tasked with sending communications using ICAP to the ICAP server 502 (step 604). The second enforcement node 150 sends the transaction information to the ICAP server 502 using secure ICAP (step 606).
An organization's firewall 608 must be configured to allow communications from the second enforcement node 150. Further, to protect the organization's data, the second enforcement node 150 can send the above information in an encrypted form via secure ICAP. However, because most DLP servers (ICAP servers 502) can only read unencrypted information, another option is to utilize a tunnel on the ICAP server 502, such as an open-source application called the stunnel application for a TLS/SSL tunnel. After installation, the stunnel application and the second enforcement node 150 can establish an SSL communication, and the second enforcement node 150 can send transaction information in encrypted form to the ICAP server 502. The stunnel application will then decrypt the transaction information for the ICAP server 502.
Once this process 600 takes place, the ICAP server 502 can read the ICAP communications from the second enforcement node 150 and report incidents as applicable in the ICAP server 502.
In the indexing tool 402, data records are identifier (step 660), and defined data is submitted (step 662), and fingerprints are uploaded to the enforcement nodes 150 (step 664). Again, importantly, the data itself is not uploaded, but hash signatures. In the admin portal (management system 120), an IT administrator can define an EDM rule for the DLP service (step 666), load the EDM rule on the enforcement nodes 150 (step 668), enable the EDM rule (step 670), etc. The enforcement nodes 150 can monitor outbound traffic for EDM rule violations (step 672), and responsive to an EDM rule violation check (step 674), either allow the outbound traffic (step 676) or block the outbound traffic and report (step 678)/
Creating an EDM template allows one to define these tokens (i.e., criteria) for data records by importing a CSV file. Once the data is defined and submitted, it is possible to apply the template to a custom DLP dictionary or engine, which will use the criteria to match against the data records. The DLP service 500 will then evaluate the EDM-defined DLP rule with the appropriate action for any outbound traffic. When creating an EDM index template, tokens (i.e., criteria) are defined for the data records, and at least one primary field is specified. The primary field is a unique key that the DLP policy rules are based on. It is a required field that must be unique based on the data records.
The following illustrates some consideration before creating an EDM index template. Review the DLP policy that is to be created and the data to be protected. During the review, consider the data that must be included in the EDM index template. Try to create a template where the data records need to be indexed once, to avoid the need to re-index. Finally, review the data records to avoid duplication.
Let's use the following example: Assume the organization is a bank with an employee database, and the objective is to protect the employees' PII as well as their company credit card information. The database records contain the following data fields: First Name (FName), Last Name (LName), Social Security Number (SSN), Credit Card Number (CCN), Mobile Phone Number, Postal Code, Street Address, and so on. The DLP dictionaries or engines that need to be created with EDM, which can then be used in the DLP policies, must cover a series of field combinations to protect the employees' information adequately. So, based on your records in this example, any of the following data field combinations could be used to create a DLP dictionary:
However, the EDM index template created using the indexing tool 402 must allow the dictionary to cover the field combinations required. This can be accomplished by selecting a primary field based on the data field combination needed. Using the example of the bank, specifying a primary field allows the creation of a single EDM index template to protect the employees' information, where:
So, using the indexing tool 402, an EDM index template would be created that includes the following fields: SSN, CCN, FName, and LName. To create the employee PII DLP dictionary, SSN can be selected as a primary field. However, to create the company-issued employee credit card DLP dictionary using the same template, select CCN as a 2nd primary field. The other included fields (i.e., FName, LName) will be applied as Secondary Fields for both dictionaries. Finally, in this example, BankNum is not a required data field for the DLP policies.
The feature discussed in this document describes a technique to forward the content that triggered the DLP rule along with the DLP scan information to a designated ICAP server 502. The ICAP server 502 can be either customer specified, on-premises ICAP server 502A, or a cloud-based ICAP server 502B that works with the cloud-based system 100. In
On detection of a DLP rule violation, the public enforcement node 150A triggers the DLP service 500 via an ICAP message. The public enforcement node 150A can send a DLP incident forwarding message to the DLP enforcement node 150B. The DLP enforcement node 150B is the second enforcement node 150 described above, and it is tasked with forwarding the DLP incidents to the DLP servers 502A, 502B. The DLP service 500 can provide DLP and EDM incident forwarding information to the DLP enforcement node 150B. Note, in some embodiments, an organization may include a private enforcement node 150C located behind the firewall 608 on the same network as the DLP server 502A. Here, the private enforcement node 150C can perform similar functionality as the public enforcement node 150A, but it can directly communicate to the DLP server 502A, being on the same, secure network.
The message format for the DLP incident forwarding can be a multipart/mixed Multipurpose Internet Mail Extensions (MIME) message that includes DLP triggering content+DLP scan metadata. The DLP triggering content is the content that triggered the DLP rule. The DLP triggering content+DLP scan metadata can be sent as attachments in a multipart/mixed message. Two cases arise, depending upon how the data is uploaded, namely a single part or a multipart message.
For a single part, the following applies
For a multipart, the following applies
The DLP scan metadata can be in JavaScript Object Notation (JSON) format with the below MIME headers.
The incident response server 722 is configured to set up client certificates with the cloud-based system 100 and setup server certificates with the DLP enforcement node 150B. The incident response server 722 is further configured to set up Secure Shell (SSH) public key authentication with the organization's SFTP server 724. The control 724, 728 is used for download and install build, requires client certificate to be installed for authentication with the cloud-based system 100. The incident response server 722 can include a process that listens on a public IP: 1344 and accepts SSL connection only.
The client certificate is used for authentication from the incident response server 722 to the cloud-based system 100. The server certificate is used for the incident response server's 722 ICAP server process. The enforcement node's 150B ICAP client needs to do verification against the incident response server 722.
The process 750 includes monitoring traffic of a user of a tenant (step 752); implementing Data Loss Prevention (DLP) service for the tenant, wherein the DLP service includes one or more DLP rules based on one or more DLP engines for the tenant (step 754); analyzing the traffic via the DLP service (step 756); detecting a DLP rule violation based on the one or more DLP rules (step 758); and forwarding forward DLP incident information to a second enforcement node that is configured to transmit the DLP incident information to a server for the tenant, including both DLP triggering content that caused the DLP rule violation and DLP scan metadata (step 760).
The first enforcement node and the second enforcement node can be configured to forward the DLP incident information and not persist the DLP triggering content in memory. The DLP triggering content can include all or a portion of data that triggered the DLP rule violation so that the tenant can determine remediation, and the DLP scan metadata can include a plurality of a DLP dictionary, a DLP engine, a search score, a trigger, a time, a user, and a Uniform Resource Locator (URL).
The DLP rule violation can be a violation of an Exact Data Match (EDM) index provided to the cloud-based system as a hash signature so that underlying data is not accessible by the cloud-based system, and wherein the triggering content includes the hash signature which is converted back to the underlying data at the server for the tenant.
The server can include an Internet Content Adaptation Protocol (ICAP) server that is one of located on-premises with the tenant and located in a cloud system and connected securely to another server located on-premises with the tenant. The first enforcement node can be configured to monitor the traffic that includes any of Secure Sockets Layer (SSL) traffic and Transport Layer Security (TLS) traffic as a proxy.
A tenant is concerned with protection that can:
(1) Identify content that is exactly the same as an indexed document 802. In this case, a cryptographic hash of the content matches a cryptographic hash of a file indexed by the tenant through the indexing tool 402.
(2) Identify content that contains the same text as text in an indexed document 802. For example, the text in a Word document is the same as the text in an indexed PDF file. That is, the content may be the same, but the document may be different.
(3) Identify content that contains text, which is a subset of the text in an indexed document 802. For example, the text in content matches one paragraph of the text in an indexed document 802.
(4) Identify content that contains text that is similar but not exactly the same as the text in an indexed file 802. The tenant can specify a threshold for similarity detection. For example, it is considered a match only if 80% of the content matches the text in an indexed file 802.
(5) A tenant can index files into multiple user-defined profiles or categories, such as, for example, legal, financial, engineering, etc. The tenant can also specify the similarity threshold for each profile, such as, for example, legal-match threshold 75%, finance-match threshold 80%, etc.
The objectives in items (1)-(4) can be reduced to the two below requirements.
(i) Similarity detection: same file (1), same text (2), similar text (4), and
(ii) Fragment identification: partial content match (3).
The result of the similarity detection and fragment identification can provide a score, such as between 1-100, which is a measure of the confidence of a match to an indexed document 802.
Again, the documents 802 are sensitive information for the tenant. It is not advisable or practical to upload the files to the cloud-based system 100. As such, the documents 802 can be indexed via the indexing tool 402 on-premises. That is, the documents 802 do not need to leave an enterprise's secure network. The indexing tool 402 can be realized in a software program, Virtual Machine (VM), etc. that performs indexing functions locally to provide the fingerprint data 808 as the hash data 408 to the cloud-based system 100. The indexing tool 402 can index single files via a UI or specify a directory of files located in a remote Secure File Transfer Protocol (SFTP) location. The indexing tool 402 can also support scheduling and the ability to do scheduled re-indexing of the files to capture the latest revisions and/or new files added to the directory. A tenant can have multiple such indexing tools 402, and they can create multiple document profiles in each tool 402. After the fingerprint data 808 is uploaded to the cloud-based system 100, the data from multiple indexing tools 402 can be combined to create customer-specific indexed data that is grouped by document profiles.
After the files have been indexed via the indexing tool 402, a fingerprint of each file is created. A key point is this fingerprint data 808 cannot be used to recreate the original file. This ensures the confidentiality of the documents 802. That is, the cloud-based system 100 only has access to the hash data 408 (the fingerprint data 808), so there is no concern with the documents 802 in the cloud-based system 100.
For detecting whether two files are the same, it is possible to use a cryptographic hash, such as MD5 (Message Digest 5) or SHA1 (Shared Hash Algorithm 1). That is, an indexed document 802 has a cryptographic hash value, and monitored content, by the DLP service 500, can be converted to a cryptographic hash value, using the same algorithm. If two cryptographic hash values match, then the monitored content matches the indexed document 802.
However, for similarity and fragment identification, a cryptographic hash is not suitable since minor changes (a single bit) in the content leads to a completely different hash value, which is not comparable to the original hash. Of note, two files that are similar to each other will have large sequences of identical bits in the same order. Thus, for detecting similarity (as opposed to the same file), instead of creating a single hash for a file, the present disclosure includes creating many hashes by dividing the file into discrete pieces, then hashing each piece individually.
The fingerprint data 808 of a file can include a combination of any of the following information
Again, the fingerprint data 808 includes at least a cryptographic hash of the entire file 820 and an ordered sequence of hashes of variable length chunks of the extracted text, e.g., CTPH. The fingerprint data 808 as bin (binary) files are then uploaded to customer assigned nodes for the distribution service 806. From there, the bin files are distributed to the DLP service 500.
The distribution service 806 and/or the DLP service 500 can create an IDM data lookup table (IDX file) for each new bin file it receives. Also, in case an updated version of a bin file is received, the distribution service 806 and/or the DLP service 500 can update the IDX file for the tenant. The IDM data lookup table (IDX) of each company is a hash table using the CTPH hashes of all files from all profiles as keys, and the values are the remaining fields of the fingerprint data of each file.
Also, the lookup table 840A, 840B does not include the actual confidential or sensitive data. With the lookup table 840A, 840B, the DLP service 500 can detect a similarity in monitored content.
When IDM matching is required against the monitored file, first a cryptographic hash can be calculated (step 852), and compared against the cryptographic hash of all indexed files of the same length as the uploaded file (step 853). Note, the matching process here in step 853 can include matching the cryptographic hash based on the file length. Here, the cryptographic hashes can be indexed by file length so it is not necessary to check different length files. This can speed up the matching process.
If a match is found, the index matching process 850 can return a match score indicative of the monitored file matching a corresponding file of all indexed files (step 854). Assuming the scoring system is 1 to 100, 1 being completely different, and 100 being an exact match, the index matching process 850 can report the match score as 100 for this profile when there is a cryptographic hash match.
If a match is not found (step 853), the index matching process 850 can extract the text from the monitored file and create an ordered sequence of hashes of variable length chunks of the extracted text (step 855). Here, the index matching process 850 uses the content of the monitored file to create the CTPH (Context Triggered Piecewise Hash). This process is the same as file indexing done in the indexing tool 402. CTPH is an ordered sequence of FNV hashes computed on variable-length chunks of the extracted text. Note, the chunk size of each hash can be in the fingerprint data 808 and this can also be used in the matching process 850, i.e., both the hash and its chunk size have to match, to be a candidate for an IDM match.
The index matching process 850 can compare each of the ordered sequence of hashes with indexed hashes in a lookup table (step 856), and generate a match score for one or more potential matches of files in the lookup table (step 857). That is, using every FNV hash in the CTPH, a lookup is done into the lookup table for this tenant to generate a candidate set of potential match files. The match score for each candidate file can be computed as the edit distance between its CTPH in the bin file 828 and the CTPH of the monitored file. This score can be scaled to be in the range of 1-100. For each profile, the indexed file with the maximum score can be reported to check if it exceeds a DLP dictionary threshold.
With the cloud-based system 100 and the DLP service 500, when upload traffic (PUT/POST requests) are scanned by any enforcement node 150, the enforcement node 150, in turn, can forward the request via ICAP to a DLP enforcement node 150B associated with this tenant. The DLP enforcement node 150B will check if this request should be blocked/allowed based on the DLP policy configured for the tenant. As part of the DLP policy enforcement, the DLP enforcement node 150B can check if all/any of the content matches the content in a customer indexed file. If a match against an indexed file is found and the match score is greater than the configured threshold for the document profile, the filename of the indexed file will be recorded in the transaction logs. If the tenant has configured email notification or incident forwarding, the filename will also be reported in the transaction metadata.
The DLP service 500 can utilize one or more dictionaries. A DLP dictionary is a set of data that includes specific kinds of information that are monitored for in user traffic. The DLP service 500 can include one or more DLP dictionaries in a DLP engine that is used for detection. The present disclosure includes utilizing expressions to combine one or more DLP dictionaries in the DLP engine to provide an aggregate result. The DLP dictionaries can include predefined dictionaries and custom dictionaries. Of course, there can also be multiple custom dictionaries for each organization (tenant).
Examples of some predefined dictionaries include:
The predefined dictionaries can be used across different tenants, such as when the DLP service 500 is multi-tenant. Also, the predefined dictionaries can be managed by a service provider. The predefined dictionaries and custom dictionaries can be used together. The custom dictionaries can be created by a tenant, using the indexing tool 402 as described herein. Thus, the predefined dictionaries can include general info and the custom dictionaries can include tenant-specific confidential information.
The custom dictionaries are based on the individual tenant. Examples of custom dictionaries may include customer data, Human Resource (HR) data, employee lists, R&D data, etc.
Again, as described herein, a DLP engine is a collection of one or more DLP dictionaries, including any of the predefined dictionaries and custom dictionaries. Some examples of DLP engines can include:
Thus, from the above examples, the DLP engine can include one or more DLP dictionaries including any predefined dictionary and custom dictionary.
Again, the present disclosure relates to systems and methods for Data Loss Prevention (DLP) expression building for a DLP engine. With one or more DLP dictionaries in a DLP engine, a user can specify conditions based on a search score versus threshold for each dictionary along with logical operators, i.e., AND, OR, and NOT, to build an interactive expression. At runtime (when the DLP service 500 is evaluating traffic), once one or more DLP engines scan the traffic and provides a search score based on its dictionary, the user-configured expression is evaluated for each of the one or more DLPs engines is evaluated as TRUE or FALSE, to determine which of the one or more DLP engines are hit.
Prior to the present disclosure, a DLP engine included a set of DLP dictionaries that are individually evaluated (TRUE or FALSE) and the results require all DLP dictionaries in the DLP engine be triggered (TRUE) for the DLP engine to be triggered (e.g., a logical AND of the results of all of the DLP dictionaries), which means all DLP dictionaries associated with a DLP engine must be triggered in order to have the engine triggered.
The same expression is presented in three different forms, in the DLP engine expression builder, the expression preview, and a database associated with the DLP service 500. In the DLP engine expression builder, the expression can be presented and modified with a tree, each level is associated with one of the following specifiers: (a) ALL (equivalent of logical ‘AND’), (b) ANY (equivalent of logical ‘OR’), and (c) EXCLUDE (equivalent of logical ‘NOT’).
In the expression preview, the expression can be presented as plain text expression in which “ALL” and “ANY” are translated into “AND” and “OR” logical operators, also the long dictionary names can be replaced with shorter ones. The objective here is to present a human-readable format.
Finally, the expression is stored in a database associated with the DLP service 500, for use at runtime. In an embodiment, the expression can have the dictionary names replaced with corresponding dictionary IDs with ‘D’ (stands for dictionary) as prefix and “.S” (stands for search score) as suffix. For example, the “Credit Card” dictionary could be replaced with “D63.S.” Here are some examples:
Certain predefined dictionaries such as Medical have only confidence but no threshold setting. For such dictionaries instead of allowing user to type number, the builder can display a label to indicate the threshold will be determined automatically based on the confidence level. For example, predefined dictionaries with no threshold can include:
These dictionaries output a confidence level, i.e., does the user traffic trigger this dictionary. For purposes of the expression, the confidence level can be converted to a TRUE or FALSE. For example, high to medium confidence equals TRUE whereas low to medium confidence equals FALSE. The user can decide if a medium confidence is TRUE or FALSE.
For example, predefined dictionaries with a threshold can include:
That is, dictionaries either evaluate to a threshold number (i.e., number of hits) or a confidential level. Either of these can output a TRUE or FALSE for evaluation in the expression.
In the expression, a given dictionary may show up multiple times, including under the same operator, e.g., CCN.Score>1 and CCN.Score>2. Of course, the user can ensure the expression logically makes sense. The previous example is simply evaluated as CCN. Score>2. The “NOT” operations are not allowed as the root element, but allowed in any position in the expression (tree). The expression may include multiple nested levels, and each level may include multiple operators (AND/OR/NOT).
The expression may also include weights so that different parts of the expression carry more weight. Evaluation of a weighted Boolean expression can be as is known in the art.
The DLP engine expression process 870 can include, prior to the obtaining, presenting a user interface for the obtaining the expression; and receiving a selection of the one or more DLP dictionaries, the corresponding threshold for the comparison, and a selection of the one or more logical operators. The user interface can include a tree having one or more levels, and the DLP engine expression process 870 can include presenting an expression preview as the selection is received.
The one or more DLP dictionaries can be any of a predefined dictionary and a custom dictionary, wherein the predefined dictionary is managed by a service provider and used for multiple tenants, and wherein the custom dictionary is managed by a tenant and data therein is kept confidential from the service provider. The one or more DLP dictionaries can include at least one predefined dictionary and at least one custom dictionary.
The one or more DLP dictionaries can be one of evaluated to a score and evaluated to a confidence level, wherein the score is evaluated through the comparison with the corresponding threshold, and wherein the confidence level is converted to a score for evaluation evaluated through the comparison with the corresponding threshold. The one or more logical operators can be any of a logical AND, a logical OR, and a logical NOT. The expression can include a plurality of nested levels. The DLP engine expression process 870 can include, responsive to the DLP trigger, performing an action based thereon.
The DLP on images process 890 can include inline monitoring the user traffic with a cloud service, such as via the cloud-based system 100 (step 891). The DLP on images process 890 includes detecting an image in monitored user traffic (step 892); scanning the image to identify any text and extracting any identified text therein (step 893); responsive to the extracting, scanning the extracted text with a plurality of Data Loss Prevention (DLP) techniques including one or more DLP engines where the extracted text is checked to trigger the one or more DLP engines, Exact Data Matching (EDM) where the extracted text is matched to see if it matches specific content, and Indexed Data Matching (IDM) where the extracted text is matched to some part of a document from a repository of documents (step 894); and performing one or more actions based on results of the plurality of DLP techniques (step 895).
The monitored user traffic can be via inline monitoring such as through the cloud-based system 100. One aspect of such monitoring includes an ability to detect content through the enforcement node 152. For example, an image can be detected based on its file type. Also, the image can be detected, as an image, based on a specific set of bytes at the beginning of the file which note the type of image file, e.g., BMP, GIF, JPG, TIFF, PNG, etc. Also, the DLP on images process 890 can consider a non-searchable PDF file as an image and operate thereon. That is, the term image used herein can denote any file or content that is not searchable for text for DLP functionality.
Further, the DLP on images process 890 may operate selectively for inline monitoring. This approach may be useful to reduce latency and processing requirements. In an embodiment, the detecting the image is in part based on detecting the user traffic is associated with any of social media, electronic mail, and posts on Web sites. Here, the objective of the DLP on images process 890 is to ensure no data loss or leakage to social media, electronic mail, and posts on Web sites. Also, the plurality of DLP techniques can include at least one DLP engine for detecting embarrassing content based on detecting the user traffic is associated with any of social media, electronic mail, and posts on Web sites. For example, the at least one DLP engine can be an adult content predefined dictionary. Data loss or leakage to social media (posts, tweets, etc.) can be useful to detect inadvertent content that may be embarrassing. That is, the DLP on images process 890 can be used in part as a social media filter.
In another embodiment, the scanning step 893 includes detecting some text in the image via Optical Character Recognition (OCR); and extracting the some text when the some text is above a threshold amount. This use case is looking for a large amount of text, i.e., where a document has been photographed and sent for eluding DLP functionality. Here, the DLP on images process 890 is constrained to only operate where there is a large amount of text, above some threshold. The threshold can be selected so that the image is primarily text, as would be the case where a document was photographed. For more sensitivity, the threshold can be selected so that the image is mainly text.
The objective here is to only apply the DLP on images process 890 where needed. The DLP on images process 890 identifies two use cases-social media, email, and web posting and documents that are sent as images. The first use case-social media, email, and web posting—can be detected based on a destination of the user traffic, and the second use case can be based on an amount of text in the image. For the second use case, a PDF document can be assumed to be included.
Also, in an embodiment, the plurality of DLP techniques can include a plurality of the DLP engines. That is, the plurality of DLP techniques can be multiple DLP engines as described herein. In another embodiment, at least one of the plurality of DLP engines can include a predefined dictionary including adult content. In a further embodiment, at least one of the plurality of DLP engines includes a predefined dictionary and at least one of the plurality of DLP engines includes a custom dictionary.
Finally, the one or more actions include any of blocking the image in a cloud service and providing a notification, including incident forwarding as described herein.
Also, the images can be scanned in single-part and multi-part HTTP uploads in POST and PUT requests, as well as in FTP uploads.
Present inline data protection solutions identify sensitive content in motion via proxy control for HTTP, HTTPS, FTP, and other traffic of the like. Inline policy controls include allow, monitor, and block. The data protection for CASB-API scans data in various SaaS applications including but not limited to file share applications (Box, Dropbox, Google drive, Onedrive, Sharepoint, Confluence, and the like), Email (MS Exchange, Gmail, and the like), CRM, ITSM, collaboration applications (Slack, MS Teams, Webex, and the like), repository applications (Bitbucket, Github, and the like), and cloud storage (S3, Azure blob, Google cloud storage). The supported DLP policy controls for CASB-API are reporting, revoke share, remove collaborators, quarantine, etc. depending on the SaaS application. However, the same identification of sensitive content (i.e., DLP dictionary and engines) can be used for both inline and CASB-API scan. This simplifies the management of the configuration into a unified content identification object.
Data Protection for endpoint brings this content identification and control to the user's device. The channels protected from exfiltration of sensitive data are copy to peripheral devices (USB, Bluetooth), printing, clipboard, copy to local network shares, and SaaS remote sync services. Various embodiments of the data protection (DLP) for the endpoint (devices) are packaged as part of cloud systems while multiple end point platforms and versions are supported (i.e., Windows, Mac, Linux, Android, and the like). Channels are contemplated as various outlets for data to be exfiltrated from a device.
In various embodiments, DLP configurations include dictionaries, engines, and rules. Dictionaries include individual identifiers and are further categorized as predefined dictionaries and custom dictionaries. Predefined dictionaries include predefined PII dictionaries (SSN, CCN, UK NINO, Mexico CLABE, etc.) and predefined phrase dictionaries (medical, financial, adult, weapons, etc.). Custom dictionaries include custom phrase dictionaries, custom pattern dictionaries, Microsoft AIP dictionaries, Exact Data Match (EDM) dictionaries, and Indexed Data Match (IDM) dictionaries.
Engines include Boolean expressions (AND, OR, EXCLUDE) between the dictionaries (predefined or custom) and with associated thresholds. Engines can be either custom or predefined as well. For example, predefined engine expressions for PCI and HIPAA are PCI=(Credit Cards>5 AND Social Security Numbers (US)>5) and HIPAA=(Medical Information>0 AND Social Security Numbers (US)>5). Custom engines can be constructed similarly with more complex logic. DLP policy rules include multiple criteria (user, group, department, device, filetype, and DLP engines) and an action. If all the conditions are met, then the rule is triggered, and any specified action or actions are performed.
Endpoint DLP rules have one more important condition “Event”, some of the monitored file events on the end point are copy to USB device, copy to network share, add to archive, copy to remote sync folder, printing, copy to clipboard, and other events of the like. An end user can have multiple devices, so device and platform specific policies can be configured. Devices can also be grouped based on different criteria and device group policies can be created.
The DLP configuration 906 fetched is parsed, and a consumable data structure is created in memory. The configuration is stored in bidirectional mapping structures (i.e., from engines to dictionaries and from dictionaries mapped to engines). This simplifies the engine evaluation as described herein. The file system crawler 908 adds files to the DLP scan queue. After the initial full scan is completed, newly added/created files are added to the scan queue. If the scan configuration version changes, then a new full scan is initiated. Safe listed file paths are excluded from scanning. The DLP scanner 910 implements the DLP scan logic on the files in the scan queue. The steps in DLP scan are any of text extraction, tokenization, DLP matching, dictionary scoring, engine expression evaluation, and others of the like.
Specifically for text extraction, for archives (i.e., zip, rar, tar, gz, 7zip, cab, etc) first decompression and then text extraction is performed on the unarchived files. Next the true filetype is detected based on magic bytes (bytes sequences at specific offsets). Text extraction is performed based on the true filetype detected. For example, OOXML format files (dox, xlsx, pptx) are xml based formats, so libxml is used to parse the xml and extract the text content. Other file formats that need special handling can include Object Linking and Embedding (OLE) files (doc, xls, ppt, msg), pdf, and rtf files.
Tokenization breaks the extracted text buffer into individual tokens based on special characters. The tokens are then converted to lowercase if required. There are three types of tokens to be considered including numeric tokens, alphanumeric tokens, and non-alphanumeric tokens. Numeric tokens contain only digits (such as 0-9,-,/,., and spaces). Alphanumeric tokens contain numbers, alphabets, and special characters. The delimiters are common English characters like ‘ ’ (spaces), parentheses, brackets, comma, period, colon, semi-colon, question mark, exclamation, etc. Non-alphanumeric tokens contain only non-alphanumeric characters bordered by an alphanumeric delimiter (i.e., ‘$’, ‘#’, ‘%’).
The DLP matching phase involves matching the tokens against predefined and custom dictionaries, generating a score for each dictionary triggered, and then evaluating the engine expressions. For matching against predefined and custom phrase dictionaries, a hash of the token is compared against the predefined phrase hash table and the custom phrase hash table. The phrase hash tables give a direct lookup and also perform a reverse lookup to the dictionaries in which the phrase is defined.
For PII dictionary matching, the dictionaries can be configured in three confidence levels including low confidence, medium confidence, and high confidence. Low confidence level only includes length and checksum. Medium confidence level includes the low confidence, plus popular format verification. High confidence level includes the medium confidence, plus specific trigger phrases. Each PII dictionary uses a different checksum algorithm. For example, credit card uses a Luhn check to verify the last digit and also a BIN series verification is done to check for valid numbers. These dictionaries can also be configured with an optional proximity configuration, which specifies the maximum distance between a PII token and the trigger phrases.
For pattern matching, all the regular expression patterns defined in all pattern matching dictionaries are compiled into an immutable pattern database that is used at scan time. The scan engine provides a callback function with the pattern id and offset of the match found.
For engine expression evaluation, the triggered dictionaries and their corresponding scores are used in evaluating which engines are triggered.
The file scan information stores the DLP scan info for all files that trigger at least one engine. Here are some examples of DLP scan information:
Further, here are examples of match count trigger information:
The event watcher 912 monitors the file system and other devices for events. On the Windows platform, one or more event watchers are implemented as file system filter drivers for monitoring the file system and device drivers for monitoring peripheral devices and detachable media. Other events are monitored via hooking into windows explorer and other applications that operate on the file system.
The enforcement engine 914 performs the action specified in the triggered policy. The actions are any of allow, block, notify, justify, and audit. When a rule is triggered and an action is enforced, a log of this event is pushed to the cloud. The log identifies the monitored event and the file for which the action was enforced.
It will be appreciated that the endpoint DLP discussed herein can be provided by the DLP service 500, and can be provided with any of the features of the present disclosure.
The endpoint DLP process 950 can further include determining a DLP trigger for the one or more devices based on the DLP configurations for the one or more devices, and responsive to the DLP trigger, performing an action based thereon. The DLP configurations can include one or more DLP dictionaries, DLP engines, and rules. The one or more DLP dictionaries can be any of a predefined dictionary and a custom dictionary. Channels protected from exfiltration of sensitive data from the devices include copying to peripheral devices, printing, clipboarding, copying to local network shares, and Software-as-a-Service (SaaS) remote sync services. Prior to the receiving, the steps can further include authenticating the one or more devices with a cloud-based system using device Identification (ID) information; and establishing a Hypertext Transfer Protocol Secure (HTTPS) connection to fetch the device DLP configurations. The DLP configurations can be stored in bidirectional mapping structures. Safe listed file paths can be excluded from scanning. The scanning can include the steps of text extraction, tokenization, DLP matching, dictionary scoring, and engine expression evaluation.
The CASB system 2600 can be implemented in a cloud-based system, such as using the architecture of the cloud-based system 100. The CASB system 2600 can be implemented in a private cloud, a public cloud, or a hybrid cloud. Alternatively, the CASB system 2600 can be one or more servers 200 that can be located on-premises with an enterprise, off-premises, etc. Even further, the CASB system 2600 can be collocated with the SaaS providers 2608. That is, various architecture implementations are contemplated. Further, the CASB system 2600 contemplated both operations with the cloud-based system 100, operating as a distributed security system, as well as independent operation (i.e., with the components of the cloud-based system 100 omitted in
The objective of the CASB system 2600 is to provide enterprise IT control over data (resources) in the SaaS providers 2608. Note, as described herein, the enterprise can be referred to as a tenant of the provider 2608. The CASB system 2600 is configured to operate as a distributed file crawler for files associated with a particular tenant. The CASB system 2600 can both provide a report based on the file crawling as well as implement policy actions based on policy configuration.
The CASB system 2600 includes one or more APIs 2602, such as a Representational state transfer (REST) API. In an embodiment, the APIs 2602 connect to the cloud-based system 100, such as one of the nodes 150. Here, a user can interact with the CASB system 2600 via a User Interface (UI) 2604 through a central authority node 2606. Additionally, the cloud node 150 can connect to a log 2610, such as a data store that stores statistics and transactions, for reporting. The cloud node 150 can also connect to a DLP engine 2612 for data leakage protection through the CASB system 2600. Here, the CASB 2600 can be used to identify content, files, etc. that match sensitive data in a DLP dictionary. The user can provide policy and configuration via the UI 2604.
Again, the CASB system 2600 can be deployed without the cloud-based system 100. Here, the API 2602 can connect directly to the UI 2604, and the log 2610 and the DLP engine 2612 can be incorporated directly in the CASB system 2600, or in an external system.
The CASB system 2600 includes an authentication provider 2614 that is configured to perform authentication of the tenant with the SaaS providers 2608. The APIs 2602 and the authentication provider 2614 connect to a message broker 2616, which is configured to interact between the APIs 2602, the authentication provider 2614, and a plurality of workers 2618. A regulator 2620 is connected to the message broker. The message broker 2616 is a pipeline where job tickets are queued for consumption by the workers 2618.
In an embodiment, the authentication provider 2614, a controller for the APIs 2602, the regulator 2620, and the workers 2618 are Java Spring services, and other embodiments are also contemplated. The message broker 2616 can be a queuing service, such as using Apache Kafka, Microsoft EventHub, or other embodiments. The API controller is a liaison service that interfaces between the CASB system 2600 and the cloud-based system 100.
With respect to the authentication provider 2614, customer information, including tokens and credentials are not stored permanently or persisted. Also, the CASB system 2600 is not tied specifically to a particular SaaS provider 2608. That is, the CASB system 2600 is configured to operate with multiple, different SaaS providers 2608. This is accomplished through customized APIs and configured of the workers 2618. Each SaaS provider 2608 can have a different set of APIs and functionality.
The workers 2618 are connected to the SaaS providers 2608 and are dedicated to performing particular tasks. In a sense, the plurality of workers 2618 are organized in a pool of workers, and tasks are assigned between the workers 2618. The CASB 2600 can include a sandbox 2622 that can be connected to the DLP engine 2612, and the DLP engine 2612 can also include a REST API connection to the SaaS providers 2608. Note, the sandbox 2622 can be included in the CASB system 2600, or it can be an external system. The sandbox 2622 is configured to execute files, open files, etc. in a safe environment to analyze whether the files are malicious or not.
The worker pool is a collection of workers 2618 that interact with the SaaS provider 2608 and perform specific tasks. The pool of workers 2618 enables the CASB system 2600 to operate efficiently in a distributed nature. The workers 2618 are assigned tasks from various queues, via the message broker 2616 and the regulator 2620. Thus, the workers 2618 can operate akin to an assembly line, and there can be handoffs between workers 2618. For example, the workers 2618 can include authentication workers to authenticate users, tenants, etc., metadata workers to analyze file or content metadata, file workers to scan/analyze files, action workers to perform various policy-related actions, and the like.
The workers 2618 can logically be viewed as contract workers in a factory, on an assembly line, etc. The workers 2618 are provided specific instructions in a job ticket. The job ticket has information on what job to be performed, where to get the inputs, and where to send the outputs. Every worker 2618 also knows what to do when something goes wrong.
The regulator 2620 is like the SCADA (Supervisory Control and Data Acquisition) in a control system architecture. The regulator 2620 monitors the performance of all the workers 2618 and controls the overall system for optimum throughput.
Again, the message broker 2616 assigns jobs to the workers 2618. Here is an example of a job ticket for an example job:
Again, each different SaaS provider 2608 can have a different set of APIs and functionality. The CASB system 2600 is configured to interface with a plurality of different SaaS providers 2608. The log 2610 can be configured to store changes/events for an entire organization, including on a per user basis.
The APIs between the CASB 2600 and the SaaS providers 2608 may be limited, e.g., throttled by the SaaS providers 2608. As such, there is an initial baseline crawl (i.e., a first-run) where the CASB system 2600 has to crawl and scan all files in the SaaS provider 2608. This initial baseline crawl is performed efficiently and is synchronized with the DLP engine 2612. After the baseline crawl, subsequent crawls are performed incrementally, namely through files that changed since the previous crawl. For example, the first run can be referred to as run one, and each incremental crawl is run X, which only scans and crawls files that have changed since run X-1. In an embodiment, the period of incremental calls is once a day. Of course, other periods are also contemplated.
The SaaS providers 2608 generally provide two ways to crawl through the files for a tenant, namely crawling based on organization-wide file activity or a change log and crawling based on a pseudo-breadth-first traversal. The file activity or a change log enables crawling based on file changes. The pseudo-breadth-first traversal is crawling based on snapshots.
For illustration, an example operation is described in
For a run X (step 2801) where X is an integer greater than 1, the file crawling process 2800 includes, fetching admin logs from the last stream-position for a tenant (step 2807), processing the batch for unique file entries in the batch (step 2808), pushing file info to a queue (Q) (step 2809), repeating through above steps 2808, 2809 for all tenants until the entire log is crawled (step 2810), and storing the log's stream-position for a next Run (step 2811).
For run X (step 2851) where X is an integer greater than 1, the file crawling process 2850 includes fetching a list of entities for the tenant from store (step 2859), for each entity, crawling through the File System and capture the list of files (step 2860), storing the last delta link for every entity (step 2861), pushing the files in a queue (Q) (step 2862), after last user last file pushed in the queue (Q), updating tenant info about Run #completion (step 2863), and repeating through above steps for all tenants (step 2864).
The worker 2618 can add new events in the queue, and the broker 2616 can dequeue the new events when assigning back to a worker 2618 (step 3007). The worker 2618 gets file info (step 3008) and receives JSON file info from the SaaS provider 2608. The worker 2618 can scan each file in the queue (step 3009), provide results to the controller 2624, which dequeues the scanned file (step 3010).
The controller 2624 can provide results of the scan to the CASB client 2626, which returns information (step 3011). The controller 2624 can create a scan file (step 3011.1) and receive a post-action (step 3011.2) from the CASB client 2626. For example, the CASB client 2626 may perform DLP, and the action can be allow, delete, quarantine, etc. The controller 2624 can implement the policy action in the queue (step 3012), the brokers 2616 can dequeue the policy action (step 3013) and assign the action to the worker 2618 which posts the action in the SaaS provider (step 3014). The worker 2618 can provide the action result in a queue (step 3015), the broker 2616 can dequeue the action results (step 3016) and post the action result in the log (step 3017).
Data Security Posture Management (DSPM) represents a strategic evolution from traditional Cloud Access Security Broker (CASB) model. While CASBs served as critical tools for enterprises as they first embraced cloud computing, helping them manage user access, enforce policies, and maintain governance over sanctioned SaaS applications, they primarily focused on the perimeter of cloud security. As organizations grow beyond a handful of sanctioned services into multi-cloud ecosystems, data becomes distributed across numerous environments, including databases, object stores, and proprietary platforms. This proliferation introduces fresh challenges including sensitive data sprawled across diverse services, misconfigurations left data repositories exposed, and increasingly stringent regulations demanded tighter visibility and control. CASBs, originally designed to mitigate shadow IT and manage application access, were not built to discover, classify, and continuously monitor sensitive data at scale. They lack the granular insight required to determine where data lived, how it was protected, and how it was handled throughout the cloud lifecycle.
In response to these limitations, a shift toward data-centric security emerged. Rather than merely focusing on who could access which cloud applications, organizations recognized the need to understand the nature, location, and security posture of their data itself. This new mindset underpinned the rise of DSPM. By providing automated data discovery, classification, and contextual risk analysis, DSPM offers continuous insight into how data flows through cloud environments, whether it is adequately protected, and who interacts with it. The result is a model that goes beyond the access and application layers covered by CASB, delivering comprehensive data security posture management tailored to meet the demands of multi-cloud complexity and regulatory scrutiny.
In addition to improving data visibility, DSPM complements and extends the functionality of CASB. Rather than replacing CASB solutions entirely, the present DSPM tool integrates seamlessly with them. The present CASB platform incorporates DSPM-like features, ensuring that an organization's approach to cloud security is both layered and holistic. In such a scenario, CASB continues to ensure secure, compliant access to sanctioned applications, while DSPM focuses on safeguarding the data that flows across and resides within various environments. Together, they support a zero-trust security model where access control and data protection work in tandem, ultimately providing the robust, end-to-end security posture that today's cloud-driven enterprises require.
The present cloud-based Data Security Posture Management (DSPM) is a robust and sophisticated solution designed to enhance the security and compliance of an organization's data across diverse environments, including cloud, hybrid, and on-premises infrastructures. It focuses on providing comprehensive visibility, control, and protection for sensitive data by identifying, managing, and mitigating potential security risks. The cloud-based DSPM is a data-centric security solution aimed at ensuring the security posture of an organization's data, i.e., the data of a tenant of the cloud-based system 100. It utilizes advanced technologies such as machine learning and Artificial Intelligence (AI) to continuously monitor and analyze data access patterns, detect anomalies, enforce security policies, and ensure regulatory compliance. This solution offers a holistic view of the data security landscape, helping organizations protect their sensitive information from unauthorized access and breaches.
Cloud-based DSPM operates through a multi-faceted approach. It begins by discovering and classifying sensitive data across all environments, involving scanning data repositories and using predefined or custom policies to identify and categorize data based on sensitivity and compliance requirements. The solution implements continuous monitoring of data access and usage patterns, leveraging machine learning to establish baselines and detect deviations or anomalies that could indicate potential security threats. It evaluates the security posture by assessing risks associated with data exposure and access, including identifying misconfigurations, vulnerabilities, and non-compliant activities. Based on the risk assessment, the cloud-based DSPM enforces security policies to control access to sensitive data, ensuring that only authorized users have access and that data handling complies with organizational and regulatory policies. In the event of a detected anomaly or security incident, the solution triggers automated responses to mitigate risks, which could include alerting security teams, blocking access, or initiating data encryption.
Implementing cloud-based DSPM involves several steps. The process starts with planning, where the scope and objectives of the DSPM implementation are defined, and the data repositories and environments to be covered are identified. Next is deployment, where the cloud-based DSPM system is integrated with the existing IT infrastructure by setting up connectors and agents for data discovery and monitoring. Configuration follows, customizing data classification policies according to organizational needs and configuring monitoring and alerting thresholds. Baseline establishment is essential, allowing the system to establish normal data access and usage patterns. Policy definition involves developing and enforcing security policies based on the risk assessment and compliance requirements. Training and awareness are crucial, educating employees and stakeholders on the new data security measures and their roles in maintaining data security. Continuous improvement is necessary, regularly reviewing and updating policies, configurations, and procedures to adapt to evolving threats and compliance requirements.
Implementing DSPM in the cloud-based system 100 includes several specific actions. Cloud integration involves integrating DSPM with cloud service providers (CSPs) such as Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP), utilizing APIs and native connectors to facilitate seamless data discovery and monitoring. Cloud data discovery entails performing a comprehensive scan of cloud storage services, databases, and applications to identify and classify sensitive data. Developing and enforcing cloud-specific security policies are crucial for controlling access and ensuring data protection, which includes configuring Identity and Access Management (IAM) settings, encryption standards, and compliance requirements. Automated monitoring enables continuous monitoring of cloud data access and usage, using machine learning models to detect anomalies specific to the cloud environment. Incident response in the cloud involves implementing automated incident response mechanisms tailored for cloud environments, including real-time alerts, access revocation, and data encryption in response to detected threats. Compliance management ensures that cloud data handling complies with relevant regulations and standards, using the cloud-based DSPM's reporting and audit features to demonstrate compliance during audits. In summary, the cloud-based DSPM is a critical tool for organizations aiming to secure their sensitive data across all environments, combining advanced technology with strategic implementation steps to provide robust data security posture management, ensuring that data remains protected, compliant, and resilient against modern cyber threats.
A significant portion of internet traffic is encrypted, which can hide malicious activities. Based thereon, the cloud-based DSPM system performs SSL/TLS inspection to decrypt, inspect, and re-encrypt secure traffic. This process ensures that encrypted data is thoroughly inspected for potential threats without compromising privacy and performance. By decrypting the traffic, the system can apply security policies and detect threats hidden within encrypted data streams.
In various embodiments, the cloud-based DSPM system leverages an extensive threat intelligence database that is continuously updated with the latest information on malware, phishing sites, malicious URLs, and other cyber threats. As data moves through the cloud-based system 100, it is inspected in real-time against this database. Advanced threat protection mechanisms, including sandboxing and behavior analysis, are employed to detect and block zero-day threats and other sophisticated attacks. The DLP capabilities described herein are a critical component of securing data in motion. The system scans traffic for sensitive data patterns and enforces policies to prevent unauthorized data exfiltration. This helps to protect intellectual property, personal data, and other sensitive information from being leaked or stolen as it moves across the network.
The cloud-based DSPM system further applies content filtering policies to block access to inappropriate or harmful websites, categorizing web content and enforcing policies based on organizational requirements. Additionally, it provides granular control over cloud applications, identifying and managing access to both sanctioned and unsanctioned applications. This control minimizes risks associated with shadow IT and ensures that only approved applications are used, thereby securing data as it interacts with various applications.
These inline inspection capabilities further provide detailed logging and reporting abilities, offering insights into traffic patterns, security incidents, and policy enforcement. This continuous monitoring and analysis enable security teams to detect anomalies and respond to security events promptly, ensuring that data in motion is continuously protected.
By operating on a Secure Access Service Edge (SASE) framework, the cloud-based system converges networking and security services into a single cloud-delivered platform. This ensures that security policies are consistently enforced across all data traffic, regardless of the user's location or the device being used. The SASE architecture simplifies security operations and enhances scalability, allowing organizations to manage and secure data in motion effectively.
Once data is classified, the system enforces security policies tailored to the sensitivity of the data. These policies govern who can access the data, under what conditions, and what actions they can perform. By integrating with CSPs, the cloud-based system 100 ensures that access controls are consistently applied across all cloud environments. This includes configuring Identity and Access Management (IAM) settings to prevent unauthorized access and ensuring that only authorized users can interact with sensitive data.
Real-time monitoring of data access and usage patterns in the cloud-based system is performed. By analyzing these patterns, the system establishes a baseline of normal behavior. Machine learning and advanced analytics are used to detect anomalies that may indicate potential security threats, such as unusual access patterns, excessive data downloads, or access from unexpected locations. When such anomalies are detected, the system can trigger alerts and initiate automatic responses to mitigate risks.
Again, a crucial aspect of securing data in the cloud is preventing data leaks. Based thereon, the system includes robust DLP capabilities that scan cloud-hosted data for sensitive information and enforce policies to prevent unauthorized data exfiltration. This involves monitoring data transfers, scanning outbound communications, and applying encryption or redaction policies to protect sensitive data from being exposed or stolen. Additionally, ensuring compliance with industry regulations and standards is a critical component of data security. The present DSPM system helps organizations adhere to regulatory requirements by continuously scanning cloud environments for compliance violations and generating detailed audit reports. These reports provide insights into data handling practices, policy enforcement, and any detected anomalies or breaches, helping organizations demonstrate compliance during audits.
Again, as stated, the system also integrates with threat intelligence feeds and continuously updates its knowledge base with the latest information on cyber threats. This enables the system to detect and respond to potential threats in real-time. Advanced threat protection mechanisms, such as sandboxing and behavior analysis, are employed to analyze suspicious activities and block malicious actions before they can compromise data. In the event of a detected security incident, the system can automate remediation actions to minimize the impact. This includes revoking access, encrypting data, and isolating compromised accounts or systems. Automated remediation ensures that threats are addressed promptly, reducing the risk of data breaches and minimizing the window of exposure.
Similarly, for securing data at endpoint devices, the system integrates with endpoint devices using lightweight agents or connectors. These agents are installed on user devices, such as laptops, desktops, and mobile devices, creating a direct link between the endpoints and the cloud-based system. This integration ensures that all data traffic from the endpoints is routed through the cloud-based security platform for inspection and policy enforcement. Once integrated, the cloud-based DSPM system continuously monitors data access and usage at the endpoints. It tracks user activities, data movements, and endpoint interactions with cloud services. By analyzing these patterns, the system can identify potential security risks, such as unusual data access behaviors, unauthorized data transfers, or suspicious application activities. This continuous monitoring helps in establishing a baseline for normal behavior and detecting anomalies in real-time.
The system further automates the classification of sensitive data stored or accessed on endpoints. It scans files, documents, and communications for sensitive information. Based on predefined or customizable policies, the system categorizes data and applies appropriate security measures as described herein. It further scans outbound communications from endpoint devices, such as emails, file uploads, and cloud storage interactions, for sensitive data patterns. Policies are enforced to block unauthorized data transfers, alert security teams, or automatically encrypt data to prevent exposure.
To further secure data at endpoints, the cloud-based DSPM system supports endpoint encryption. Sensitive data stored on devices is encrypted, ensuring that even if an endpoint is lost or stolen, the data remains protected and inaccessible to unauthorized users. Encryption keys are managed securely, and encryption policies are enforced centrally through the cloud-based system 100.
Therefore, the present disclosure provides systems and methods for a comprehensive cloud-based DSPM approach. Various embodiments ensure that data is discovered, classified, monitored for compliance and security risks, protected through policy enforcement, and continuously audited to meet evolving regulatory requirements.
In various embodiments, data discovery involves scanning various environments including SaaS, IaaS, hybrid, on-premises, databases, object stores, endpoints, and private platforms to identify sensitive data. Classification policies can be predefined or customizable based on an organization's unique compliance mandates, internal governance frameworks, or industry-specific standards. Once data is classified, continuous monitoring leverages machine learning to establish baselines of normal behavior and detect anomalies such as unauthorized access patterns, insider threats, or data exfiltration attempts. The monitoring can occur at rest or in motion, including inline inspection of encrypted traffic to thwart malicious activity concealed within SSL/TLS-encrypted channels.
Risk evaluation involves identifying misconfigurations, excessive permissions, or vulnerabilities in cloud storage buckets, IAM configurations, or encryption practices. As these issues are surfaced, policy enforcement modules can automatically restrict access, apply encryption, issue alerts, or implement data loss prevention measures to prevent data leakage. The reporting interface provides a transparent view into data handling, mapping sensitive datasets to applicable regulatory regimes and generating audit logs that facilitate compliance verification. Security teams gain insights from dashboards and analytics tools, enabling them to review historical incidents, track ongoing compliance efforts, and support continuous improvement of their security posture.
Endpoint integration enables the cloud-based DSPM system to continuously monitor endpoint interactions with cloud environments. By analyzing outbound communications and applying classification policies and encryption, the system prevents inadvertent data leaks or unauthorized transfers.
In summary, the cloud-based DSPM system secures data stored in cloud services and at endpoints by integrating with devices and services, continuously monitoring data access and usage, classifying and protecting sensitive information, preventing data loss, detecting and responding to threats, enforcing compliance and security policies, managing secure access, and supporting endpoint encryption and automated remediation. This comprehensive approach ensures that endpoint data remains secure, compliant, and resilient against potential cyber threats.
The process 3300 can further include generating compliance reports and audit logs reflecting data handling practices and security policy enforcement. The compliance reports can include dashboards and visual analytics tools for reviewing detected anomalies, remediation actions taken, and overall compliance posture over time. The discovering and classifying can include identifying sensitive data based on predefined or customizable classification policies. The policies can include at least one of restricting access, encrypting data, or alerting security personnel. The discovering and classifying can further include scanning data assets in one or more of Software as a Service (SaaS) platforms, Infrastructure as a Service (IaaS) platforms, on-premises data stores, databases, object stores, or private applications. The monitoring can include utilizing machine learning to establish baseline data access patterns and detect anomalous behavior that indicates insider threats, unauthorized access, or data exfiltration attempts. Enforcing one or more security policies can further include applying Data Loss Prevention (DLP) to block or redact sensitive information, and automatically implementing encryption or revocation of access privileges in response to detected anomalies. The discovering and classifying can include integrating with Cloud Service Provider (CSP) Application Programing Interfaces (APIs) and native connectors to scan storage services, databases, containers, and virtual machines for data. Evaluating the security posture can include identifying misconfigurations in cloud storage buckets, improper Identity and Access Management (IAM) settings, or ineffective encryption measures.
It will be appreciated that some embodiments described herein may include or utilize one or more generic or specialized processors (“one or more processors”) such as microprocessors; Central Processing Units (CPUs); Digital Signal Processors (DSPs): customized processors such as Network Processors (NPs) or Network Processing Units (NPUs), Graphics Processing Units (GPUs), or the like; Field-Programmable Gate Arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more Application-Specific Integrated Circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as “circuitry configured to,” “logic configured to,” etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.
Moreover, some embodiments may include a non-transitory computer-readable medium having instructions stored thereon for programming a computer, server, appliance, device, processor, circuit, etc. to perform functions as described and claimed herein. Examples of such non-transitory computer-readable medium include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically EPROM (EEPROM), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by a processor or device (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause a processor or the device to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.
Although the present disclosure has been illustrated and described herein with reference to preferred embodiments and specific examples thereof, it will be readily apparent to those of ordinary skill in the art that other embodiments and examples may perform similar functions and/or achieve like results. All such equivalent embodiments and examples are within the spirit and scope of the present disclosure, are contemplated thereby, and are intended to be covered by the following claims.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17952696 | Sep 2022 | US |
| Child | 19070792 | US | |
| Parent | 18098258 | Jan 2023 | US |
| Child | 19070792 | US | |
| Parent | 16996965 | Aug 2020 | US |
| Child | 19070792 | US | |
| Parent | 16853862 | Apr 2020 | US |
| Child | 19070792 | US | |
| Parent | 16923225 | Jul 2020 | US |
| Child | 19070792 | US |
