Network-aware endpoint data loss prevention for web transactions

Methods for network aware endpoint data loss prevention (DLP) in web transactions are performed by systems and devices, which includes implementing DLP on endpoint devices and focuses on web traffic events from web browsers, while also associating the events to the network source entity. File download and upload events are intercepted from the operating system by a file system filter that determines the process creating events is a web browser based on process identifiers and comparing process names and process executable signatures. A uniform resource locator (URL) from a current tab or session is retrieved for the web browser. Policies for events are evaluated via a policy server or via cache, and additional data from the file is provided for policy decisions when necessary. DLP actions taken via the file system filter to block or allow events, including encrypting file data, are based on the policy decisions.

BACKGROUND

Current data loss prevention (DLP) solutions are either network based, e.g., via a proxy, or endpoint based, e.g., with a presence on the client machine. Network based solutions lack visibility to all events without a client presence. Some solutions utilize injections JavaScript™ (from Oracle Corporation) code to run on the client device in order to emulate or perform client-side controls. This JavaScript™ code impacts the performance and users' experience when browsing websites, and it requires heavy computation resources for DLP providers and hosts. On the other hand, endpoint DLP solutions are not able to associate the DLP activities such as downloads and uploads with network resources and applications because of the complexity involved.

SUMMARY

Methods for network aware endpoint data loss prevention (DLP) in web transactions are performed by systems and devices, which includes implementing DLP on endpoint devices and focuses on web traffic events from web browsers, while also associating the events to the network source entity. File download and upload events are intercepted from the operating system by a file system filter that determines the process creating events is a web browser based on process identifiers and comparing process names and process executable signatures. A uniform resource locator (URL) from a current tab or session is retrieved from the web browser by querying an open tabs database. Policies for events are evaluated via a policy server or via cache, and additional data from the file is provided for policy decisions when necessary. DLP actions taken via the file system filter to block or allow events, including encrypting file data, are based on the policy decisions.

Further features and advantages, as well as the structure and operation of various examples, are described in detail below with reference to the accompanying drawings. It is noted that the ideas and techniques are not limited to the specific examples described herein. Such examples are presented herein for illustrative purposes only. Additional examples will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

DETAILED DESCRIPTION

The following detailed description discloses numerous embodiments. The scope of the present patent application is not limited to the disclosed embodiments, but also encompasses combinations of the disclosed embodiments, as well as modifications to the disclosed embodiments.

Furthermore, it should be understood that spatial descriptions (e.g., “above,” “below,” “up,” “left,” “right,” “down,” “top,” “bottom,” “vertical,” “horizontal,” etc.) used herein are for purposes of illustration only, and that practical implementations of the structures and drawings described herein can be spatially arranged in any orientation or manner. Additionally, the drawings may not be provided to scale, and orientations or organization of elements of the drawings may vary in embodiments.

Section II below describes example embodiments for network aware endpoint DLP in web transactions. Section III below describes example mobile and computing device embodiments that may be used to implement features of the embodiments described herein. Section IV below describes additional examples and advantages, and Section V provides some concluding remarks.

II. Example Aspects for Network Aware Endpoint DLP in Web Transactions

Data loss prevention (DLP) techniques provide different network- and endpoint-based implementations for securing and protecting data in network and Internet communications. DLP solutions seek to minimize data exfiltration and malicious content infiltration for computing systems and networks. Embodiments herein provide for network aware endpoint DLP in web transactions that enable the benefits of both network- and endpoint-based DLP, but without the drawbacks of either.

One example of these embodiments is an implementation of a file system filter at the operating system (OS) level. It should be noted, however, that the example implementations are not limiting, but rather, are illustrative in nature. The file system filter may reside in the kernel of the OS, or both in the kernel and in the user-space which may allow for additional flexibility for operational calls in performance of network aware endpoint DLP in web transactions.

The embodiments herein provide for implementing DLP on endpoint, or client, devices and focuses on web traffic events from web browsers, such as file reads and file writes at the endpoint device. While web traffic events are a focus, as they involve the endpoint, the described DLP solutions also enable associating these events at the endpoint to the network source entity, of which prior endpoint solutions had no knowledge. File download events, corresponding to endpoint device writes, and file upload events, corresponding to endpoint device reads, are intercepted from the OS and file system by a file system filter. As noted above, the file system filter resides in at the OS level, at least partially in the system kernel.

The file system filter determines if the process creating or causing the events is a web browser application. The file system filter makes these determinations based at least on process identifiers associated with the intercepted events and comparisons of process names and process executable signatures. The file system filter identifies and retrieves a uniform resource locator (URL) from a current tab or session for web browser applications determined to create or cause the events. URLs may be retrieved by querying an open tabs database of a web browser application or the web browser application itself, by reading a current session file of the web browser application, by reading the URL from an OS-level metadata file that includes origin information of download files, and/or the like. Policies for events are evaluated via policy server or via cache for repeated transactions, and additional data from the file is provided for policy decisions when necessary. File data for download events is buffered, without persistently storing it, for provision to the policy server. DLP actions taken via the file system filter to block or allow events, including encrypting file data based on policy decisions.

Prior DLP solutions have several shortcomings. Network-only based DLP solutions do not see all DLP events. That is, because not all downloads and/or uploads are transferred “as-is” or “on the wire,” network-based solutions lack the ability to identify various DLP events during network transmissions. Additionally, some prior, network-based DLP solutions utilize JavaScript™ to perform client-side DLP controls, yet this impacts the performance for loading and interacting with web pages at the client endpoint, and also requires heavy resource commitments to modify all JavaScript™ code sent from all protected applications. A client-side DLP presence alleviates these issues, but has its own drawbacks. While endpoint DLP solutions are able to inspect DLP controls on the client side, such implementations are not able to associate DLP events with web activity, and this prevents endpoint DLP solutions from taking remote device identities into consideration.

Thus, to avoid the issues noted above, the described network aware endpoint DLP in web transactions via a file system filter enable both client-side DLP event awareness together with operations and techniques that identify associated network-side information needed for DLP policy determinations and actions, without the need to generate and inject additional code in network transmissions. Accordingly, the embodiments herein provide solutions that improve systems via network aware endpoint DLP in web transactions. These and other embodiments will be described in further detail below in association with the Figures, and in the Sections/Subsections that follow.

Systems, devices, and apparatuses may be configured in various ways for network aware endpoint DLP in web transactions. For instance,FIG.1is a block diagram of a system100, according to embodiments. System100is configured for network aware endpoint DLP in web transactions, according to embodiments. As shown inFIG.1, system100includes a remote computing device102(also “remote device”102herein), a policy server104, and a client computing device108(also “client device”108herein) that communicate in embodiments with each other over a network110. It should be noted that in various embodiments different numbers of remote devices, client devices, networks, and/or policy servers are present, and additionally, according to embodiments, any combination of the systems and/or components illustrated inFIG.1are present in system100. For example, embodiments of system100having cloud- and/or network-based systems and devices are included herein, where embodiments enable network aware endpoint DLP in web and/or other network transactions.

Network110comprises different numbers and/or types of communication links that connect computing devices and hosts/servers such as, but not limited to, the Internet, wired or wireless networks and portions thereof, point-to-point connections, local area networks, enterprise networks, cloud networks, and/or the like, in embodiments. For example, as exemplarily illustrated, network110may comprise the Internet, a cloud-based platform or architecture, an enterprise network, etc., and may include remote device102and/or policy server104, at one or more geographic locations. In another example, network110may be a cloud-based platform network and/or enterprise network to which remote device102and/or client device106connect via the Internet or another network. Additionally, remote device102, policy server104, and/or client device106may be implemented in any number or combination of network types.

Remote device102, in embodiments, comprises one or more server computers or computing devices, which may include one or more distributed or “cloud-based” servers. In embodiments, remote device102is associated with, or is a part of, a cloud-based service platform, and in some embodiments, remote device102comprises an on-premises server(s) in addition to, or in lieu of, cloud-based servers. Remote device102in various embodiments includes any number, type, or combination of other computing devices and/or computing systems, including a terminal, a personal computer, a laptop computer, a tablet device, a smart phone, a personal digital assistant, a server(s), a gaming console, and/or the like, that may include internal/external storage devices, that are utilized to host services and/or applications, and/or to otherwise make available any type of information, data, files, programs, and/or the like, to client devices such as client device106. Additionally, remote device102in various embodiments is any number, type, or combination of computing devices and/or computing systems to which any type of information, data, files, programs, and/or the like may be transmitted from client device106.

Remote device102is configured to host and execute any type of service and/or application accessed/utilized by a user of client device102that may include the transfer of data, information, files, etc., e.g., a DB server application, an email application/service, a document sharing service, productivity applications, etc. (not shown for brevity and illustrative clarity), and in some aspects, remote device102may store and/or transmit malicious software/code such as viruses, malware, etc. In embodiments, client device106communicates with remote device102via a web browser application executing at client device106, e.g., electronic communications that include data packets, requests, and/or the like. Remote device102may be a computing device or system of a cloud-based platform that hosts services, applications, etc., for tenants. Remote device102also includes additional components (not shown for brevity and illustrative clarity) including, but not limited to, components and subcomponents of other devices and/or systems herein, e.g., as shown inFIG.2,FIG.9, and/orFIG.10described below, in accordance with embodiments.

Policy server104comprises one or more server computers or computing devices, which may include one or more distributed or “cloud-based” servers. In embodiments, policy server104is associated with, or is a part of, a cloud-based service platform, and in some embodiments, policy server104comprises an on-premises server(s) in addition to, or in lieu of, cloud-based servers. Policy server104is configured to store policies and host a policy engine that evaluates events, as described herein, for compliance with the policies. As illustrative examples, policies may be implemented via policy server104that prohibit events such as the upload or download of certain types of files, data, information, etc., that allow or block such events, that require encryption for such events, and/or the like, based at least on one or more factors, including but without limitation: an identity or type of service/application of a remote device associated with the event, the content of the files or content portions thereof, data, information, etc., an identity of the user of a client device, and/or the like. Policy server104is configured to receive the above factors from client device106and to return indicia of policy decisions and/or determinations. In embodiments, policy server104is configured to request additional portions of the files, data, information, etc., to make the policy decisions and/or determinations.

Client device106, in embodiments, comprises one or more computers or computing devices. Client device106in various embodiments includes any number, type, or combination of other computing devices and/or computing systems, including a terminal, a personal computer, a laptop computer, a tablet device, a smart phone, a personal digital assistant, a server(s), a gaming console, and/or the like, that may include internal/external storage devices, that are utilized to access services and/or applications, and/or to otherwise upload and/or download any type of information, data, files, programs, and/or the like, to/from remote devices such as remote device102. In embodiments, client device106is associated with a cloud-based service platform in which client device106is a member of a tenancy. Additionally, as noted above, client device106is configured to communicate with remote device102via a web browser application executing at client device106for electronic communications. Client device106may be configured to execute any type of operating system (OS) and any type of web browser application.

As shown inFIG.1, client device106includes a file system filter108. In embodiments, file system filter108is an OS-level driver or filter that may reside in the kernel and/or the user space of the OS implemented by client device106. File system filter108is configured to intercept upload and download events initiated via a web browser application of client device106. For instance, upload events correspond to file reads to the file system of the client device106OS, and download events correspond to file writes to the file system. These events are intercepted by file system filter108at the OS-level in order to determine if a web browser application initiates these events, and if so, to facilitate determinations for handling the events according to policy requirements for network aware endpoint DLP at client device106. Further details regarding file system filter108are provided below.

Client device106also includes additional components (not shown for brevity and illustrative clarity) including, but not limited to, components and subcomponents of other devices and/or systems herein, e.g., as shown inFIGS.2,9, and/or10described below, in embodiments.

As noted and described herein, computing devices and systems are applicable to any type of system for network aware endpoint DLP in web transactions, according to embodiments. One example of implementations noted above are network, or “cloud,” implementations, applications, or services in a network architecture/platform. A cloud platform includes a networked set of computing resources, including servers, routers, etc., that are configurable, shareable, provide data security, and are accessible over a network such as the Internet, according to embodiments. Cloud applications/services such as those hosted by remote computing device102, etc., in various embodiments are configured to run on these computing resources, often atop operating systems that run on the resources, for entities that access the applications/services, locally and/or over the network. A cloud platform is configured to support multi-tenancy, where cloud platform-based software services multiple tenants, with each tenant including one or more users who share common access to software services of the cloud platform. Furthermore, a cloud platform is configured to support hypervisors implemented as hardware, software, and/or firmware that run virtual machines (emulated computer systems, including operating systems) for tenants. A hypervisor presents a virtual operating platform for tenants. In some embodiments herein, tenants of cloud-based implementation services may communicate with cloud-based servers and hosts utilizing network aware endpoint DLP in web transactions, as described herein.

Client devices, such as client device106, are configured in various ways for network aware endpoint DLP in web transactions via file system filter108. For instance, referring now toFIG.2, a block diagram of a system200is shown for network aware endpoint DLP in web transactions, according to an example embodiment. System200is configured to be an embodiment of system100ofFIG.1, e.g., client device106. System200is described as follows and may reference the described devices, systems, components, etc., of system100inFIG.1.

System200includes a computing system202, which is an embodiment of a system, server, or computing device at which a described file system filter is implemented, and which is any type of computing device or computing system, as mentioned elsewhere herein or as otherwise known. As shown inFIG.2, computing system202includes one or more processors (“processor”)204, one or more of a memory and/or other physical storage device (“memory”)206, as well as one or more network interfaces (“network interface”)226. Computing system202includes an OS212and a web browser application222. In embodiments, while not shown for brevity and illustrative clarity, computing system202includes additional software, applications, and/or additional ones of components illustrated inFIG.2, as would be understood by one of skill in the relevant art(s) having the benefit of this disclosure.

System200also includes additional components (not shown for brevity and illustrative clarity) including, but not limited to, components and subcomponents of other devices and/or systems herein, as well as those described below with respect toFIG.9and/orFIG.10, according to embodiments.

Processor204and memory206may respectively be any type of processor circuit(s) and memory that is described herein, and/or as would be understood by a person of skill in the relevant art(s) having the benefit of this disclosure. Processor204and memory206may each respectively comprise one or more processors or memories, different types of processors or memories, remote processors or memories, and/or distributed processors or memories. Processor204may be multi-core processors configured to execute more than one processing thread concurrently, and cores of processor204may be grouped with portions of memory206. Processor204may comprise circuitry that is configured to execute computer program instructions such as, but not limited to, embodiments of OS212and/or web browser application222, including one or more of the components thereof as described herein, which may be implemented as computer program instructions to perform network aware endpoint DLP in web transactions, as described herein.

Memory206may include volatile storage portions such as a random access memory (RAM), cache(s), etc., and/or persistent storage portions such as hard drives, nonvolatile RAM, and/or the like, to store or be configured to store computer program instructions/code as described herein, as well as to store other information and data described in this disclosure including, without limitation, OS212, a kernel210, a file system filter208, files associated with a file system214, a process list216, origin metadata218, daemon/API(s)220, web browser application222, browser data224, and/or browser certificates and hash values228, including one or more of the components thereof as described herein, etc.

Network interface226may be any type or number of wired and/or wireless network adapter, modem, etc., configured to enable system200, including computing system202, to communicate with other devices and/or systems over a network, including cloud networks, such as communications between computing system202and other devices, systems, hosts, etc., of system100inFIG.1over a network such as network110and/or the like.

Web browser application222may be any type of web browser application/program and is configured to enable a user of computing system202to interact with a remote device, e.g., remote device102inFIG.1, via the Internet or other network, as described herein and as would be understood by a person of skill in the relevant art(s). For example, web browser application222may be a Microsoft Edge® browser from Microsoft Corporation of Redmond, WA, a Firefox® browser from Mozilla Corporation of San Francisco, CA, a Safari® browser from Apple, Inc. of Cupertino, CA, a Chrome® browser from Google Inc. of Mountain View, CA, or any other web browser application. Web browser application222executes in a system memory of memory206, and may store in memory206browser data224. Browser data224includes session/tab information for a browser application of a given type that includes information and data describing current/active sessions, tabs, instances, etc., of web browser application222. Browser data224may be updated in real-time, or approximately in real-time, to accurately track activities of web browser application222. While a single web browser application is shown for web browser application222, this is for purposes of illustrative clarity, and two or more of web browser application222being present is contemplated for embodiments herein.

Also associated with web browser application222is browser certificates and hash values228, which may be persisted in memory206. Browser certificates and hash values228includes a list or other type of data structure of publisher certificates and hash values that correspond to the identity of web browser application222and instances, sessions, and/or tabs thereof, and enable file system filter208to verify and/or identify the instances, sessions, and/or tabs as processes that initiate or cause events to be intercepted and handled for network aware endpoint DLP in web transactions, as described herein.

OS212may be any type of operating system and is configured to be executed by computing system202. OS212may be any version of Microsoft® Windows® from Microsoft Corporation of Redmond, WA, macOS® from Apple, Inc. of Cupertino, CA, mobile device versions thereof, or any other operating system, including LINUX® and other UNIX® variants, by way of example. In the context of versions for Microsoft® Windows®, file system filter208may comprise a “minifilter” driver in the kernel of the OS that communicates with file system214for calling filtering functions of the driver. While embodiments herein may be described and/or illustrated with respect to a particular OS, it should be understood that similar and/or equivalent implementations of aspects herein for different OSs are contemplated under the same described techniques for network aware endpoint DLP in web transactions. That is, exemplary descriptions herein are non-limiting and serve to illustrate aspects of network aware endpoint DLP in web transactions across different platforms and implementations without limitation.

OS212includes file system214, which is a file system configured to manage the formatting and persistent storage of data, information, and files in memory206of computing system202, and process list216, which is a list stored in memory206that includes the processes currently running on processor204, as well as information associated with such processes (e.g., process identifiers, execution paths, etc.). OS212may also maintain metadata for file origins in origin metadata218, including source origins of download files, e.g., an associated URL, and origin metadata218may be stored, e.g., persistently, in memory206by OS212. In the context of specific OS platforms, origin metadata218may be stored in extended properties of the Apple® file system in macOS® versions, and in Windows® OS versions, e.g., employing the New Technology File System (NTFS), origin metadata218may be stored in the default file system, e.g., file system214inFIG.2. Portions of origin metadata218, such as the URL, may be stored at the OS-level as extended file properties and/or low-level hidden properties of the download files.

OS212further includes kernel210that operates in a kernel space of OS212, as would be understood by a person of skill in the relevant art(s). Kernel210includes file system filter208. File system filter208is a network-aware, OS-level driver or filter, which may be an embodiment of file system filter108ofFIG.1. While shown for illustrative clarity and brevity as being within kernel210, file system filter208may also have components thereof that reside outside of the kernel space in the user space of OS212, or a combination of kernel space and user space components. For instance, OS212may include daemon/API(s)220comprising a user-space daemon configured to perform functions and operations of file system filter208, including API calls for information and/or operations, as well as for event control when events are intercepted by file system filter208, as described herein. Equivalently, in some embodiments, e.g., in the context of macOS®, AppleScript® may be used to make calls for information to web browser application222, which is exposed to AppleScript® in macOS®.

When requests for reads of and writes to files are sent to file system214via OS212, file system filter208is configured to intercept these requests, as events, and hold them, if necessary, for policy determinations to be made thereon. In embodiments, an intercepting component of file system filter208may reside in kernel210, while other components reside in the user-space of OS212, e.g., in daemon/API(s)220. An event may be held when file system filter208identifies the initiator, or cause, of the event to be a web browser such as web browser application222. If the initiator of the event is determined to be web browser application222, file system filter208is configured to retrieve a uniform resource locator (URL) corresponding to the event and to web browser application222, and to perform one or more DLP actions against the event. The DLP actions taken may be based on a policy determination, e.g., via cached policy indicia or by a policy server such as policy server104inFIG.1, and file system filter208is configured to provide the URL and file data to the policy server for policy determinations to be made thereby, and to receive such determinations when made.

Further details regarding file system filter208are provided below. For example,FIGS.3and4will now be described.

FIG.3shows a flow diagram300for network aware endpoint DLP in web transactions, according to an example embodiment. Flow diagram300is provided in the context of file system filter208ofFIG.2.FIG.4shows a flowchart400for network aware endpoint DLP in web transactions, according to example embodiments. System100inFIG.1and/or system200inFIG.2, e.g., via file system filter208, operate according to flow diagram300and flowchart400(which may be an embodiment of flow diagram300ofFIG.3).

Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following descriptions. Flow diagram300and flowchart400are described below with respect to system100inFIG.1and system200ofFIG.2.

As noted above, flow diagram300illustrate file system filter208. As shown, file system filter208includes an event interceptor302, an event controller304, and API(s)306. In embodiments, event controller304and/or one or more of API(s)306may reside in the user space of OS212, e.g., in daemon/API(s)220as noted above forFIG.2, and file system filter208is configured to communicate directly and/or indirectly (e.g., via API calls of API(s)306) with policy server104ofFIG.1, as well as with components of the user space in OS212and web browser application222ofFIG.2.

Turning also now toFIG.4, flowchart400begins at step402. In step402, an event is intercepted in the OS, the event being a read of or a write to a file. For instance, event interceptor302is configured to intercept calls to the file system (e.g., file system214ofFIG.2), shown as an event308, that specify reads of files and writes to files. Event interceptor302includes hooks or other mechanisms to monitor calls to the file system in order to detect reads of and writes to files managed by the file system that may be initiated by web browser application222. The inclusion of file system filter208in OS212, e.g., at kernel210, enables such monitoring by file system filter208. When event308is detected, event information310associated with event308, such as but not limited to a file name, a process identifier of the process initiating event308, and/or the like, is determined from event308and passed from event interceptor302to event controller304, which is configured to manage or handle events such as event308that are intercepted by event interceptor302of file system filter208.

As shown in flow diagram300, event controller304is configured to make invocations312to API(s)306in performance of network aware endpoint DLP in web transactions. In embodiments, invocations312to API(s)306may be made by event interceptor302in lieu of, in conjunction with, and/or in addition to invocations312from event controller304. Invocations312made by event controller304may be to ones of API(s)306for communicating with policy server104ofFIG.1, as well as with components of the user space in OS212(e.g., as described above forFIG.2) and web browser application222ofFIG.2. In an example, event interceptor302and/or event controller304may invoke one of API(s)306to make a call to the user space in OS212(e.g., file system214) and/or to web browser application222to halt, or hold, the read or write operation associated with event308subsequent to the intercepting performed in step402described above.

Referring again toFIG.4, flowchart400continues at step404in which it is determined that a process executing at the computing device and causing the event to occur is an instance of a web browser application. For example, event controller304makes one or more invocations312to API(s)306for information related to the process that initiated event308based at least on event information310. In response, API(s)306issue calls314to obtain the information associated with invocations312(and provided back via returns of calls314), requested by event controller304. As an example, invocations312to API(s)306may cause API(s)306to issue calls314to the user space of OS212for determining a process identifier for event308based at least on the intercepting and event information310. Based at least on the process identifier determined, the instance of web browser application222that caused event308can be identified.

Continuing with flowchart400, in step406, a uniform resource locator (URL) corresponding to the event and to the instance of the web browser application is retrieved. For instance, based at least on the determined instance of web browser application222associated with event308from step404, the URL for the event and the instance, tab, and/or session of web browser application222can also be determined. In embodiments, the URL is determined from one or more of different methods/techniques. For instance, browser data224inFIG.2may be read, web browser application222may be queried, and/or origin metadata218inFIG.2may be read, e.g., via API(s)306, as described in further detail below.

Finally, with respect to flowchart400, in step408, a data loss prevention (DLP) action is performed against the event based at least on the URL and an identifier of the file. For example, event controller304is configured to perform a DLP action for event308. The DLP action taken may be based at least on the URL and file identifier (e.g., a file name, file type, etc.), and may also be based on content of the file. In embodiments, the URL, and file identifier and/or content of the file that is written to or read from, may be checked via policy server104, by utilizing a cached policy or a cached policy decision, to determine DLP actions to be taken for event308, including but without limitation, allowing event308to complete, blocking event308from completion, etc., as described in further detail below.

FIG.5will now be described.FIG.5shows a flowchart500for network aware endpoint DLP in web transactions, according to example embodiments. System100inFIG.1and/or system200inFIG.2, e.g., via file system filter208, operate according to flowchart500, which may be an embodiment of flow diagram300ofFIG.3and flowchart400ofFIG.4. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following descriptions.

As noted above with respect to file system filter208in flow diagram300and step404of flowchart400, determining that web browser application222causes event308includes determining a process identifier for event308and identifying web browser application222based on the process identifier. Flowchart500includes further details regarding these operations, and begins at step502.

In step502, to determine the process identifier, the process identifier is extracted from the event. For example, event controller304in flow diagram300may receive event information310of event308from event interceptor302, as described for step402in flowchart400. Event controller304is configured to extract the process identifier from event information310.

The remaining steps of flowchart500provide example operations for identifying the instance of the web browser application based at least on the process identifier, in an example embodiment.

In step504, the OS is queried for an executable path for the process identifier. For instance, event controller304in flow diagram300is configured to perform one of invocations312for an API of API(s)306with the extracted process identifier from step502. One of API calls314queries OS212with the extracted process identifier, e.g., in the user space where OS212tracks executing processes in process list216, and returns the executable path from process list216for the process based at least on the process identifier, along with a hash value and a browser certificate of the instance of web browser application222executing as the process.

In step506, the process, which has a hash value and a certificate associated therewith, is identified based at least on the executable path. For example, event controller304is configured to identify the process based at least on the executable path, and in embodiments, based also on the certificate and/or the hash value. As noted above, web browser application222has associated data and information persisted in memory206as browser certificates and hash values228. The hash value and browser certificate returned with the executable path may also be utilized by event controller304to identify the process. Once the process is identified, the hash value and browser certificate returned with the executable path can be used to verify if the process identified is an instance, tab, session, etc., of web browser application222.

In step508, the hash value and the certificate of the process are compared to information in a predefined data structure of web browser applications in a memory. For instance, browser certificates and hash values228in the user space of OS212can be queried through one of invocations312to API(s)306for one of API calls314with the hash value and the certificate of the process. The hash value and the certificate of the process from step506are compared to entries in the predefined data structure of web browser applications in memory206to determine if a match is present. A match positively verifies that the process identified is an instance, tab, session, etc., of web browser application222.

Accordingly, it is determined that the process executing at the computing device and causing event308to occur is an instance of web browser application222.

Embodiments herein for network aware endpoint DLP in web transactions also include the determination of an application, service, and/or the like at a remote device, e.g., remote device102inFIG.1, that is associated with event308. As described herein, an upload event corresponds to the reading of a file that will be transmitted via web browser application222from a client device (e.g., client device106, computing system202, etc.) to the remote device, while a download event corresponds to a write to a file that will be transmitted from the remote device to the client device via web browser application222. Because the techniques herein enable “network aware” endpoint DLP in web transactions, the URL for the application, service, and/or the like at a remote device is utilized for DLP considerations. The URL may be determined in various ways without departing from the overall DLP processes set forth in this description. In this context,FIG.6will now be described.

Turning now toFIG.6, a flowchart600for network aware endpoint DLP in web transactions is shown, according to an example embodiment. System100inFIG.1and/or system200inFIG.2, e.g., via file system filter208, operate according to flowchart600, which may be an embodiment of flow diagram300ofFIG.3and flowchart400ofFIG.4, e.g., step406of flowchart400as described in view of file system filter208and flow diagram300. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following descriptions.

Flowchart600includes a step602, a step604, and a step606, and one or more of these steps may be optionally performed to execute step406of flowchart400, according to embodiments. Flowchart600may follow from step404in flowchart400, described above.

In step602, a current session file of the web browser application is read and the URL is retrieved therefrom. For instance, referring also back again toFIGS.2and3, when the instance of web browser application222is determined, browser data224inFIG.2may be read via one of invocations312to an API of API(s)306from event controller304, and an associated call of calls314retrieves the URL from browser data224, as noted above for flow diagram300. In embodiments, this call of calls314includes identifying information for the instance of web browser application222such that the call is enabled to find the corresponding URL in browser data224.

In step604, the web browser application is queried for one or more open instances thereof via an application programming interface that is exposed to the OS. For example, web browser application222is queried via one of invocations312to an API of API(s)306from event controller304, and an associated call of calls314retrieves the URL from the corresponding instance, tab, session, etc., of web browser application222, as noted above for flow diagram300. In embodiments, this call of calls314includes identifying information for the instance of web browser application222such that the call is enabled to find the corresponding URL in the appropriate instance, tab, session, etc., of web browser application222.

In step606, the URL is read from an OS-level metadata file that includes origin information of download files. For instance, OS212may maintain and update metadata for file origins of download files in origin metadata218, including source origins of download files and associated URLs, for origin metadata218stored persistently in memory206. Origin metadata218inFIG.2may be read via one of invocations312to an API of API(s)306from event controller304, and an associated call of calls314retrieves the URL from origin metadata218, as noted above for flow diagram300. In embodiments, this call of calls314includes identifying information for the file such that the call is enabled to find the corresponding URL for the download file in origin metadata218.

On completion of one or more optional steps for flowchart600, the flow of flowchart400may proceed to step408.

It should be noted that while three optional steps are provided for flowchart600, this set of steps is not to be considered exclusive for the embodiments herein, and further that optional steps performed may be selected based specific operational scenarios based at least on factors, such as but not limited to, the event source, the web browser application type, version, etc., the operating system type, version, etc., and/or the like.

In various embodiments for network aware endpoint DLP in web transactions, a policy server may be utilized for determinations of DLP actions to be taken for given events. As described above forFIG.1, policy server104is configured to store policies and host a policy engine that evaluates events, as described herein, for compliance with the policies. Policies may be implemented via policy server104that prohibit events such as the upload or download of certain types of files, data, information, etc., that allow or block such events, that require encryption for such events, and/or the like, based at least on one or more factors, including but without limitation: an identity or type of service/application of remote device102associated with the event, the content of the files or content portions thereof, data, information, etc., an identity of the user of client device106, and/or the like. In this context,FIGS.7and8will be described below.

FIG.7shows a flow diagram700for network aware endpoint DLP in web transactions, according to an example embodiment. Flow diagram700is provided in the context of policy server104inFIG.1and file system filter208inFIG.2.FIG.8illustrates a flowchart800for network aware endpoint DLP in web transactions, according to an example embodiment. System100inFIG.1and/or system200inFIG.2, e.g., via file system filter208, operate according to flow diagram700and flowchart800(which may be an embodiment of flow diagram700ofFIG.7and of flowchart400ofFIG.4, e.g., step408of flowchart400).

Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following descriptions. Flow diagram700and flowchart800are described below.

Flow diagram700inFIG.7includes a buffer799, which is part of memory206of system200, in embodiments. Buffer799is configured to buffer data of files that are associated with events for downloads/writes to files, as described herein, without persistently storing the data/files. Buffer799may be any size, and in embodiments, may be configured with a size, e.g., 50 MB (although any other size for buffer799is contemplated as noted above), that enables an amount of the file to be buffered enabling policy decision determinations while still limiting the amount of the file being buffered for performance and/or resource utilization considerations. The size of buffer799is configurable in embodiments.

In flow diagram700, file system filter208provides the URL and the file identifier to policy server104that is configured to evaluate DLP policies for events, such as event308described for flow diagram300inFIG.3. The URL and the file identifier, described above for the preceding FIGS., may be provided as policy metadata702for policy server104to render policy decisions on events. The provision policy metadata702is performed by invoking an API of API(s)306and placing a corresponding API call, in embodiments, as similarly described for flow diagram300above.

In some scenarios, policy server104is able to determine a policy decision716based on the provided policy metadata702, and in such cases, policy decision716is provided to file system filter208to take a DLP action(s) based thereon, as described in further detail below. In other embodiments, policy server104may require additional information to make its policy decision. For example, a request704for additional event information is transmitted from policy server104to file system filter208. Request704may stipulate that data of the file associated with the event be provided to policy server104for evaluation of the policy(ies).

For upload events in which a file is read from the client system, request704is fulfilled by file system filter, e.g., via API(s)306as described herein, sending an instruction706to file system214. Instruction706specifies the file is to be provided to policy server104, and in file system214provides a communication708that includes the file to policy server104. In some embodiments, a portion of the file is provided to policy server104, and additional iterations of request704, instruction706, and communication708may be performed. Policy server104is thus enabled to determine policy decision716and provide it to file system filter208.

For download events in which a file is written to the client system, request704is fulfilled by file system filter, e.g., via API(s)306as described herein, sending an instruction710to web browser application222, which may generate an “open” system call, to initialize writing of the beginning of the file, which is observed by file system filter208. That is, instruction710specifies that a “write” operation for the file to be written be made to buffer799, and this operation begins with “open.” The specified write operation may be an operation that writes a relatively small amount of file data712at one time to buffer799. That is, many iterations of the write operation may be performed by reissuing instruction710until the size limit of buffer799is reached or until the entire file is buffered, e.g., when a “close” system call is detected by file system filter208.

A monitoring signal713or other equivalent indicia of buffer capacity may be used by file system filter208to determine how many such write operations are performed. In one embodiment, instead of monitoring signal713, file system filter208may track the number of write operations made by web browser application222and determine the amount of file data written to buffer799given a size of each write operation. In response to the entire file being written to buffer799, or to buffer799filling up, a communication714that includes at least a portion of the file is provided to policy server104from buffer799. Policy server104is thus enabled to determine policy decision716and provide it to file system filter208.

Turning now toFIG.8, Flowchart800includes a step802, a step804, a step806, and a step808, and one or more of these steps may be optionally performed to execute step408of flowchart400for taking a DLP action against the event, according to embodiments. Flowchart800may follow from step406in flowchart400, described above.

In step802, the event is allowed to complete. For instance, policy server102may return a policy decision that indicates event308is allowed to complete as the DLP action taken against event308. The hold on the read or write operation associated with event308is released by file system filter208, and the operation is performed.

In step804, the event is blocked from completion. For example, policy server102may return a policy decision that indicates event308is not allowed to complete and is blocked as the DLP action taken against event308. The hold on the read or write operation associated with event308is released by file system filter208, and the operation is discarded.

In step806, data of the file associated with the event is encrypted. For instance, policy server102may return a policy decision that allows event308to complete, as described for step802, but requires that data associated with the file be encrypted for the upload or download of the file. File data may be buffered and encrypted prior to the upload or download operation being completed, as would be understood by persons of skill in the relevant art(s) having the benefit of this disclosure. While not expressly described for the sake of brevity, any type of encryption method is contemplated herein, and may be performed via software and/or hardware (e.g., via trusted platform module (TPM) or other mechanism(s)).

In step808, a buffer that stores at least a portion of the file associated with the event is released, and the event is the write to the file. For example, as noted above, when policy server104requires additional information to make a policy decision, a request may be received for file data to be provided to policy server104. In these cases, e.g., for download/write events, the file data may be received from web browser application222and buffered by buffer799without persistently storing the file data. With additional reference to flow diagram700, when the policy decision to allow or block a download/write event for which file data was requested by policy server104, buffer799is released. Additionally, file data in buffer799may be encrypted via buffer799prior to being released.

III. Example Computing Device Embodiments

Embodiments described herein may be implemented in hardware, or hardware combined with software and/or firmware. For example, embodiments described herein may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium. Alternatively, embodiments described herein may be implemented as hardware logic/electrical circuitry.

As noted herein, the embodiments described, including but not limited to, system100inFIG.1and system200inFIG.2, along with any components and/or subcomponents thereof, as well any operations and portions of flowcharts/flow diagrams described herein and/or further examples described herein, may be implemented in hardware, or hardware with any combination of software and/or firmware, including being implemented as computer program code configured to be executed in one or more processors and stored in a computer readable storage medium, or being implemented as hardware logic/electrical circuitry, such as being implemented together in a system-on-chip (SoC), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a trusted platform module (TPM), and/or the like. A SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits and/or embedded firmware to perform its functions.

Embodiments described herein may be implemented in one or more computing devices similar to a mobile system and/or a computing device in stationary or mobile computer embodiments, including one or more features of mobile systems and/or computing devices described herein, as well as alternative features. The descriptions of computing devices provided herein are provided for purposes of illustration, and are not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

Embodiments described herein may be implemented in one or more computing devices similar to a mobile system and/or a computing device in stationary or mobile computer embodiments, including one or more features of mobile systems and/or computing devices described herein, as well as alternative features. The descriptions of computing devices provided herein are provided for purposes of illustration, and are not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

FIG.9is a block diagram of an exemplary mobile system900that includes a mobile device902that may implement embodiments described herein. For example, mobile device902may be used to implement any system, client, or device, or components/subcomponents thereof, in the preceding sections. As shown inFIG.9, mobile device902includes a variety of optional hardware and software components. Any component in mobile device902can communicate with any other component, although not all connections are shown for ease of illustration. Mobile device902can be any of a variety of computing devices (e.g., cell phone, smartphone, handheld computer, Personal Digital Assistant (PDA), etc.) and can allow wireless two-way communications with one or more mobile communications networks904, such as a cellular or satellite network, or with a local area or wide area network.

Mobile device902can include a controller or processor910(e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system912can control the allocation and usage of the components of mobile device902and provide support for one or more application programs914(also referred to as “applications” or “apps”). Application programs914may include common mobile computing applications (e.g., e-mail applications, calendars, contact managers, web browsers, messaging applications) and any other computing applications (e.g., word processing applications, mapping applications, media player applications).

Mobile device902can include memory920. Memory920can include non-removable memory922and/or removable memory924. Non-removable memory922can include RAM, ROM, flash memory, a hard disk, or other well-known memory devices or technologies. Removable memory924can include flash memory or a Subscriber Identity Module (SIM) card, which is well known in GSM communication systems, or other well-known memory devices or technologies, such as “smart cards.” Memory920can be used for storing data and/or code for running operating system912and application programs914. Example data can include web pages, text, images, sound files, video data, or other data to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. Memory920can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment.

A number of programs may be stored in memory920. These programs include operating system912, one or more application programs914, and other program modules and program data. Examples of such application programs or program modules may include, for example, computer program logic (e.g., computer program code or instructions) for implementing one or more of system100inFIG.1and system200inFIG.2, along with any components and/or subcomponents thereof, as well as the flowcharts/flow diagrams described herein, including portions thereof, and/or further examples described herein.

Mobile device902can include a mobile TPM992. Mobile TPM992may be a mobile device equivalent embodiment of a TPM, as would be understood by one of skill in the relevant art(s) having the benefit of this disclosure. For example, mobile TPM992may be configured to perform one or more functions or operations of TPMs for various embodiments herein.

Mobile device902can support one or more input devices930, such as a touch screen932, a microphone934, a camera936, a physical keyboard938and/or a trackball940and one or more output devices950, such as a speaker952and a display954. Other possible output devices (not shown) can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, touch screen932and display954can be combined in a single input/output device. Input devices930can include a Natural User Interface (NUI).

One or more wireless modems960can be coupled to antenna(s) (not shown) and can support two-way communications between processor910and external devices, as is well understood in the art. Modem960is shown generically and can include a cellular modem966for communicating with the mobile communication network904and/or other radio-based modems (e.g., Bluetooth964and/or Wi-Fi962). At least one wireless modem960is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the mobile device and a public switched telephone network (PSTN).

Mobile device902can further include at least one input/output port980, a power supply982, a satellite navigation system receiver984, such as a Global Positioning System (GPS) receiver, an accelerometer986, and/or a physical connector990, which can be a USB port, IEEE 1394 (FireWire) port, and/or RS-232 port. The illustrated components of mobile device902are not required or all-inclusive, as any components can be deleted and other components can be added as would be recognized by one skilled in the art.

In an embodiment, mobile device902is configured to implement any of the above-described features of flowcharts herein. Computer program logic for performing any of the operations, steps, and/or functions described herein may be stored in memory920and executed by processor910.

FIG.10depicts an exemplary implementation of a computing device1000in which embodiments may be implemented. For example, embodiments described herein may be implemented in one or more computing devices or systems similar to computing device1000, or multiple instances of computing device1000, in stationary or mobile computer embodiments, including one or more features of computing device1000and/or alternative features. The description of computing device1000provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems, servers, and/or clusters, etc., as would be known to persons skilled in the relevant art(s).

As shown inFIG.10, computing device1000includes one or more processors, referred to as processor circuit1002, a system memory1004, and a bus1006that couples various system components including system memory1004to processor circuit1002. Processor circuit1002is an electrical and/or optical circuit implemented in one or more physical hardware electrical circuit device elements and/or integrated circuit devices (semiconductor material chips or dies) as a central processing unit (CPU), a microcontroller, a microprocessor, and/or other physical hardware processor circuit. Processor circuit1002may execute program code stored in a computer readable medium, such as program code of operating system1030, application programs1032, other programs1034, etc. Bus1006represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. System memory1004includes read only memory (ROM)1008and random access memory (RAM)1010. A basic input/output system1012(BIOS) is stored in ROM1008.

Computing device1000also has one or more of the following drives: a hard disk drive1014for reading from and writing to a hard disk, a magnetic disk drive1016for reading from or writing to a removable magnetic disk1018, and an optical disk drive1020for reading from or writing to a removable optical disk1022such as a CD ROM, DVD ROM, or other optical media. Hard disk drive1014, magnetic disk drive1016, and optical disk drive1020are connected to bus1006by a hard disk drive interface1024, a magnetic disk drive interface1026, and an optical drive interface1028, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk and a removable optical disk are described, other types of hardware-based computer-readable storage media can be used to store data, such as flash memory cards, digital video disks, RAMs, ROMs, and other hardware storage media.

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system1030, one or more application programs1032, other programs1034, and program data1036. Application programs1032or other programs1034may include, for example, computer program logic (e.g., computer program code or instructions) for implementing embodiments described herein, such as but not limited to, s system100inFIG.1and system200inFIG.2, along with any components and/or subcomponents thereof, as well as the flowcharts/flow diagrams described herein, including portions thereof, and/or further examples described herein.

A user may enter commands and information into the computing device1000through input devices such as keyboard1038and pointing device1040. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, a touch screen and/or touch pad, a voice recognition system to receive voice input, a gesture recognition system to receive gesture input, or the like. These and other input devices are often connected to processor circuit1002through a serial port interface1042that is coupled to bus1006, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB).

A display screen1044is also connected to bus1006via an interface, such as a video adapter1046. Display screen1044may be external to, or incorporated in computing device1000. Display screen1044may display information, as well as being a user interface for receiving user commands and/or other information (e.g., by touch, finger gestures, virtual keyboard, etc.). In addition to display screen1044, computing device1000may include other peripheral output devices (not shown) such as speakers and printers.

Computing device1000is connected to a network1048(e.g., the Internet) through an adaptor or network interface1050, a modem1052, or other means for establishing communications over the network. Modem1052, which may be internal or external, may be connected to bus1006via serial port interface1042, as shown inFIG.10, or may be connected to bus1006using another interface type, including a parallel interface.

TPM1054may be connected to bus1006, and may be an embodiment of any TPM, as would be understood by one of skill in the relevant art(s) having the benefit of this disclosure. For example, TPM1054may be configured to perform one or more functions or operations of TPMs for various embodiments herein.

As noted above, computer programs and modules (including application programs1032and other programs1034) may be stored on the hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage medium. Such computer programs may also be received via network interface1050, serial port interface1042, or any other interface type. Such computer programs, when executed or loaded by an application, enable computing device1000to implement features of embodiments discussed herein. Accordingly, such computer programs represent controllers of the computing device1000.

Embodiments are also directed to computer program products comprising computer code or instructions stored on any computer-readable medium or computer-readable storage medium. Such computer program products include hard disk drives, optical disk drives, memory device packages, portable memory sticks, memory cards, and other types of physical storage hardware.

IV. Additional Examples and Advantages

As described, systems and devices embodying the techniques herein may be configured and enabled in various ways to perform their respective functions for network aware endpoint data loss prevention (DLP) in web transactions. In embodiments, one or more of the steps or operations of any flowchart and/or flow diagram described herein may not be performed. Moreover, steps or operations in addition to or in lieu of those in any flowchart and/or flow diagram described herein may be performed. Further, in examples, one or more operations of any flowchart and/or flow diagram described herein may be performed out of order, in an alternate sequence, or partially (or completely) concurrently with each other or with other operations.

As described herein, systems, devices, components, etc., of the embodiments that are configured to perform functions and/or operations are also contemplated as performing such functions and/or operations.

According to the described embodiments for network aware endpoint DLP in web transactions, an endpoint DLP solution is enabled to be network aware, providing knowledge for a local client to associate network activities for uploads and downloads while also having knowledge client-side activities. Additionally, the described embodiments provide both network- and client-side knowledge, without the injection of code that was previously required to handle the recent variations in web transmission formats, thus reducing computational and bandwidth overhead. The embodiments herein utilize a unique implementation and methodology for network aware endpoint DLP in web transactions at the OS level of the client device that were previously not available for software-based DLP solutions, much less for the specific embodiments described herein performed by a file system filter at the OS level. The described embodiments are also adaptable to different types of web browser applications and OS types.

In some alternative embodiments, libraries may be injected into running processes (e.g., applications) to force the processes to run functions and operations associated with the embodiments described herein.

The additional examples and embodiments described in this Section may be applicable to examples disclosed in any other Section or subsection of this disclosure.

Embodiments in this description provide for systems, devices, and methods for network aware endpoint DLP in web transactions. For instance, a method performed by a file system filter in an operating system (OS) of a computing device is described herein for such embodiments. The method includes intercepting an event in the OS, the event being a read of or a write to a file, determining that a process executing at the computing device and causing the event to occur is an instance of a web browser application, retrieving a uniform resource locator (URL) corresponding to the event and to the instance of the web browser application, and performing a data loss prevention (DLP) action against the event based at least on the URL and an identifier of the file.

In an embodiment of the method, the determining that the process executing at the computing device and causing the event to occur is the instance of the web browser application includes: determining a process identifier for the event based at least on said intercepting and event information; and identifying the instance of the web browser application based at least on the process identifier.

In the embodiment of the method, the determining the process identifier includes extracting the process identifier from the event, and the identifying the instance of the web browser application includes: querying the OS for an executable path for the process identifier, identifying the process, based at least on the executable path, which has a hash value and a certificate associated therewith, and comparing the hash value and the certificate of the process to information in a predefined data structure of web browser applications in a memory.

In an embodiment of the method, the retrieving the URL includes at least one of: reading a current session file of the web browser application and retrieving the URL therefrom, querying the web browser application for one or more open instances thereof via an application programming interface that is exposed to the OS, or reading the URL from an OS-level metadata file that includes origin information of download files.

In an embodiment, the method, prior to performing the DLP action, includes providing the URL and the file identifier to a policy server that is configured to evaluate DLP policies for events, and in response to said providing the URL and the file identifier, receiving an indication of the DLP action to be performed from the policy.

In the embodiment, the method, prior to receiving the indication of the DLP action to be performed, includes: receiving a request for additional information from the policy server, and providing at least a portion of the file associated with the event to the policy server.

In the embodiment of the method, the event is the write to the file, and providing the at least a portion of the file includes: enabling the instance of the web browser application to initiate a download of the file, and buffering the at least a portion of the file during the download for provision to the policy server, while preventing the at least a portion of the file from being saved to a persistent storage at the computing device.

In an embodiment of the method, the DLP action includes at least one of: allowing the event to complete, blocking the event from completion, encrypting data of the file associated with the event, or releasing a buffer that stores at least a portion of the file associated with the event, the event being the write to the file.

A computing system is also described herein. In an embodiment, the system includes at least one memory that stores program code, and a processing system, comprising one or more processors, configured to receive the program code from the at least one memory and, in response to at least receiving the program code, to perform operations. The operations include to intercept an event in the OS, the event being a read of or a write to a file, determine that a process executing at the computing device and causing the event to occur is an instance of a web browser application, retrieve a uniform resource locator (URL) corresponding to the event and to the instance of the web browser application, and perform a data loss prevention (DLP) action against the event based at least on the URL and an identifier of the file.

In an embodiment of the computing system, to determine that the process executing at the computing device and causing the event to occur is the instance of the web browser application includes to: determine a process identifier for the event based at least on said intercepting and event information, and identify the instance of the web browser application based at least on the process identifier.

In the embodiment, to determine the process identifier includes to extract the process identifier from the event, and to identify the instance of the web browser application includes to: query the OS for an executable path for the process identifier, identify the process, based at least on the executable path, which has a hash value and a certificate associated therewith, and compare the hash value and the certificate of the process to information in a predefined data structure of web browser applications in a memory of the computing system.

In an embodiment of the computing system, to retrieve the URL includes at least one of to: read a current session file of the web browser application and retrieving the URL therefrom, query the web browser application for one or more open instances thereof via an application programming interface that is exposed to the OS, or read the URL from an OS-level metadata file that includes origin information of download files.

In an embodiment of the computing system, the processing system is configured, in response to at least receiving the program code, and prior to said perform the DLP action, to: provide the URL and the file identifier to a policy server that is configured to evaluate DLP policies for events, and in response to said provide the URL and the file identifier, receive an indication of the DLP action to be performed from the policy.

In the embodiment, the processing system is configured, in response to at least receiving the program code, and prior to said receive the indication of the DLP action to be performed, to: receive a request for additional information from the policy server, and provide at least a portion of the file associated with the event to the policy server.

In the embodiment, the event is the write to the file, and to provide the at least a portion of the file includes to: enable the instance of the web browser application to initiate a download of the file, and buffer the at least a portion of the file during the download for provision to the policy server, while preventing the at least a portion of the file from being saved to a persistent storage at the computing device.

In an embodiment of the computing system, the DLP action includes at least one of to: allow the event to complete, block the event from completion, encrypt data of the file associated with the event, or release a buffer that stores at least a portion of the file associated with the event, the event being the write to the file.

A computer-readable storage medium having program instructions recorded thereon that, when executed by a processing system, perform a method by a file system filter in an operating system (OS), is also described. The method includes intercepting an event in the OS, the event being a read of or a write to a file, determining that a process executing at the computing device and causing the event to occur is an instance of a web browser application, retrieving a uniform resource locator (URL) corresponding to the event and to the instance of the web browser application, and performing a data loss prevention (DLP) action against the event based at least on the URL and an identifier of the file.

In an embodiment of the computer-readable storage medium, determining that the process executing at the computing device and causing the event to occur is the instance of the web browser application includes: determining a process identifier for the event based at least on said intercepting and event information, and identifying the instance of the web browser application based at least on the process identifier.

In an embodiment of the computer-readable storage medium, retrieving the URL includes at least one of: reading a current session file of the web browser application and retrieving the URL therefrom, querying the web browser application for one or more open instances thereof via an application programming interface that is exposed to the OS, or reading the URL from an OS-level metadata file that includes origin information of download files.

In an embodiment of the computer-readable storage medium, the event is the write to the file, and the method further includes, prior to performing the DLP action: providing the URL and the file identifier to a policy server that is configured to evaluate DLP policies for events; receiving a request for additional information from the policy server; providing at least a portion of the file associated with the event to the policy server, including: enabling the instance of the web browser application to initiate a download of the file, and buffering the at least a portion of the file during the download for provision to the policy server, while preventing the at least a portion of the file from being saved to a persistent storage at the computing device; and in response to said providing the URL and the file identifier, receiving an indication of the DLP action to be performed from the policy.