Protecting encrypted files transmitted over a network

Abstract

An improved system and approaches for protecting secured files when being used by an application (e.g., network browser) that potentially transmits the files over a network to unknown external locations are disclosed. According to one aspect, access to secured files is restricted so that unsecured versions of the secured files are not able to be transmitted over a network (e.g., the Internet) to unauthorized destinations. In one embodiment, processes operating on a computer system are monitored to determine destination locations, if any, of said processes, and then using such destination locations to determine whether to permit the processes to open files in a secure or unsecured manner.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to security systems for data and, more particularly, to security systems that protect data in an inter/intra enterprise environment.

2. Description of Related Art

The Internet is the fastest growing telecommunications medium in history. This growth and the easy access it affords have significantly enhanced the opportunity to use advanced information technology for both the public and private sectors. It provides unprecedented opportunities for interaction and data sharing among businesses and individuals. However, the advantages provided by the Internet come with a significantly greater element of risk to the confidentiality and integrity of information. The Internet is an open, public and international network of interconnected computers and electronic devices. Without proper security measures, an unauthorized person or machine may intercept any information traveling across the Internet, and may even get access to proprietary information stored in computers that interconnect to the Internet but are otherwise generally inaccessible by the public.

There are many efforts in progress aimed at protecting proprietary information traveling across the Internet and controlling access to computers carrying the proprietary information. Cryptography allows people to carry over the confidence found in the physical world to the electronic world, thus allowing people to do business electronically without worries of deceit and deception. Every day hundreds of thousands of people interact electronically, whether it is through e-mail, e-commerce (business conducted over the Internet), ATM machines or cellular phones. The perpetual increase of information transmitted electronically has lead to an increased reliance on cryptography.

One of the ongoing efforts in protecting the proprietary information traveling across the Internet is to use one or more cryptographic techniques to secure a private communication session between two communicating computers on the Internet. Cryptographic techniques provide a way to transmit information across an unsecure communication channel without disclosing the contents of the information to anyone eavesdropping on the communication channel. An encryption process is a cryptographic technique whereby one party can protect the contents of data in transit from access by an unauthorized third party, yet the intended party can read the data using a corresponding decryption process.

Conventionally, network browsers (e.g., Internet or Windows browsers) are utilized to access content remotely located on the World Wide Web. In other words, with a network browser, a user can request a resource that is remotely located on a remote server coupled to the Internet. Alternatively, a network browser can be used to transmit a file to a remote server coupled to the Internet. Hence, network browsers are effective at allowing communications between network browsers and remote servers. Although network browsers greatly facilitate access to data, when network browsers are used on computing systems that utilize file security systems, network browsers present a security problem. More specifically, a network browser presents a security risk because it can transmit any of the files it accesses to a remote server (remote site). Hence, the security provided on secured files can be lost if unsecured versions of secured files are made available to network browsers. However, when the network browser merely desires access to the files for display or other non-transmission purposes, then the network browser does not present a security risk. Accordingly, if the network browser does intend to transmit a file to an unsecured remote server, then the security for the file as provided by the file security system is compromised.

Thus, there is an need for improved techniques to enable file security systems to permit the use of network browsers yet preserve the security on secured files.

SUMMARY OF THE INVENTION

The invention relates to improved approaches for protecting secured files when being used by an application (e.g., network browser) that is capable of transmitting the files over a network to unknown external locations.

One aspect of the invention pertains to restricting access to secured files so that unsecured versions of the secured files are not able to be transmitted over a network (e.g., the Internet) to unauthorized destinations. In one embodiment, in opening a file for use by a network browser, the network browser receives a secured (e.g., encrypted) version of the secured file when the destination location (e.g., destination address) for the network browser is not trusted, but receives an unsecured (e.g., unencrypted) version of the secured file when the destination location for the network browser is trusted. Another aspect of the invention pertains to monitoring processes operating on a computer system to determine destination locations, if any, of said processes, and then using such destination locations to determine whether to permit the processes to open files in a secure or unsecured manner.

The invention can be implemented in numerous ways, including as a method, system, device, and computer readable medium. Several embodiments of the invention are discussed below.

As a method for limiting access to a file stored in and secured by a file security system, one embodiment of the invention includes at least the acts of: receiving a request for access to a secured file, the request being initiated by a requester and being associated with a process associated with a computer system; determining whether the process is trusted by the file security system; determining whether the requestor is permitted to access an unsecured version of the secured file; and unsecuring the secured file to produce an unsecured file, thereby permitting access to the unsecured file only when the process is determined to be trusted and the requestor is determined to be permitted to access an unsecured version of the unsecured file.

As a method for limiting access to a file secured by a file security system, another embodiment of the invention includes at least the acts of: receiving a file open request to open a secured file, the request being initiated by a requester and being associated with a process associated with a computer system; determining whether the process is trusted by the file security system; determining whether the requestor has sufficient access privileges to open an unsecured version of the secured file; permitting the secured file to be opened for limited use by the requestor when the process is determined not to be trusted; and permitting the unsecured version of the secured file to be opened for use by the requestor when the process is trusted and the requestor has sufficient access privileges.

As a method for identifying a destination address being accessed by a window for a process operating on a computer system, one embodiment of the invention includes at least the acts of: determining a foreground window for the process, and examining a resource within the foreground window to determine a destination address that is being or is to be accessed by the process.

As a computer readable medium including at least computer program code for limiting access to a file secured by a file security system, one embodiment of the invention includes at least: computer program code for receiving a request for access to a secured file, the request being initiated by a requestor and being associated with a process associated with a computer system; computer program code for determining whether the process is trusted by the file security system; computer program code for determining whether the requestor is permitted to access an unsecured version of the secured file; and computer program code for unsecuring the secured file to produce an unsecured file, thereby permitting access to the unsecured file only when the process is determined to be trusted and the requestor is determined to be permitted to access an unsecured version of the unsecured file.

As a computer system providing file security, one embodiment of the invention includes at least an access control system that limits access to stored files based on at least access rules and trusted criteria, a process operating on the computer system, and a destination monitor that monitors an external destination of the process. The access control system permits access to the stored, secured files only when the access rules are satisfied and the process as well as the external destination satisfy the trusted criteria.

Other objects, features, and advantages of the present invention will become apparent upon examining the following detailed description of an embodiment thereof, taken in conjunction with the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:

FIG. 1 is a block diagram of a file security system according to one embodiment of the invention.

FIG. 2 is a flow diagram of file access processing according to one embodiment of the invention.

FIG. 3 is a flow diagram of file open processing according to one embodiment of the invention.

FIG. 4 is a flow diagram of trusted evaluation processing according to one embodiment of the invention.

FIG. 5 shows a basic security system in which the invention may be practiced in accordance with one embodiment thereof.

FIG. 6 shows an exemplary data structure of a secured file that may be used in one embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to improved approaches for protecting secured files when being used by an application (e.g., network browser) that is capable of transmitting the files over a network to unknown external locations.

One aspect of the invention pertains to restricting access to secured files so that unsecured versions of the secured files are not able to be transmitted over a network (e.g., the Internet) to unauthorized destinations. In one embodiment, in opening a file for use by a network browser, the network browser receives a secured (e.g., encrypted) version of the secured file when the destination location (e.g., destination address) for the network browser is not trusted, but receives an unsecured (e.g., unencrypted) version of the secured file when the destination location for the network browser is trusted.

Another aspect of the invention pertains to monitoring processes operating on a computer system to determine destination locations, if any, of said processes, and then using such destination locations to determine whether to permit the processes to open files in a secure or unsecured manner.

Using the invention, a file security system can enforce the policy that a network browser never sends unsecured versions of secured files (e.g., decrypted files) to web-based email sites which are external destination locations that are unapproved (e.g., untrusted). On the other hand, the file security system is still able to send unsecured versions of the secured files to approved document management sites.

Secured files are files that require one or more keys, passwords, access privileges, etc. to gain access to their content. The security is often provided through encryption and access rules. The files, for example, can pertain to documents, multimedia files, data, executable code, images and text. In general, a secured file can only be accessed by authenticated users with appropriate access rights or privileges as compared to the access rules for the secured file. In one embodiment, each secured file is provided with a header portion and a data portion, where the header portion contains, or points to, security information. The security information is used to determine whether access to associated data portions of secured files is permitted.

As used herein, a user may mean a person, a software agent, a group of users, a member of the group, a device and/or application. Besides a person who needs to access a secured document, a software application or agent sometimes needs to access secured files in order to proceed. Accordingly, unless specifically stated, the “user” as used herein does not necessarily pertain to a human being.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will become obvious to those skilled in the art that the present invention may be practiced without these specific details. The description and representation herein may rely on the common meanings used by those experienced or skilled in the art to most effectively convey the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, components, and circuitry have not been described in detail to avoid unnecessarily obscuring aspects of the present invention.

Reference herein to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Further, the order of blocks in process flowcharts or diagrams representing one or more embodiments of the invention do not inherently indicate any particular order nor imply any limitations in the invention.

Embodiments of the present invention are discussed herein with reference to FIGS. 1-6. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments.

FIG. 1 is a block diagram of a file security system 100 according to one embodiment of the invention. The file security system 100 includes an access control system 102 that controls access to files maintained by the file security system 100. The access control system 102 couples to a local file storage 104. The access control system 102 also couples to a remote file storage 106 over a network 108. The network 108 can be a local area network, a wide area network or the Internet, or some combination thereof. Typically, the files are maintained in an encrypted format and the access control system 102 operates to permit access to unencrypted versions of the files only to requestors that have been properly authenticated and have sufficient access privileges.

The file security system 100 can operate on a computing system. The computing system is typically a client machine, though it could also be coupled to and use resources of a server machine. An operating system of the computing device hosting at least a portion of the file security system 100 includes the access control system 102 and the local file storage 104 or an interface thereto in an operating system layer. The computing device also operates to execute one or more applications in an application layer. These applications execute one or more processes. As shown in FIG. 1, as a representative example, a browser process 110 and a non-browser process 112 are active within the application layer. The browser process 110 is produced by a network browser application, and the non-browser process 112 is produced by an application other than a network browser application. The browser process 110 produces a browser window A 114 and a browser window B 116. Typically, these browser windows 114 and 116 are displayed on a display device associated with the computing device. The browser window A 114 is deemed a foreground window as it is on top of and, in this case, overlaps a portion of the browser window 116. The non-browser process 112 produces a window A 118 and a window B 120. The window A 118 is deemed a foreground window as it is on top of and, in this example, overlaps a portion of the window B 120.

The browser process 110 and the non-browser process 112 can access secured files via the operating system. These secured files can be stored locally in the local file storage 104 or stored remotely in the remote file storage 106. As such, the access control system 102 needs to limit access to the secured files such that a process operating in the application layer is not able to transmit unsecured versions of the secured files to unauthorized external locations.

The file security system 100 includes an address identifier monitor 122. In general, an address identifier identifies a destination address and may, for example, be a Universal Resource Identifier (URI) or Universal Resource Locator (URL). To facilitate the description of the invention, the address identifier monitor 122 is also referred to herein as a URL monitor 122. The URL monitor 122 monitors each of the processes resident in the application layer, namely, in this example, the processes 110 and 112. The URL monitor 122 determines, for each process, a destination URL (i.e., an external destination) for the foreground window. For example, the URL monitor 122 would determine a destination URL for the browser window A 114 and would determine a destination URL for the window A 118. However, since the window A 118 is produced by the non-browser process 112, the URL monitoring performed by the URL monitor 122 would normally not identify a URL associated with the window A 118 because it is not associated with a network browser and thus would not be accessing a destination URL.

The access control system 102 can then determine whether or not to permit access to secured files by the processes operating on the application layer. For example, if the browser process 110 were to seek access to a secured file, the access control system 102 would determine not only whether the browser process 110 is permitted to gain access but also whether the URL associated with the browser window A 114 is a permissible destination. In one embodiment, the access control system 102 determines whether the browser process and its URL are both trusted. In one implementation, the access control system 102 can maintain a list or table of trusted processes and/or URLs. Then, the access control system 102 can compare the browser process 110 and the URL associated with the browser window A 114, as determined by the URL monitor 122, to determine whether the browser process 110 is trusted at this time for access to the secured files. Thus, access control to secured files being requested by a process can be dependent on the URL (i.e., destination URL) associated with the process.

Accordingly, a network browser is able to send files to many different external sites. The file security system 100 operates to enforce whether or not these external sites are given an encrypted version of the file or a decrypted version of the file. The file security system 100 has the ability to detect whether the requestor is sending the file requested to a network browser, and if so, limiting the extent to which decrypted versions of the files are made available to the network browser.

As previously noted, the URL monitor 122 monitors each of the processes resident in the application layer to determine a destination URL, if any, for each process. Such monitoring can be performed in an active or passive manner. In the case of active monitoring, the URL monitor can periodically locate windows provided by an operating system and search through such windows for certain heuristics or attributes that would specify a URL associated with the window. For example, in the case of a network browser window (e.g., Internet Explorer), an address bar would typically appear towards the top portion of the content being displayed in the window.

In the case of passive monitoring, in one embodiment, a browser helper object (BHO) can be registered with the browser application, such as Internet Explorer from Microsoft Corporation. The browser helper object would then notify the URL monitor 122 each time the browser application goes to a new URL.

According to one embodiment, the access control system 102 can associate a given network browser process identifier (ID) with the URL that is currently being browsed by the process by determining which window is currently in the foreground, and if it is a browser window, which URL is being displayed. Such determination of the URL being browsed can be done with Application Programming Interfaces (APIs) provided in an operating system (e.g., Microsoft Windows XP) or through an active monitoring and evaluation technique.

FIG. 2 is a flow diagram of file access processing 200 according to one embodiment of the invention. The file access processing 200 is, for example, performed by a file security system, such as the access control system 102 illustrated in FIG. 1.

The file access processing 200 monitors 202 URL access by processes. The URL specifies a network address for an external server. For example, if a process associated with a network browser is browsing a URL, the monitoring operates to identify the URL. Next, a decision 204 determines whether a file access request has been received. When the decision 204 determines that a file access request has not been received, the file access processing 200 awaits such a request and may continue to monitor URL access by the processes such that the monitoring remains current.

When the decision 204 determines that a file access request has been received, a decision 206 determines whether the requesting process and its URL (obtained via monitoring) are authorized to access the requested file. When the decision 206 determines that the requesting process and its URL are authorized, then a decision 208 determines whether the requested file can be accessed given the access privileges of the requestor. According to one embodiment, the secured file is in a form including embedded access rules that control restrictive access to the secured file. Accordingly, in such an embodiment, the access rules are evaluated against the access privileges of the user. When the decision 208 determines that access rules have been satisfied, then access to an unsecured version of the secured file is permitted 210.

On the other hand, when the decision 206 determines that the requesting process and its URL are not authorized, or when the decision 208 determines that the access rules are not satisfied, then access to an unsecured version of the secured file is denied 212. Following the operations 210 and 212, the file access processing 200 is complete and ends.

FIG. 3 is a flow diagram of file open processing 300 according to one embodiment of the invention. The file open processing 300 is, for example, performed by a file security system, such as the access control system 102 illustrated in FIG. 1.

The file open processing 300 begins with a decision 302 that determines whether a file open request has been received. The file open request is provided or initiated by a requestor. The requester can be a user. When the decision 302 determines that a file open request has not yet been received, the file open processing 300 awaits such a request.

Once the decision 302 determines that a file open request has been received, then a decision 304 determines whether the file is secured. Typically, the file is secured through access rules as well as encryption of some or all of the file. When the file to be accessed is not secured, then the file open is permitted 306 and the file open processing 300 is completed. In this case, the file open is permitted without restriction because the file to be opened is not secured.

On the other hand, when the decision 304 determines that the file to be accessed is secured, then a decision 308 determines whether the process requesting the file is trusted. A process can be deemed trusted if the process itself is deemed trusted and/or if an external destination (e.g., URL) of the process is trusted. When the decision 308 determines that the process requesting the file is not trusted, then the file open is permitted 310 but only with secured data. In other words, the file open is processed but the file is the secured file and thus the data remains secured (e.g., encrypted). After the file open has been permitted 310 with the secured data, the file open processing 300 is complete and ends.

Alternatively, when the decision 308 determines that the process requesting the file is trusted, then a decision 312 determines whether the requestor is permitted access to an unsecured version of the file. When the requester is permitted access to an unsecured version of the file, such as by satisfying access rules, an unsecured version of the file is produced 314. For example, when the file has been previously secured through encryption, the unsecured version of the file can be obtained by decryption of the file. Then, the file open is permitted 316 with the requestor receiving the unsecured version of the file. Following the operation 316, the file open processing 300 is complete and ends. On the other hand, when the decision 312 determines that the requestor is not permitted to access an unsecured version of the file, the file open is denied 318 and the file open processing 300 is complete and ends.

In the above embodiment, a file open request is either denied, permitted with secured data, or permitted with unsecured data. However, to receive the unsecured data, the process requesting the file must be trusted and the requestor must satisfy the access rules. Consequently, processes that are not trusted are not able to open files to gain access to unsecured data in the files.

In general, trusted evaluation processing determines whether a process requesting a secured file is trusted. The trusted evaluation processing can maintain a list of process identifiers (IDs) with current URLs. When one of these processes attempts to open a secured file (e.g., an encrypted file), the trusted evaluation processing makes a decision whether or not the process and/or its current URL are trusted. Based on the trust determination, the secured file is made available to the process in its secured form if untrusted and in its unsecured form if trusted.

FIG. 4 is a flow diagram of trusted evaluation processing 400 according to one embodiment of the invention. The trusted evaluation processing 400 is, for example, processing that can be utilized to determine whether the process requesting the file is trusted. For example, the trusted evaluation processing 400 can represent one embodiment of processing associated with the decision 308 illustrated in FIG. 3.

The trusted evaluation processing 400 initially obtains 402 a process identifier for the process that is requesting access to a secured file. Then, using the process identifier, a process name and a current URL can be identified 404 for the process. In one embodiment, the process identifier is used to retrieve the associated process names and the current URL associated with the process, where the current URL was previously obtained by monitoring the process. A list of trusted processes and/or URLs can also be retrieved 406. The list of trusted processes and/or URLs can be predetermined, or determined in advance, of the operation 406. In one embodiment, a system administrator could have previously identified those processes and/or URLs that are considered to be trusted. For example, a system administrator can configure a list of trusted processes and URLs that are to be deemed trusted.

A decision 408 then determines whether the process name is trusted. Here, the process name of the process requesting access to the secured file can be checked against the trusted processes within the list of trusted processes and/or URLs. When the decision 408 determines that the process name is trusted, then a decision 410 can determine whether the URL is trusted. In performing the decision 410, the current URL associated with the process can be compared to the URLs within the list of trusted processes and/or URLs. When the decision 410 determines that the URL is trusted, then the process is deemed 412 trusted for the URL. Alternatively, when the decision 408 determines that the process name is not trusted or when the decision 410 determines that the URL is not trusted, then the process is deemed 414 untrusted for the URL. Following the operations 412 and 414, the trusted evaluation processing 400 is complete and ends.

Note that, in this embodiment, a process is trusted if its process name can be trusted and if specific URLs can be trusted. Hence, with respect to a particular access request, a process may or may not be deemed trusted depending upon the URL associated with the process. In other words, in order to be trusted, both the process and the specific URLs must be trusted.

Further, the list of trusted processes and/or URLs can be organized or arranged in a variety of different ways such that those processes and/or URLs to be trusted are designated in a positive or negative sense. For example, the list of trusted processes and/or URLs can contain those processes that are trusted or those processes that are untrusted. Likewise, the list can include those specific URLs that are untrusted or those specific URLs that are trusted.

In one embodiment, the processes being determined to be trusted or untrusted are network browsers. Note that the trusted evaluation processing 400 assumes (for security sake) that a network browser (or other process) is opening a file with the intent to transmit it to the site at the given URL; however, opening a file by a network browser does not necessitate its transmission to a remote site.

FIG. 5 shows a basic security system 500 in which the invention may be practiced in accordance with one embodiment thereof. The security system 500 may be employed in an enterprise or inter-enterprise environment. It includes a first server 502 (also referred to as a central server) providing centralized access management for the enterprise thus files secured in the security system 500 can be controlled for restrictive access. To provide the dependability, reliability and scalability of the system, one or more second servers 504 (also referred to as local servers of which one is shown) may be employed to provide backup or distributed access management for users or client machines serviced locally. For illustration purposes, there are two client machines 501 and 502 being serviced by a local server 504. Alternatively, one of the client machines 501 and 502 may be considered as a networked storage device.

Secured files may be stored in either one of the devices 501, 502, 504 and 506. It is assumed that the client machine 501 corresponds to a file security system 100 of FIG. 1. When a user of the client machine 501 attempts to send a secured file to a remote destination 512, one or more of the processing 200, 300 and 400 discussed above are activated to ensure that the requested secured file is delivered without compromising the security imposed on the secured file.

FIG. 6 shows an exemplary data structure 620 of a secured file that may be used in one embodiment of the invention. The data structure 620 includes two portions: a header (or header portion) 622 and encrypted data (or an encrypted data portion) 624. The header 622 can be generated in accordance with a security template associated with the store and thus provides restrictive access to the data portion 624 that is an encrypted version of a plain file. Optionally, the data structure 620 may also include an error-checking portion 625 that stores one or more error-checking codes, for example, a separate error-checking code for each block of encrypted data portion 624. These error-checking codes may also be associated with a Cyclical Redundancy Check (CRC) for the header 622 and/or the encrypted data portion 624. The header 622 includes a flag bit or signature 627 and security information 626 that is in accordance with the security template for the store. According to one embodiment, the security information 626 is encrypted and can be decrypted with a user key associated with an authenticated user (or requester).

The security information 626 can vary depending upon implementation. However, as shown in FIG. 6, the security information 626 includes a user identifier (ID) 628, access policy (access rules) 629, a file key 630 and other 631. Although multiple user identifiers may be used, a user identifier 628 is used to identify a user or a group that is permitted to access the data structure 620. The access rules 629 provide restrictive access to the encrypted data portion 624. The file key 630 is a cipher key that, once obtained, can be used to decrypt the encrypted data portion 624 and thus, in general, is protected. In one implementation of the structure 620, the file key 630 is encrypted in conjunction with the access rules 629. In another implementation of the structure 620, the file key 630 is double encrypted with a protection key and further protected by the access rules 629. The other 631 is an additional space for other information to be stored within the security information 626. For example, the other information 631 may be used to include other information facilitating secure access to the secured file, such as version number or author identifier.

The invention is preferably implemented by software or a combination of hardware and software, but can also be implemented in hardware. The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, and optical data storage devices. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

The various embodiments, implementations and features of the invention noted above can be combined in various ways or used separately. Those skilled in the art will understand from the description that the invention can be equally applied to or used in other various different settings with respect to various combinations, embodiments, implementations or features provided in the description herein.

The advantages of the invention are numerous. Different embodiments or implementations may yield one or more of the following advantages. One advantage of the invention is that file security systems are able to protect secured files (e.g., documents) even when network browsers seek access to secured files. Another advantage of the invention is that a file security system can enforce the policy that a network browser never sends unsecured versions of secured files (e.g., decrypted files) to unapproved sites. For example, the policy could prevent a network browser from sending unsecured versions of secured files to web-based email sites which are external destination locations that are unapproved (e.g., untrusted), yet the file security system would still be able to send unsecured versions of the secured files to approved sites that are permitted to access the secured files. The approved sites may, for example, be used by those temporary consultants or tele-commuters for an enterprise.

The foregoing description of embodiments is illustrative of various aspects/embodiments of the present invention. Various modifications to the present invention can be made to the preferred embodiments by those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims. Accordingly, the scope of the present invention is defined by the appended claims rather than the foregoing description of embodiments.

Claims

1. A method for identifying a destination address configured to be accessed by a window for a process operating on a computer system, the method comprising: determining, by the computer system, a foreground window for the process, wherein the process is associated with the computer system;examining, by the computer system, a resource within the foreground window to determine a destination address that is configured to be accessed by the process, wherein the destination address is external with respect to the computer system; anddetermining, by the computer system, whether the process is a pre-approved process based at least on the destination address and a process identifier of the process, in order to ascertain permissions for transmission of unsecured files for the process.

2. The method as recited in claim 1, wherein the process is associated with a network browser operating on the computer system.

3. The method as recited in claim 1, wherein the examining comprises: determining whether the process is associated with a network browser operating on the computer system; andexamining the resource being displayed in the foreground window of the network browser to determine the destination address.

4. The method as recited in claim 1, wherein the destination address is separately determined for each of a plurality of separate processes operating on the computer system.

5. The method as recited in claim 1, wherein the resource comprises at least one of content or characteristics within the foreground window.

6. The method as recited in claim 1, further comprising informing a file security system with respect to the destination address being accessed by the process such that the file security system can restrict files accessible to the computer system from being transmitted to destinations that are not pre-approved via the process in response to the informing.

7. The method as recited in claim 6, wherein the process is associated with a network browser operating on the computer system.

8. The method as recited in claim 7, wherein the examining comprises: determining whether the process is associated with a network browser operating on the computer system; andexamining the resource being displayed in the foreground window of the network browser to determine the destination address.

9. The method as recited in claim 8, wherein the destination address is separately determined for each of a plurality of separate processes operating on the computer system.

10. A computer-readable medium having stored thereon, computer program code that, if executed by a device, causes the device to identify a destination address configured to be accessed by a window for a process operating on a computer system by a method, the method comprising: determining a foreground window for the process, wherein the process is associated with the computer system;examining a resource within the foreground window to determine a destination address that is configured to be accessed by the process, wherein the destination address is external with respect to the computer system; anddetermining, by the computer system, whether the process is a pre-approved process based at least on the destination address and a process identifier of the process, in order to ascertain permissions for transmission of unsecured files for the process.

11. The computer-readable medium as recited in claim 10, wherein the examining comprises: determining whether the process is associated with a network browser operating on the computer system; andexamining the resource being displayed in the foreground window of the network browser to determine the destination address.

12. The computer-readable medium as recited in claim 10, wherein the destination address is separately determined for each of a plurality of separate processes operating on the computer system.

13. The computer-readable medium as recited in claim 10, further comprising informing a file security system with respect to the destination address being accessed by the process such that the file security system can restrict files accessible to the computer system from being transmitted to destinations that are not pre-approved via the process in response to the informing.

14. The computer-readable medium as recited in claim 13, wherein the process is associated with a network browser operating on the computer system.

15. The computer-readable medium as recited in claim 14, wherein the examining comprises: determining whether the process is associated with a network browser operating on the computer system; andexamining the resource being displayed in the foreground window of the network browser to determine the destination address.

16. The computer-readable medium as recited in claim 15, wherein the destination address is separately determined for each of a plurality of separate processes operating on the computer system.

17. An address identification system comprising: a processor; anda memory coupled to the processor and configured to store instructions that in response to execution by the processor, cause the processor to invoke an address identifier monitor configured to identify a destination address configured to be accessed by a window for a process operating on a computer system, wherein the process is associated with the computer system, wherein the address identifier monitor comprises:a foreground window monitor configured to determine a foreground window for a process;a resource examiner configured to examine a resource within the foreground window to determine a destination address that is being accessed by the process having a process identifier, wherein the destination address is external with respect to the computer system; anda determining module configured to determine, based at least on the destination address and the process identifier, whether the process is a pre-approved process, in order to ascertain permissions for transmission of unsecured files for the process.

18. The system as recited in claim 17, wherein the resource examiner is further configured to: determine that the process pertains to a network browser operating on the computer system; andexamine the resource being displayed in the foreground window of the network browser to determine the destination address that is being accessed by the network browser.

19. The system as recited in claim 17, wherein the address identifier monitor is further configured to separately identify destination addresses for each of a plurality of separate processes operating on the computer system.

20. The system as recited in claim 17, wherein the address identifier monitor is further configured to inform a file security system about the destination address being or to be accessed by the process so that the file security system can restrict files accessible to the computer system from being transmitted to destinations that are not pre-approved via the process.