This application is a continuation of U.S. patent application Ser. No. 11/383,161, filed May 12, 2006, which claims the benefit of U.S. provisional patent applications 60/755,019, filed Dec. 29, 2005; 60/766,036, filed Dec. 29, 2005; and 60/743,121, filed Jan. 11, 2006. These applications along with all other cited references in this application are incorporated by reference.
The present invention generally relates to the access and usage control and management of information stored in a computer environment. The invention relates more specifically to a method and apparatus for controlling access to and usage of electronic information using centrally managed rules in a computer environment.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Networked computer systems have evolved over the years from simple serially connected computer systems to massively networked computer systems connected via large intranets and the Internet. During this evolution, many different concepts were developed to manage how users are granted access to electronic files stored in the computer systems. How a computer system determines if a user permission to access a file has been a complex problem to solve.
Some operating systems use a simple approach to determining whether a user has permission to access a file. For example the Unix operating system gives a system administrator or file owner the ability to attach access permissions to directories and files. There are three types of access permissions that the system administrator or file owner can select from. The permissions are: read, write, and execute. These permissions can then be limited to three types of users: the owner of the file; the group that the owner belongs to; and other users. Each permission and user type has two states: allowed or denied.
Whenever a user accesses a file, the Unix operating system first checks the permissions set for a file against the user's type. The operating system checks if the user falls into any of the three user types. If the user is a member of any of the user types and the user type has been specified as allowed, then the operating system checks which of the permissions are set as allowed. The user is then allowed to perform any access that falls under an allowed permission.
This approach does not offer much flexibility to the system administrator. The system administrator cannot specify particular users other than the owner or particular groups. The permissions are limited to directories and files within the file system and do not cover nonfile system objects such as e-mails and Web pages. Further, the operating system checks permissions for file accesses based only on user and it does not restrict file accesses based on application programs.
A more advanced approach that is commonly used is called Access Control Lists (ACL). ACL uses a language that allows the system administrator or file owner to set read, write, and execute permissions for specific users and groups of users for accesses to files. In some approaches, each set of ACLs for a particular directory reside in a file stored in that directory. The ACLs apply to files that are contained within that directory. When a user attempts to access a file in a directory, the operating system loads the ACL file and reads the ACL rules that were created by the system administrator or user. The operating system determines if the user is allowed to access the file by parsing the ACL rule. In other approaches, a set of ACLs associated with a file is stored as one or more extended file system attributes of the file. In another implementation, access control and auditing ACLs are stored in a security descriptor associated with a file or a directory.
There are many drawbacks to the ACL approach. ACL only applies to files within a file system and does not apply to nonfile system objects. The ACL support is built into the operating system kernel and cannot be extended. ACL is not very portable because it is file system specific and is therefore not universal which means that not all file systems support the same ACL and not all operating systems have the same interpretation of an ACL. When a file is copied from one file system to another (or from one operating system to another), some of the control information may be lost due to compatibility issues. Further, ACL is difficult to apply to users outside of a company's file system (e.g., a customer). Finally, as with the operating system example above, ACL is capable of controlling file accesses by a user but is not capable of controlling file accesses by a particular application program or at a particular time or location.
Applications such as document management systems require a user to check a document in and out of a library system. Once the document has been checked out, it can be distributed and modified in any manner. This means that there is no control over how a document is used once the document leaves the document management system.
A method and apparatus controls document access and application usage using centrally managed rules. The rules are stored and manipulated in a central rule database via a rule server. Policy enforcers are installed on client systems and/or on servers and perform document access and application usage control for both direct user document accesses and application usage, and application program document accesses by evaluating the rules sent to the policy enforcer. The rule server decides which rules are required by each policy enforcer. A policy enforcer can also perform obligation and remediation operations as a part of rule evaluation. Policy enforcers on client systems and servers can operate autonomously, evaluating policies that have been received, when communications have been discontinued with the rule server.
In an embodiment, the invention is a method of controlling application usage in a number of computers using centrally managed rules, the method including the computer-implemented step of controlling usage of an application program on a computer system, where the controlling step limits the application program's operational functionality in accordance to at least one rule stored on the computer system, and the at least one rule contains at least one expression used by the controlling step to control application program operation.
In another embodiment, the invention is a method of controlling document access in a number of computers using centrally managed rules, the method including the computer-implemented step of controlling, on a computer system, access to documents, where the controlling step limits the document access operation in accordance to at least one rule stored on the computer system, and where the at least one rule contains at least one expression used by the controlling step to control document access operation.
In another embodiment, the invention is a method including: controlling usage, at a client system, of an application program, where the controlling step limits the application program's operational functionality in accordance to at least one rule stored on the client system, and the at least one rule contains at least one expression used by the controlling step to control application program operation. Further, the steps include controlling access, at a server, to documents, where the controlling step limits document access operation in accordance to at least one rule stored on the server, and the at least one rule contains at least one expression used by the controlling step to control document access operation.
In another embodiment, the invention is an apparatus for controlling application usage in a number of computers using centrally managed rules, including: a module for controlling usage of an application program on a computer system, where the controlling module limits the application program's operational functionality in accordance to at least one rule stored on the computer system, and the at least one rule contains at least one expression used by the controlling module to control application program operation.
In another embodiment, the invention is an apparatus for controlling document access in a number of computers using centrally managed rules, including a module for controlling, on a computer system, access to documents, where the controlling module limits the document access operation in accordance to at least one rule stored on the computer system, and the at least one rule contains at least one expression used by the controlling module to control document access operation.
In another embodiment, the invention is an apparatus including: a module for controlling usage, at a client system, of an application program, where the controlling module limits the application program's operational functionality in accordance to at least one rule stored on the client system, and the at least one rule contains at least one expression used by the controlling module to control application program operation. Further, the apparatus includes a module for controlling access, at a server, to documents, where the controlling module limits document access operation in accordance to at least one rule stored on the server, and the at least one rule contains at least one expression used by the controlling module to control document access operation.
In another embodiment, the invention is a method of controlling application usage and document access in a number of computers using centrally managed rules, the method including: controlling usage of an application program on a computer system, where the controlling usage step limits the application program's operational functionality in accordance with at least one rule stored on the computer system, and the at least one rule includes a first expression used by the controlling usage step to control application program operation. Further, the steps include controlling, on a computer system, access to documents, where the controlling access step limits the document access operation in accordance with the at least one rule stored on the computer system, and the at least one rule includes a second expression used by the controlling access step to control access to documents.
In another embodiment, the invention is a method of controlling application usage and document access in a number of computers using centrally managed rules, the method including: controlling usage of an application program on a computer system, where the controlling usage step limits the application program's operational functionality in accordance with a rule stored on the computer system, and the rule includes an expression used by the controlling usage step to control application program operation. Further, the steps include controlling, on a computer system, access to documents, where the controlling access step limits the document access operation in accordance with the rule stored on the computer system, and the expression of the rule is used by the controlling access step to control access to documents.
Other objects, features, and advantages of the present invention will become apparent upon consideration of the following detailed description and the accompanying drawings, in which like reference designations represent like features throughout the figures.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1 is a block diagram that illustrates a policy server that centrally manages policies that are used by workstations and servers according to the invention;
FIG. 2 is a block diagram that illustrates minimal embodiments that utilize a number of workstations each with policy enforcers installed or a number of document servers each with policy enforcers installed according to the invention;
FIG. 3 is a block diagram that illustrates a number of workstations and document servers with policy enforcers installed and coexist within a system according to the invention;
FIG. 4 is a block diagram that illustrates internal components of a policy server according to the invention;
FIG. 5 is a block diagram that illustrates internal components of an intelligence server according to the invention;
FIG. 6 a is a block diagram that illustrates an interceptor and a consequence applicator in a Policy Enforcement Point (PEP) module according to the invention;
FIG. 6 b is a block diagram that illustrates a policy enforcer that implements interception and enforcement functions using a PEP plug-in architecture according to the invention;
FIG. 6 c is a block diagram that illustrates a policy engine running in a process separate from a policy enforcer according to the invention;
FIG. 7 is a block diagram that illustrates a policy engine module's policy input and evaluation output according to the invention;
FIG. 8 is a block diagram that illustrates a policy enforcer installed on a workstation that controls access to files on the workstation according to the invention;
FIG. 9 is a block diagram that illustrates a policy enforcer on a client computer that controls the client computer's access to files on a file server according to the invention;
FIG. 10 a is a block diagram that illustrates a policy enforcer on a file server implemented in operating system kernel that controls access to files on the file server according to the invention;
FIG. 10 b is a block diagram that illustrates a policy enforcer on a file server that controls access to files on the file server according to the invention;
FIG. 10 c is a block diagram that illustrates a policy enforcer on a file server with a policy engine running on a separate computer that controls access to files on the file server according to the invention;
FIG. 11 is a block diagram that illustrates a policy enforcer on a workstation enforcing access control to a nonfile system object according to the invention;
FIG. 12 is a block diagram that illustrates a policy enforcer on a workstation applying an obligation action for a file access operation according to the invention;
FIG. 13 is a block diagram that illustrates a policy enforcer on a workstation applying a remediation action for a file access operation according to the invention;
FIG. 14 is a diagram that illustrates a policy enforcer on a virtual file server that controls a client computer's access to files on a file server or a network attached storage device behind a virtual file server according to the invention;
FIG. 15 is a diagram that illustrates a policy enforcer on a file gateway that controls the client computer's access to files on a file server or a network attached storage device across the wide area network according to the invention;
FIG. 16 is a block diagram that illustrates a policy enforcer on a workstation that controls application usage on the workstation according to the invention;
FIG. 17 is a block diagram that illustrates a policy enforcer on a workstation that controls application usage on the workstation according to the invention;
FIG. 18 is a block diagram that illustrates a policy enforcer on a workstation that controls application usage on nonfile system objects at the workstation according to the invention;
FIG. 19 is a block diagram that illustrates a policy enforcer on a workstation that combines application usage and document access control on files at the workstation according to the invention;
FIG. 20 is a block diagram that illustrates a policy enforcer on a workstation that uses an obligation to implement a regulatory compliance requirement according to the invention;
FIG. 21 is a block diagram that illustrates a policy enforcer on a workstation that controls application usage on nonfile system objects at the workstation according to the invention;
FIG. 22 a is a block diagram that illustrates a document server policy specifying information to be obtained from a point-of-use policy enforcer during policy evaluation according to the invention;
FIG. 22 b is a block diagram that illustrates a workstation policy enforcer transmitting information obtained at a point-of-use to a document server policy enforcer according to the invention;
FIG. 23 is a block diagram that illustrates a file server policy enforcer allows access to a file only if a workstation policy enforcer is detected on a client computer that requested the file according to the invention;
FIG. 24 is a block diagram that illustrates an embodiment where a copy operation is performed from a file server to a destination file server and the destination file server does not have a policy enforcer which results in a denial of the operation according to the invention;
FIG. 25 is a block diagram that illustrates a workstation policy engine needing information about a recipient of a message that is unavailable at its location and the workstation policy engine delegating evaluation of the policy to a policy decision server according to the invention;
FIG. 26 is a block diagram that illustrates a document server policy that requires copies of a file on all workstations be deleted when the master copy on a document server is deleted according to the invention; and
FIG. 27 is a block diagram that illustrates a computer system upon which an embodiment may be implemented.
A method and apparatus for enforcing control policies in an information management system is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Embodiments are described in this application according to the following outline:
1.0 General Overview
2.0 Structural and Functional Description
2.1 A Centrally Managed Policy System
2.2 Policy Creation and Management
2.21 Policy Server
2.22 Intelligence Server
2.3 Policy Enforcers
2.4 Example Scenarios
3.0 Implementation Mechanisms-Hardware Overview
4.0 Extensions and Alternatives
1.0 General Overview
Based on the foregoing, there is a clear need for a system that provides for the control of access to files at both the user and application program levels. Additionally, the system would allow a system administrator to centrally manage access policies for files in workstations and file servers. There is a further need for a system that provides for the control of access to nonfile system objects.
An embodiment of the invention centrally manages policies (or rules) pertaining to the control of access to documents and usage of application data and functions. The policies are stored and manipulated by a policy administrator or user in the policy database via a policy server. The policy server is an intelligent system that has the ability to decide if a single or multiple policies or subset of policies are required by each policy enforcer. The policy server distributes the policies to each policy enforcer.
Policy enforcers are installed on client systems at the operating system level or in application programs (e.g., application programs such as Microsoft Word, Microsoft Excel, SAP Frontend, enterprise resource planning client applications, customer relationship management client applications, Internet Explorer, Mozilla Firefox, Windows Explorer, Notepad, Windows Messenger, Yahoo Messenger, Microsoft Outlook, Windows Media Player, Remote Assistance, FTP client, Java JVM, DOS command shell, DOS programs, and other third party system utilities) on the client system to provide document access and application usage control at the point-of-use. They can also be installed on servers at the operating system level or in an application program on the server to provide protection to the documents on the server.
Policy enforcers are able to perform document access and application usage control for both direct user document accesses and application usage, and application program document accesses and data usage. A document includes any of: a file, a Web page, an e-mail message, a discussion thread, an on-line report, results of a database query, an on-line form, a bitmap, a file system object, a data object managed by a document management system, a data object managed by a content management server, a data object in a product lifecycle management system, a source code file or a code fragment managed by a source code management system, a data object managed by a configuration management system, a data object managed by a project management system, a data object in an enterprise resource planning system, a data object in a customer relationship management system, a data object managed and/or served by a portal server, a data object served by a Web server, a data object managed and/or served by any application server, or any unit of information content stored on volatile or nonvolatile memory.
The client systems and servers can operate autonomously, evaluating policies that have been previously received, when communications have been discontinued with the policy server. For example, a policy enforcer installed on a laptop computer continues to enforce policies installed on or distributed to the laptop computer while the laptop computer is not connected to a network, or the laptop computer is connected to a network but cannot communicate with a policy server. In another example, a policy enforcer installed on a document server continues to enforce policies installed on or distributed to the document server while communication to a policy server is interrupted.
A client system can be a desktop computer, laptop computer, personal digital assistant (PDA), smart phone, thin clients (e.g., HP Consolidated Client Infrastructure clients and Wyse terminals), an instance of client operating environment running on a terminal server (e.g., Microsoft Terminal Server or Citrix MetaFrame), a guest operating system running on a virtual machine (e.g., VMWare Workstation or Microsoft Virtual Server), a server making document access or application usage request (acting as a client in the context of the request), information kiosk, Internet kiosk, and any computing device and computing environment from which a document access or application usage request originates, etc. A server can be a file server, network attached storage (NAS), virtual NAS device (e.g., a NAS switch such as Acopia Adaptive Resource Switch, NeoPath File Director, or Rainfinity RainStorage), edge file gateway (e.g., a wide area file service (WAFS) device such as Cisco File Engine series appliances, Tacit IShared products, or Riverbed Steelhead appliances), Web server, e-mail server, document management system, content management system, portal server, database server, or any other document repository.
In addition to providing control or protection, a policy enforcer can also perform obligation and remediation operations as a result of a document access or application usage attempt (whether successful or not) as dictated by the active policy.
The policies are evaluated when an action is taken by a user or an application to access a document, invoke a function in an application program, or operate on application data object or fragment. The action is intercepted (or detected) and relevant policies are applied before the action is allowed to be carried out. The policies that a policy enforcer can handle can be defined based on the type of action, user, user group, user attribute (e.g., department, role, project or status—full-time, part-time or consultant, user's business function), computer, type of computer (e.g., a laptop or smart phone), group of computers (e.g., “finance department computers”), application program (e.g., Word or Outlook), type of application program (e.g., spreadsheet), application module (e.g., SAP CRM module or Oracle Finance accounting module), location (e.g., New York office vs. London office), connectivity (including access mechanism and bandwidth; e.g., LAN, WLAN, VPN, Bluetooth, Internet, DSL, ISDN, dialup, Remote Desktop Protocol (RDP), Virtual Network Computing (VNC) protocol, latency, secure point-to-point, 56 k, broadband, 100 Mb and 1 Gb), time of day, day of the week, file path, file name, file size, file timestamp, file owner, file properties, document type (e.g., file or e-mail), document format (e.g., xls file or pdf file), document identifier, document classification, document characteristics (e.g., a document contains a watermark), document content, database query, database query result set, database query result set properties, metadata, and more. A policy enforcer can interpret any combination of parameters.
In other aspects, the invention encompasses a computer apparatus and a computer-readable medium configured to carry out the foregoing steps.
2.0 Structural and Functional Description
2.1 A Centrally Managed Policy System
An embodiment of the invention centrally manages policies (or rules) pertaining to the controlling of access to documents and usage of application data and functions. Documents can be file system or nonfile system objects. For example, a file system object may be an Excel spreadsheet. A nonfile system object may be an e-mail message or data delivered to an SAP Frontend client application (e.g., information about an employee) by an SAP human resource module running on a server. A document encompasses objects such as a file, an e-mail message, a Web page, an on-line report, an on-line form, a discussion thread, a result set generated by a database query, a bitmap, a file system object, a data object managed by a document management system, a data object managed by a content management server, a data object in a product lifecycle management system, a source code file or a code fragment managed by a source code management system, a data object managed by a configuration management system, a data object managed by a project management system, a data object in a enterprise resource planning system, a data object in a customer relationship management system, a data object managed and/or served by a portal server, a data object served by a Web server, a data object managed and/or served by any application server, or any unit of information content stored on volatile or nonvolatile memory. The policies allow policy enforcers (also referred to as agents) to make decisions on whether to allow or deny access to a particular document, execute a particular application function, or operate on a particular application data object or fragment. The policy enforcers perform document access and application usage control for operations performed in response to direct user action and execution of application program logic.
Referring to FIG. 1, policies are created and managed by a policy server 101 . As discussed below, a policy may define to whom and under what condition(s) access to a document is granted or denied. The policies are stored and manipulated by the policy author and policy administrator in the policy repository 102 . Policies and/or subsets of policies are transmitted to workstations 103 and document servers 105 to control local and remote document accesses and application usage. A workstation can be a desktop computer, laptop computer, personal digital assistant (PDA), smart phone, thin clients (e.g., HP Consolidated Client Infrastructure clients and Wyse terminals), an instance of client operating environment running on a terminal server (e.g., Microsoft Terminal Server or Citrix MetaFrame), a guest operating system running on a virtual machine (e.g., VMWare Workstation or Microsoft Virtual Server), a server making document access or application usage requests (acting as a client in the context of the request), information kiosk, Internet kiosk, and any computing device and computing environment from which a document access or application usage request originates. A document server can be a file server, network attached storage (NAS), virtual NAS device (e.g., a NAS switch device such as Acopia Adaptive Resource Switch, NeoPath File Director, or Rainfinity RainStorage), edge file gateway (e.g., a wide area file service (WAFS) device such as Cisco File Engine series appliances, Tacit IShared products, or Riverbed Steelhead appliances), Web server, e-mail server, document management system, content management server, portal server, database server, or any other document repository.
A policy enforcer can be installed on a workstation 103 to provide document access and application usage control at the point-of-use. The policies can be stored locally on the workstation. Point-of-use control prevents unauthorized access to documents anywhere on the network and prevents unauthorized application usage and operations on application data or usage of application functions. One may think of point-of-use access control as building a firewall around a user.
Similarly, a policy enforcer can be installed on a document server 105 (e.g., a file server or e-mail server) to provide protection to the documents on (accessible by or managed by) the document server. Server-based protection prevents unauthorized access to documents in a particular repository (or on a server) from any computer on a network, in other words, building a firewall around a server. Besides, an application server policy enforcer such as Microsoft Exchange policy enforcer can also control usage of application data and application functions (e.g., copying an e-mail message, deleting a contact or modifying a calendar entry).
The control and protection functions can be achieved either through one policy or multiple policies defined centrally. The policy server 101 is an intelligent system that has the ability to decide if a single, multiple policies, or a subset of policies are applicable to each policy enforcer. At least a subset of all policies defined is distributed to each policy enforcer.
Controlling document access can have different meanings when operating on different document types. For example, if a document type is a file, then document accesses are file accesses that includes: opening/reading a file, reading a file when connected using VPN, opening a file at a particular time of a day, writing/saving a file, deleting a file, reading a file's permission (or security setting), changing a file's permission, reading a file's attribute, or changing a file's attribute. Another example is when a document type is an e-mail message on a mail server then document access refers to application program internal operations that can include: opening an e-mail, deleting an e-mail, reading an e-mail's attribute, or changing an e-mail's attribute.
Controlling application usage can have different meanings when applied to different applications. For example, if an application is a word processor, then application usage includes: creating a file, opening a file, saving a file, saving a document as a different file, exporting or converting a file to a different format, printing a file, sending a file to a recipient via e-mail, publishing a file in a shared folder, cutting data to a clipboard, pasting data from a clipboard, performing a drag-and-drop operation, adding a macro or a script to a document, or modifying a macro or a script in a document. In another example, if an application is a mail client, then application usage includes: creating an e-mail, opening an e-mail, copying an e-mail, moving an e-mail, archiving an e-mail, saving an e-mail to a file, deleting an e-mail, sending an e-mail, forwarding an e-mail, attaching a file to an e-mail, cutting data to a clipboard, pasting data from a clipboard, performing a drag-and-drop operation, or changing e-mail attributes.
In yet another example, if an application is an enterprise resource planning (ERP) application, application usage includes: creating a quote, converting a quote to an order, viewing customer information, viewing an order, viewing product pricing and discounts, viewing sales data, viewing reports, or viewing employee information.
To control application usage and document access, a policy enforcer may exert control on a computer system at two functional levels. At a first functional level, a policy enforcer detects and controls application operations thereby effecting application usage control. For example, when application usage control is opening a file in Microsoft Word, a policy enforcer detects and controls application operation “File|Open” menu operation in Microsoft Word. At a second functional level, a policy enforcer detects and controls document access operations thereby effecting document access control. For example, when document access control is applied to the same file open action in Microsoft Word, a policy enforcer detects and controls operating system library operations fopen( ), open( ) and FileOpen( ) where these operations are typically required to open a file on local file system or on a file server.
Among the application operations that a policy enforcer may exert control, some application operations may translate into one or more document access operations while other application operations may not perform any document access operation. For example, a user action of opening a file typically translates into an application operation and a document access operation. In another example, a user action of sending an e-mail message in Microsoft Outlook typically translates into an application operation (e.g., “File|Send”) and document access operation (e.g. a send function in messaging application programming interface (MAPI)). In yet another example, a user action of pasting data from a clipboard to a document typically generates an application operation but no document access operation.
To control document access and application usage, a policy enforcer may control user interface elements such as visual and input elements of an application program, commands and functionalities of an application program, and information presented to a user. For example, a visual element of an application program includes any of: a menu, a menu item, a button, a list box, a list item, a check box, a tab, a scroll bar, a slider, an icon, an image or a hypertext link. An input element of an application program includes any of: a key event handler, a mouse event handler, or any event handler associated with a visual element.
An application program may support a large number of commands. A command can be invoked by selecting a menu item, pressing a button (shown on a screen), pressing one or more keys, or pressing one or more mouse buttons. A command can also be invoked by a macro or script, or invoked by a code module that calls a function (or method) in an application program interface (API) library. For example, a command can perform a task such as opening a file, sending an e-mail message, editing a cell in a spreadsheet, editing a macro, changing text format, or more.
A function of an application program generally maps to a function or method in a high level programming language. For example, a function in an application program may correspond to a command such as saving a file, sending an e-mail message, or editing a cell formula in a spreadsheet. A function may also represent an internal application program operation such as a call to operating system library function fopen( ).
If information to be displayed contains personal information such as a social security number, personal identification number (PIN) or account balance, then controlling application usage includes: filtering out or obscuring the personal information.
If information to be displayed contains actionable data or objects such as a button, a hypertext link, or a clickable image, then controlling application usage includes: disabling the button, removing the hypertext link, or removing the link associated with the image.
In addition to providing control or protection, a policy enforcer can also perform obligation and remediation operations (described below) as a result of a document access or application usage attempt (whether successful or not) as dictated by the active policy, or policies.
Different levels of control and protection are achieved by distributing policy enforcers to workstations and/or document servers. For example, by using workstation policy enforcers only, such as on workstation 103 , one can achieve document access and application usage control that covers access to documents on local disks 104 (i.e., local files), access to documents on a protected document server 105 (i.e., protected by a document server policy enforcer), access to documents on an unprotected document server 106 , and application program functions for applications running on the workstation 103 .
When only document server policy enforcers are used, such as on document server 105 , one can achieve document access protection and application usage control for documents on protected servers when the documents are accessed from workstations with a workstation policy enforcer installed 103 and workstations without a workstation policy enforcer installed 107 .
When both workstation policy enforcers and document server policy enforcers are installed, the combined benefit of both installations as described above is achieved.
The policy server 101 allows policies to be centrally managed and automatically distributed and updated to policy enforcers. Distribution is achieved through pushing policies to policy enforcers and/or pulling policies from the policy server 101 by policy enforcers. Policies are not tied to (or stored with) documents. The policies are evaluated when an action is taken by a user (or an application) to access a document or operate on application data. The action is intercepted and relevant policies are applied before the action is allowed to be carried out.
The policies that a policy enforcer can handle can be defined based on the type of action, user, user group, user attribute (e.g., department, role, project or status (e.g., full-time, part-time, or consultant), user's business function), host, group of computers (e.g., “finance department computers”), type of computer (e.g., laptop or smart phone), application program (e.g., Word or Outlook), type of application program (e.g., word processor or spreadsheet), application module (e.g., SAP CRM module or Oracle Finance accounting module), location (e.g., New York office vs. London office), connectivity (including access mechanism and bandwidth; e.g., LAN, WLAN, VPN, Bluetooth, Internet, DSL, ISDN, dialup, Remote Desktop Protocol (RDP), Virtual Network Computing (VNC) protocol, latency, secure point-to-point, 56 k, broadband, 100 Mb and 1 Gb), time of day, day of the week, file path, file name, document size, document timestamp, document owner, document properties, document type (e.g., file and e-mail), document format (e.g., XLS, PDF, or HTML format), document identifier, document classification (e.g., a confidential document or a financial report), document characteristics (e.g., a document contains a watermark), document content (e.g., a document contains a social security number), database query, database query result set, database query result set properties, metadata, and more. Not all of these parameters are required. A policy enforcer can interpret almost any combination.
2.2 Policy Creation and Management
Referring to FIG. 2, minimal embodiments are shown that utilize a number of workstations 204 each with policy enforcers 205 installed or a number of document servers 206 each with policy enforcers installed 207 . The authoring and administration module 201 is a client application running on a workstation. It provides the user interface to create, test, publish, modify, delete, and deploy policies, manage system configuration, monitor system health, and view document access activity, application usage activity and policy enforcement activity. The authoring and administration module 201 is connected to the control center 202 which is responsible for policy lifecycle management, system management, log data management and maintaining a central policy and log repository 203 .
The policy builder 208 acts as an interface to the policy server 211 and makes it simple for the policy author and policy administrator to create, test, publish, and deploy policy rule statements. The main tasks that can be performed with policy builder 208 are policy authoring and policy administration. Policy authoring functions include creating a policy, modifying a policy, testing a policy, publishing a policy (i.e., making a new policy available for deployment and modifications on an existing policy available for redeployment), and retiring a policy. Policy administration functions include maintaining policy related configurations and deploying policies to policy enforcers.
The management console 209 acts as an interface to management server 212 and is a user interface for managing system configuration and monitoring the health of the system.
The policy server 211 transfers policies to the policy enforcers 205 , 207 through a push and/or pull mechanism. The policy server 211 determines what policies are to be delivered to the policy enforcers 205 , 207 and when policies are to be updated on the policy enforcers 205 , 207 . The policy enforcers 205 , 207 report status logs to the log server 213 such as what documents were accessed or application program functions were used and by whom (described below) and what enforcement actions have been taken.
The reporting module 210 is a user interface element that interacts with the log server 213 to provide report generation and data analysis functions. The policy author and policy administrator can use the reporting module to view document access activity, application usage activity and policy enforcement activity and investigate cases of potential information misuse or effectiveness of a policy.
Referring to FIG. 3, a more complex embodiment is shown where a number of workstations 204 and document servers 206 have policy enforcers 205 , 207 installed and coexist within the system. The interaction between the policy builder 208 , the policy server 211 , and the policy repository 303 have been described above.
The reporting and analysis module 307 acts as a user interface to the intelligence server 308 for displaying reports and results from data analysis functions. The reporting module 210 allows the policy author and policy administrator to query and view document access activity, application usage activity and policy enforcement activity. The analysis tool 312 interacts with the intelligence server 308 to perform data analysis which includes event correlation and trend analysis. The policy author and policy administrator can use the capabilities offered by the reporting and analysis module 307 to analyze effectiveness of a policy, document access and application usage activity on a document or on a server, policy enforcement activity, and investigate cases of potential information misuse. The intelligence server 308 provides three functions: log services, integration with external data sources, and data analysis.
The log and intelligence repository 309 is used by the intelligence server 308 to store log data coming from the policy enforcers 205 , 207 , data from external sources that support event correlation, and data generated by the data analysis services. The log and intelligence repository 309 is normally implemented as one or more relational databases or sets of log files.
The Light Weight Directory Access Protocol (LDAP) server 305 and LDAP repository 306 provide user, user group and host information to the policy server 211 to assist in composing policy and assembling policy subsets and provide information to intelligence server 308 to support report generation and data analysis. Note that LDAP servers are normally deployed in organizations to provide authentication service and are not critical for the operation of the embodiment.
A management server 212 is responsible for system configuration (not policy configuration), system health monitoring, and system control. It provides centralized management of all the components in the system. The management server 212 provides a single location to view system status, modify system configurations, and manage policy author and policy administrator user accounts. The management console 209 is a user interface for system management via the management server 212 .
The management server 212 provides services such as: monitoring all other system components including policy servers, intelligence servers, communication servers and policy enforcers; displaying the status of each component; registering new policy enforcers; maintaining a registry of all policy enforcers; managing the configuration for all servers; and managing configuration profiles for policy enforcers.
The communication server 304 is responsible for directing traffic among the policy server 211 , intelligence server 308 , management server 212 and all policy enforcers 205 , 207 . The communication server 304 brokers communications between policy enforcers 205 , 207 , and other servers, including distribution of configuration profiles, policy deployments, and the transfer of log data to the intelligence server 308 . The communication server 304 provides a scalable communication service such that the system can support a large number of workstations 204 and document servers 206 .
2.21 Policy Server
Referring to FIG. 4, the internal components of the policy server 401 are shown. The policy server 401 is responsible for policy management, including policy authoring, life cycle, and deployment. The policy server 401 maintains a policy repository 203 , 303 for storing policies. A system typically has at least one policy server 401 and can contain multiple policy servers in order to support a large number of policy builders 208 and policy enforcers 205 , 207 . The policy server 401 provides the following functions: policy authoring; policy access control; policy lifecycle management; policy management; and policy deployment.
Policy authors and policy administrators access the policy server 401 through the policy builder application 208 which provides a graphical user interface to author policies and manage the policy lifecycle from creation through retirement. Authored policies are stored in a central policy repository 203 , 303 .
The policy lifecycle module 402 provides policy lifecycle support that covers policy development, deployment and management. For example, policy development uses information about users, user groups, roles of users, user's business functions, actions, hosts, applications, and document resources being supported to compose or update a policy. An environment is also provided to support editing (composition), staging (testing) and deployment of policies.
The policy engine 403 is responsible for policy evaluation (or execution). It helps validate a policy and it is part of the staging environment. Additionally, the policy engine 403 can be set up to support proxy policy evaluation. A proxy policy evaluation request may be generated by a policy enforcer under two situations:
1) A workstation policy enforcer 205 (or document server policy enforcer 207 ) does not have a policy engine. A policy engine proxy in the policy enforcer relays policy evaluation requests from policy enforcers to a remote policy engine 403 in a policy server 401 or policy decision server (dedicated to make policy decisions) that offers policy evaluation services.
2) A workstation policy enforcer 205 (or document server policy enforcer 207 ) does have a policy engine, but the local policy engine decides that the local policy subset is not sufficient to make a policy decision and should delegate policy evaluation to a policy engine that has access to a wider policy scope, or access to relevant data. A proxy policy evaluation request is made by a local policy engine to a remote policy engine 403 in the policy server 401 or a policy decision server to complete the policy evaluation.
A policy optimizer 404 is responsible for optimizing the run-time performance of policies. It can be used to optimize policies prior to deploying to a policy enforcer 205 , 207 . The policy optimizer 404 is not required for a minimal system to operate.
The policy deployment module 405 handles deployment of policies to policy enforcers 205 , 207 , policy decision servers (not shown) and the location where a policy engine resides. During policy deployment, the policy deployment module may invoke a policy optimizer 404 to optimize a set of polices (the set of policies can be a full set or subset of policies on the policy server). The deployment function may be initiated by a policy server (e.g., via a push operation) or a policy enforcer or target (e.g., via a pull operation). In either operational mode, a full set or a subset of policies is transmitted to a target.
In a policy system architecture that distributes full sets of policies to all policy enforcers, the policy deployment module 405 takes a complete set of policies and sends it to a policy enforcer 205 , 207 .
In a policy system architecture that organizes policies based on the policy enforcer 205 , 207 that the policies target, the policy deployment module 405 receives or locates a policy enforcer's information and delivers the set of policies defined for that policy enforcer 205 , 207 .
The deployment module can deploy policies in different forms depending on the capability of a policy engine at a target. For example, the set of policies that are transmitted from a policy server to a policy enforcer (or target) may comprise of combinations of the following forms:
(1) ASCII text.
(2) Binary (e.g., code or data).
(3) XML (e.g., in Extensible Access Control Markup Language—XACML format).
(4) Translated and/or compiled form including policies represented in binary form, polices translated into tables (in binary or text form) or policies translated into programming language (such as XML, Java, C#, Perl or Python in source code format or compiled binaries).
2.22 Intelligence Server
Referring to FIG. 5, the internal components of the intelligence server 501 are shown. The intelligence server 501 provides summary, trend, and detailed analysis of document access activity, application usage activity and policy enforcement activity. The intelligence server is accessed using the reporting and analysis 307 software tool that allows business users to create graphical reports to demonstrate compliance, understand application usage, and investigate cases of information misuse. The intelligence server 501 analyzes comprehensive log data captured in a centralized repository, thereby providing insight and accountability for information handling. Policy authors can use data captured by the intelligence server 501 to analyze the effectiveness of a policy. Policy enforcers can utilize the log data and information derived from the log data to support policy evaluation.
The log services module 502 is responsible for collecting and managing log data coming from policy enforcers 205 , 207 . Log data is normally generated or collected by a policy enforcer or explicitly by a policy via a log handler (an obligation handler) in a policy enforcer 205 , 207 .
The integration services module 503 is responsible for capturing events that occur outside of the system and providing access to an external data sources when needed. It may collect data produced by other application programs outside of the system or import data stored outside the system into a log and intelligence repository 309 . The integration services module can also export log and analysis data to application program or repository outside of the system. It allows the data analysis module 505 to correlate document access activities, application usage activities and policy enforcement activities with events that occur externally to the system.
The reporting module 504 is responsible for providing support to the reporting and analysis tool 307 . Its main function is report generation.
The data analysis module 505 provides data analysis functions such as event (or log) correlation. For example, one of the functions of the event correlation engine in the data analysis module 505 is to correlate separate events that occur within a policy enforcer 205 , 207 or across multiple policy enforcers 205 , 207 to identify trends, repetitions, frauds, hacking attempts and other attacks, bad policy designs, and bad practices by users. The data analysis module 505 can provide several types of analyses:
1) Summary Analysis—document access activity, application usage activity or policy enforcement activity summarized by user, document, host, policy, location, time (e.g., day or week), organization, and more.
2) Trend Analysis—document access activity, application usage activity or policy enforcement activity for a given period of time.
3) Detailed Event Forensics—detailed listing of activities for specific user actions or policy enforcement actions. Detailed reports showing event-level details for document access activity, application usage activity or policy enforcement activity. Compliance officers can use event forensics to investigate specific incidents of information misuse.
2.3 Policy Enforcers
A policy enforcer provides three key functions: interception (or detection), decision, and enforcement.
Interception refers to a function of detecting certain operations (e.g., carried out through altering normal code execution that implements the operation) in an existing application program or operating system to allow the operations to be examined by a policy enforcer before the operation is carried out. Alternatively, interception may refer to a function in an application program or operating system (e.g., the logic is implemented at development time) where the function affects examination of an operation by a policy enforcer before the operation is carried out. For example, the function in an application program is a procedure call to a policy enforcer application program interface (API) library.
Decision refers to a process of evaluating zero or more policies (or rules) relevant to an intercepted (or detected) operation and determine if the operation should be carried out, and if additional action(s) need to be performed.
The enforcement function is responsible for implementing the outcome (sometimes called a policy effect) produced by the decision function. For example, if a policy effect is DENY, an operation is blocked.
Interception and enforcement are normally functions of a Policy Enforcement Point (PEP) and decision is a function of a policy engine (described below). Both the PEP and policy engine are components of a policy enforcer. In addition, a policy enforcer can carry out audit (or log) functions, and obligation and remediation tasks (described below).
There can be at least two types of policy enforcers that can exist in a system to provide a multi-layer approach to information control and compliance enforcement, such as: document server policy enforcers and workstation policy enforcers. Document server policy enforcers are designed to control access to and usage of documents on document servers. While workstation policy enforcers are designed to control end-user access to and usage of documents on workstations and document servers and application usage by end-users at a workstation. Combining both types of policy enforcers in an embodiment provides control over document accesses from a workstation controlled by a policy enforcer, from a workstation not controlled by a policy enforcer, to a document server controlled by a policy enforcer, to a document server not controlled by a policy enforcer, and control the usage of information by organization personnel.
Policy enforcers are responsible for both enforcing policy and collecting audit information (document access activities, application usage activities and policy enforcement activities) for their respective host systems. The policy enforcers intercept end-user or system events (or actions) or application usage (e.g., invoking a function in an application program and operating on data in an application) that may be subject to document access or application usage control policies. The context of each of these events is provided by a PEP to a policy engine that is responsible for evaluating policies relevant to the context of an event. The consequence determined by a policy evaluation is communicated back to the PEP which contains application-specific or system-specific logic to carry out the enforcement function. If the policy evaluation results in the requested event being denied, the PEP typically terminates the request and returns an error status that indicates access is denied or the requested action cannot be performed.
Since policy enforcers have access to information regarding document access and application usage, such activity information (or audit information) can be logged by a policy enforcer to a local or central database. The activity data collected by one or more policy enforcers can be correlated, analyzed, and applied to many applications including: 1) auditing or compliance; 2) investigation; 3) detecting information fraud; 4) detecting information misuse; 5) detecting anomalies; 6) understanding and optimizing resource utilization; and 7) understanding and improving workforce productivity.
The data that is collected by a policy enforcer typically includes a combination of: event(s) (or action(s)), attributes associated with the event, resources associated with the event, identification of the application in which the event occurred (or operation being invoked), under which user account the activity is being carried out, the host computer this event occurred on, and so forth.
Policy Enforcers for Document Servers
Document server policy enforcers are server (e.g., a file server) or server application program (e.g., a mail server) specific policy enforcers. For example, a file server policy enforcer (discussed below) is designed to protect file resources on (or managed by) the file server. In another example, an e-mail server policy enforcer, such as a Microsoft Exchange Server policy enforcer, controls access to and usage of e-mail and other Microsoft Exchange Server application objects on the server. In yet another example, a Document Management System (DMS) policy enforcer controls access to and usage of documents stored in a DMS repository and other DMS-specific application objects.
A document server policy enforcer is installed on a server computer (e.g., a file server) or on the computer where a server application program (e.g., a mail server) is installed. Alternatively, some policy enforcer functions including the policy engine can be distributed to a separate computer. The interception function carried out by a PEP is server and server application program specific and can occur inside a server application program or at the operating system level.
Policy Enforcers for File Servers
A file server policy enforcer is a type of document server policy enforcer. The file server policy enforcer controls access to and usage of (e.g., copy and print) files on file servers. It is installed on a file server machine and enforces document access and/or application usage policies as organization personnel interact with the file server. Document access policies control whether users or application programs are allowed to access files and folders on (or managed by) a file server including: create, read, write, delete, copy, move, and rename files; create, open, delete, and rename folders; access and change file or folder attributes; and create, access, change, rename, and delete links or shortcuts associate with files or folders. The policy enforcers also log accesses to files and folders, and information about each enforcement event.
The file server policy enforcer monitors network requests for files and also monitors file system requests. This architecture allows the policy enforcer to evaluate policies based on the greatest amount of context for each request, since it can use both network-level and file system-level information. Certain file access operations can also be intercepted inside a server application program (e.g., a NFS server) and at the operating system level.
In a specific file system implementation, both a file server policy enforcer and a workstation policy enforcer (described below) are typically needed to provide thorough protection to the resources managed by the file system. For example, Andrew File System (AFS) uses a client application program to cache file system objects on a workstation. With only an AFS server policy enforcer, file system objects cached on a workstation are not protected. In that case, a workstation policy enforcer can be combined with an AFS server policy enforcer to provide complete file system resource protection.
The file server policy enforcer is self-monitoring and self-protecting. When it is running, no user or process can modify, delete, or access the policy enforcer system files including the binaries, configuration files, log files, and policy files. If the policy enforcer is stopped unexpectedly, it is automatically restarted.
Policy enforcers can be installed on some or all file servers within an enterprise, depending on which file servers contain documents that the organization wants to enforce document access and/or application usage policies on. A file server policy enforcer affects only the file server where it is installed. Alternatively, the policy engine in a policy enforcer can run on a computer different from the server being managed.
The file server policy enforcer is responsible for controlling accesses to and usage of files stored on (or managed by) a file server. It can control accesses to and usage of files on a file server by workstations that are controlled or not controlled by policy enforcers.
Policy Enforcers for Workstations
The workstation policy enforcer controls end-user usage of documents on workstations. The policy enforcer is installed on a workstation and controls access to and usage of documents, whether those documents are stored on the workstation or remotely. The policy enforcer detects (or intercept) document access and application usage activity for each application running on the workstation. Detection can occur inside an application program or at the operating system level.
Usage policies control whether users of that workstation are allowed to perform various actions such as sending, printing, or copying documents. Usage policies can also apply to application data to control cut-and-paste, drag-and-drop, allowing only a particular group of users to modify a particular spreadsheet formula, restricting edits to macros or scripts by a user, restricting edits to a specific region in a document by a user, restricting certain application functions based on the type of connectivity (such as VPN), restricting a particular type of edit to a document based on time, and restricting screen capture functions to control any misappropriation of data in a document.
Policy enforcers also collect information about each enforcement event for an activity journal or report. The policy enforcer is self-monitoring and self-protecting. When it is running, no user or process can modify, delete, or access the policy enforcer's system files, including the binaries, configuration files, log files, and policy files.
Policy enforcers can be installed on any number of workstations within an enterprise. Each policy enforcer affects only the workstation where it is installed. Policy enforcers may be embedded into a computing device like PDA or smart phone. The policy enforcer can also be installed on a terminal server (e.g., Microsoft Terminal Server or Citrix MetaFrame Server) to control document access and application usage in each client session.
The workstation policy enforcer is responsible for document access and application usage control at the point-of-use. It has the ability to control application usage and access to documents stored locally on the workstation and remotely on document servers. The document servers may or may not be controlled by policy enforcers. The workstation policy enforcer can also control usage of information at a workstation.
Information Exchange
Policy enforcers have the ability to interact with one another and exchange information in order to perform document access and application usage control at their local levels. Information exchange refers to a first policy enforcer obtaining or collecting information gathered by a second policy enforcer to assist the first policy enforcer in performing a policy evaluation.
Collaborative policy evaluation through information exchange is a way for a policy enforcer to expand the pool of information available to it beyond its execution environment when it evaluates policies. Without the ability to exchange information with a second policy enforcer (or multiple policy enforcers), a first policy enforcer can only evaluate policies based on information available at the first policy enforcer's execution environment. Normally, the information at the execution environment is information collected at the time of interception, configuration parameters, and external information within the immediate operating environment (i.e., information obtainable from the operating system and other application programs).
For example, a server policy enforcer typically has no visibility to application usage information that is available at a client computer. The server policy enforcer may request the client policy enforcer to provide specific application usage information so the server policy enforcer can make its decision using that information.
A policy enforcer may have to implement a policy based on information available at another policy enforcer that is normally not available to the policy enforcer itself. With the information exchange capability, a policy enforcer can evaluate policies based on information available at other policy enforcers.
A policy enforcer's capabilities can be expanded significantly by working with other policy enforcers that can provide the information that the policy enforcer needs to complete a particular policy evaluation.
The following is a more detailed example illustrating how a file server policy enforcer implements point-of-use policies.
1) A file server policy enforcer intercepts a file open operation on a file on the file server:
For example, a document server may enforce an application usage policy such as “no printing of highly sensitive documents” by using a policy executed on the document server. The document server policy enforcer, during policy evaluation, can obtain application usage information from the workstation policy enforcer that initiated the operation that the document server intercepted. Alternatively, application usage information can be attached to a request that is intercepted by the document server policy enforcer so that application usage information is available to the document server policy enforcer during policy evaluation. Note that application usage information is normally unavailable to a document server policy enforcer because it is typically physically separate from the point-of-use. The application usage information is available only at the point-of-use.
In one implementation of information exchange, a document server policy enforcer requests application usage information from another policy enforcer located at the workstation that initiated the operation that was intercepted by the document server policy enforcer. In the case where a policy enforcer is installed on the workstation, the workstation policy enforcer responds with the application usage information related to the operation. In the case where a policy enforcer is not installed on the workstation or the document server policy enforcer fails to communicate with a policy enforcer on the workstation, policy evaluation at the document server policy enforcer may produce one of: a default effect, evaluating additional policy or policies, or evaluating a different set of policies.
In an implementation of information exchange, a policy enforcer stores information regarding whether another computer has a policy enforcer installed.
In another implementation of information exchange, a policy enforcer queries a server to determine if another computer has a policy enforcer installed.
In yet another implementation of information exchange, a point-of-use policy enforcer attaches application usage information associated with an operation to one or more messages (or network packets) destined to a document server that implements the operation. For example, the message can be a network protocol message (e.g., TCP or UDP).
In another example, the message is a network file share protocol message (e.g., CIFS or NFS). In yet another example, the message is an application protocol message or is encapsulated in an application programming interface (e.g., HTTP, SOAP, Microsoft Windows Messaging API (MAPI) or Java Messaging Service (JMS)). When a document server policy enforcer detects the existence of the application usage information attached to the one or more messages, it extracts the application usage information and applies it to a policy evaluation when appropriate.
The application usage information can be:
(1) attached to a message as one or more message headers;
(2) attached to the end of a message;
(3) stored in one or more custom fields (or custom record or custom entry) in a message; or
(4) stored in the data as one or more comments in a message.
Transfer of Control
When a user copies a document from a document server to a location outside the document server, the source document server loses control of the “copy” of a document. To avoid losing control of important document content after a document is copied a document server policy can block all copy operations unless a policy enforcer at the destination can be detected. What this means is that a document server allows the copying of a controlled document only if it is sure the control can be maintained after the document is copied to another location. A document server policy enforcer can further require that a destination policy enforcer provide certain types of protection and enforce certain set(s) and/or version of policies before the document server policy enforcer transfers control of a document.
Transfer of control refers to a policy enforcer in charge of protecting certain information does not relinquish control of the information (or a copy of it) until the policy enforcer is sure that there is a policy enforcer at the receiving end and that the receiving policy enforcer has sufficient capabilities to continue to protect such information.
To implement transfer of control policies, the following should be in place:
1) One or more directives or expressions in a policy to indicate that a policy enforcer will need to successfully implement the directives or expressions to satisfy the policy condition.
2) At least one policy enforcer that is capable of implementing such a transfer of control directives.
3) Facilities for policy enforcers to communicate so that a policy enforcer can detect the existence of another policy enforcer and exchange information when needed.
In order to implement such policy, a document server policy enforcer must be able to detect if a policy enforcer is running on the destination workstation (or document server). Note that the destination of a copy operation does not need to be the workstation that issues the command; it can be another computer including a workstation and document server. Communication between a policy enforcer at the source and a policy enforcer at the destination can be direct or indirect through a communication server.
For example, a user attempts to copy a sensitive document from his/her company's protected server to a laptop computer. Without a collaborative policy enforcer on the laptop computer, a document server policy enforcer that implements a transfer of control policy will have to block all copy operations to the laptop computer under all circumstances.
One approach used by document management systems allows any user who has access to a protected document to copy (or checkout) a document knowing that the system will lose control of the information once the document is checked out. It is important to note that at the point that a document is released from a document management system, document control no longer exists.
In this example, the server policy enforcer will not allow a file to be copied to a laptop unless there is a workstation policy enforcer running on the laptop. In a more elaborate implementation, the server policy enforcer may ask the workstation policy enforcer for its capability list and policy version number to make sure the workstation policy enforcer has the right capabilities to protect the information.
A similar example can be applied to the viewing of documents. For example, once a document is opened in a word processing software on a laptop, a user may be able to save it to another file, cut-and-paste part of the document, or make a screen capture of the document. A policy enforcer can disable such functions if they are not desirable.
Delegation
Delegation can occur in three ways:
1. A decision point delegates policy evaluation to one or more decision points at different locations.
2. A decision point instructs one or more policy enforcers at other locations to carry out a consequence produced by its current policy evaluation.
3. A decision point posts an event to one or more decision points that causes a policy evaluation at the target locations.
The decision point is a location where a policy engine is installed. For example, a policy engine can be located in a policy enforcer, a policy server, or a policy decision server (dedicated to making policy decisions). The delegation of a policy evaluation is initiated from a policy engine and the target may be the same policy engine (i.e., local delegation) or another policy engine (i.e., remote delegation). However, the delegation of a consequence application is carried out by a policy enforcer.
There are situations where the information required to support the evaluation of a certain policy is not available to a decision point at a particular location or a consequence produced by a policy evaluation needs to be carried out at one or more locations different from where the decision point is located.
For example, a decision point can delegate a policy evaluation to a decision point that has access to the proper information required to complete the policy evaluation so it can address the information availability issue. Note that in some situations, information availability issues can also be addressed using the information exchange technique described above.
When a policy consequence needs to be carried out at different location(s), it can be handled using the policy consequence delegation technique (2). Alternatively, the post event technique (3) can be used to implement the delegation of a policy consequence.
Delegation is a way for one decision point to ask another decision point to execute a policy on its behalf—one policy engine asks another policy engine to execute a set of policies. A policy engine does not need to be running inside a policy enforcer. It may be one of the policy engines in a policy decision server.
1) Policy evaluation: In the case where information that is available to other decision point(s) is required to complete a policy evaluation, there are two approaches that can be used: 1) use the information exchange technique to obtain the needed information to complete the policy evaluation; or 2) delegate the policy evaluation (complete or partial) to a decision point that has access to the information needed to complete the policy evaluation.
2) Consequence application: In the case that a consequence of a policy needs to be applied at one or more locations different from where the decision point is located, a decision point can complete the evaluation of a policy and delegate the consequence application to one or more policy enforcers. Delegation of a consequence application can be made synchronously (waiting from the helper policy enforcer to complete the consequence application) or asynchronously.
3) Posting an event: A decision point can post an event to one or more target decision point. A posted event is similar to an intercepted operation except the action specified is often an internal event rather than an intercepted action. For example, an intercepted action may be OPEN, SEND and COPY. An internal event may be user defined and can include: APPLY-DELETE, FLUSH-BROWSER-CACHE, or DISABLE-INSTANT-MESSENGER. The posted event becomes an action for the target decision point and the parameters submitted with the event become the resource, subject, and context attributes of the event (or request). The consequence application function discussed throughout can also be carried out using the event posting technique. In addition to the consequence application function, event posting can be used to trigger a policy evaluation at any number of decision points. The event posting operation can be made synchronous or asynchronous. An event to be posted is normally specified in the consequence portion of a policy. When posted, such an event will trigger a policy evaluation at the target location. Additional data is normally posted along with the event and may include: source action, context, resource, and subject information.
For example, in the case of delegating a policy evaluation, when a workstation policy enforcer does not have the information needed to complete the evaluation of a policy, it can delegate the policy evaluation to a server policy enforcer that has access to the information required to complete the policy evaluation. The consequence of a policy evaluation produced by the server policy enforcer is returned to the workstation policy enforcer so the policy consequence can be applied at the workstation.
In another example of delegated policy evaluation, a master decision point can delegate the evaluation of policies to more than one helper decision point. A master decision point can be a policy engine in the workstation policy enforcers or document server policy enforcers or a policy engine in a policy decision server (a centralize cluster of policy engines dedicated to perform policy evaluation). A helper decision point can be any one of the policy engines listed above other than the master policy engine. The master decision point can combine the consequences collected from the helper decision points and apply the combined consequences.
A master decision point (especially a policy enforcer) may not have the visibility to certain information that is required to evaluate a particular policy. By delegating the evaluation of that particular policy at a location where the required information is available or accessible, the master decision point and helper decision point(s) can operate collaboratively to process complex policies. The master decision point queries helper decision points to find out if the helper decision point exists and also whether the helper decision point has the ability to evaluate and/or enforce the policy.
A master decision point (especially a policy decision server) can act as a coordinator that coordinates policy evaluation at multiple locations. This type of function is often found in maintenance policies where a master policy executed at a central location distributes policy evaluation tasks to decision points at remote locations. For example, a master decision point may instruct policy enforcers on all mobile devices to implement a set of policies that clean up sensitive information on such devices.
In an example of delegating a consequence application, a document server policy enforcer evaluates a policy that controls deletion of a document by a manager on a document server. The policy requires that when the master copy of a document (i.e., the one that sits on a document server) is deleted, all copies of the same document distributed (or copied) to workstations must also be deleted. This document server policy requires distributed consequence application support to carry out document deletion at the workstations.
Policy Enforcer Software Architecture
Referring to FIGS. 6 a - c , policy enforcers 601 for document servers and workstations have a similar architecture. An interceptor 610 is responsible for intercepting (or detecting) application usage and document access operations (or actions), collecting information about an intercepted operation (e.g., type of action, document(s) associated with the action, and information about the application or module where interception occurred), and forwarding the data collected to a policy engine 603 for performing policy evaluation. The consequence of a policy evaluation is returned by a policy engine 603 to a consequence applicator 611 . A consequence applicator 611 is responsible for applying any consequences of a policy evaluation that includes a policy effect and additional tasks.
FIG. 6 a illustrates an embodiment where an interceptor 610 and a consequence applicator 611 are components of a Policy Enforcement Point (PEP) 602 module and the policy enforcer 601 consists of at least one PEP 602 and one policy engine 603 .
FIG. 6 b illustrates an embodiment where a policy enforcer 601 implements interception and enforcement functions using a PEP plug-in architecture. The policy enforcer consists of one PEP 602 and at least one PEP Plug-in module 613 . Both interceptor 610 and consequence applicator 611 are components of a PEP Plug-in module 613 .
FIG. 6 c illustrates an embodiment where a policy engine 603 runs in a process separate from a policy enforcer 601 . The policy decision process 614 and policy enforcer 601 can run on the same computer or on separate computers.
The interceptor 610 and consequence applicators 611 are functional entities where the implementation of the two functions varies from operating system to operating system and application to application. In some cases, the interceptor 610 and consequence applicator 611 functionalities are combined into one code module. In other cases, the interceptor 610 and consequence applicator 611 reside in separate code modules.
The interceptors 610 and consequence applicators 611 may function at the application program level or the operating system level in order to carry out the interception and consequence applicator functions. Application program level interceptors and consequence applicators are application program specific code modules which can be implemented as add-ins, plug-ins, scripts, macros, libraries and extension programs. Operating system level interceptors and consequence applicators are operating system specific code modules that can be implemented as libraries, filters and device drivers.
To control application usage, a policy enforcer effects control on application program operations (e.g., blocking an application program operation) and/or filters results generated by the application program operations (e.g., remove text or disable actionable object in the result). Using interceptors and consequence applicators, an application program operation is intercepted (or detected) and information about the application program operation is provided to a policy engine to make a policy decision, and if the policy decision specifies an enforcement action, the enforcement action is carried out effecting control on the application program operation or filtering of results generated by the application program operation.
A policy enforcer may use one or more methods to implement application usage control. The methods include: (a) blocking or altering an application program operating after it is invoked directly or indirectly by a user but before the application program operation is carried out; (b) disabling or hiding a user interface element responsible for invoking an application program operation so that a user cannot invoke the application program operation through the user interface element; and (c) removing, altering or obscuring a part or all of the result generated by an application program operation making certain information not available to a user. Note that the user interface element described in (b) may be an element of an application program (e.g., a menu item or a button) or an element of the result generated by an application program operation (e.g., a hypertext link, a check box or a list box).
In a graphical user interface environment, an application program operation may correspond to an operation associated with a user interface element. If a user interface element is a menu item, a corresponding application program operation is an operation that will be carried out when the menu item is selected (e.g., printing a document). If a user interface element is a hypertext link (such as a clickable word or phrase on a Web page), a corresponding application program operation is an operation that will be carried out when the hypertext link is clicked (e.g., loading a new Web page or jumping to another position on a Web page). Other common user interface elements include a: menu, button, list box, list item, check box, scroll bar, key (on the keyboard), and mouse button. An application program operation may also correspond to a command or function that is invoked by a user indirectly (e.g., through a macro or script) or by another application program.
To filter results generated by an application program operation, a consequence applicator may alter, substitute, remove, hide or obscure one or more portions (or all) of the result to be presented to a user. The consequence applicator may also alter, substitute, remove, hide, disable or obscure one or more actionable objects or fragments of text (e.g., menu, tab, buttons, check boxes, list boxes, or hypertext links).
To control document access, a policy enforcer effects control on document access operations. Common document access operations include: read (or open), write (or save), execute (for binary file or script), delete, read permission (or security setting), and change permission. Many document repositories (especially document management systems) support additional document access operations.
Typically, interceptors and consequence applicators intercept (or detect) a document access operation and information about the document access operation is provided to a policy engine to make a policy decision, and if the policy decision specifies an enforcement action, the enforcement action is carried out effecting control on the document access operation. Alternatively, the interceptors and consequence applicators may also integrate with an existing access control system provided by a document repository (e.g., document management system).
Interceptors and consequence applicators that control document access are document repository dependent. They may be installed in a document server application program (e.g., HTTP server, IBM Lotus Notes Server, Microsoft Exchange Server, or Microsoft Sharepoint Portal Server), at an application program interface (e.g., MAPI, JMS, ODBC, JDBC and Oracle SQL*NET), at an application protocol interface, or act as a application protocol proxy between a client and a server (e.g., HTTP, FTP or SOAP), at file system libraries, at network file share protocol driver (e.g., CIFS or NFS), or at file system device driver.
Some common document repositories include: file servers, mail servers, document management server, content management server, HTTP or Web servers, FTP servers, WebDAV servers, and database servers.
In one implementation of a policy enforcer, interceptors and consequence applications are installed in an existing application program or operating system to implement interception (or detection) and enforcement functions. The interceptors and consequence applicators are not native elements of the application program or operating system.
In another implementation of a policy enforcer, interceptors and consequence applicators are native elements of an application program or operating system. Interception and enforcement may be implemented through one or more calls to a policy enforcer application program interface (API). For example, a policy enforcer API is provided in the form of a software development kit (SDK).
A workstation policy enforcer installs a number of application program interceptors 610 and consequence applicators 611 to monitor document access and application usage operations (or actions) inside individual application programs and to apply enforcement actions. In addition, a workstation policy enforcer also installs operating system interceptors 610 and consequence applicators 611 to monitor file accesses from application programs and to apply enforcement actions. The operating system interceptors 610 can intercept operations from application programs that are or are not monitored by application program interceptors on the workstation.
Interceptors 610 and consequence applicators 611 can be setup during program installation time or anytime during a program's lifecycle. One method that can be used to setup an interceptor is to perform code analysis on an application program or library module and then modify the stored program code. Another method that can be used to setup an interceptor is through code injection at program startup time. Yet another method that can be used to setup an interceptor is to perform code injection after the program has been started. Code injection includes any method that modifies existing program code and/or inserts new code into an existing program code to implement an additional function. The existing program code can reside in volatile or nonvolatile memory.
The consequence applicator 611 implements the consequence (or outcome) called for by the policy engine 603 . The consequence includes an effect of policy evaluation and optionally obligation and remediation tasks (described below) to be carried out. An effect includes whether an operation should be allowed or denied; querying a user for input; evaluating another set(s) of policies; and calling a custom effect handler (described below).
The local policy repository 604 holds a copy of policies applicable to a policy enforcer. Depending on the policy system architecture selected, the set of policies in the local policy repository 604 may be a full set of policies from the policy server or a subset. The local policy may be stored locally in a relational database, in one or more files, or in any form that convenient to the policy enforcer. By storing policies for a policy enforcer locally, a workstation policy enforcer can continue to function while the workstation is off-line and the policy server cannot be reached.
The custom effect handler 612 is a code module that implements custom effects and is optional in the policy enforcer 601 .
An obligation handler 605 is a code module that carries out obligations supported by the policy system architecture. An obligation is a task that is related to the intercepted action that a policy enforcer is obligated to take. The tasks may include logging an action being intercepted, sending a notification to an administrator regarding the intercepted action, and archiving or encrypting the document associated with the intercepted action. For example, if a policy says “any e-mail sent to a patient should be maintained in the patient record database; and the obligation action is to send (or ‘bcc’) a copy of the e-mail to the record management system”. In this case, a policy enforcer automatically applies the obligation action (i.e., archive) and sends a copy of an e-mail to a record management system.
In a second example, the obligation can be used to implement regulatory compliance requirements such as “all e-mail communications from an executive must be archived”. A policy can be written to capture all send and forward actions on e-mail messages and to apply an archive obligation action automatically.
Some obligation handlers are executed inside a policy enforcer 601 process (e.g., the log handler) while others are implemented as PEP 602 components executing inside an application program (e.g., an e-mail delete handler) or an operating system. The obligation handler 605 is optional in the policy enforcer 601 .
The remediation handler 606 is very similar in function to the obligation handler 605 except it performs different functions. Remediation means additional actions taken that are different from what is being intercepted. Such actions are introduced solely by policies defined to “remediate”.
The tamper resistance module 609 is responsible for preventing, blocking, monitoring, and recovering from attempts to disable or alter the function of a policy enforcer. Many techniques can be used to protect program files and configurations from modifications and corruption. For example:
1) Multiple copies of files can be maintained and a missing or corrupted file can be restored from the backup copies.
2) Checksums or signatures can be generated on important files and stored in nonvolatile memory to enable detection of corrupted program and data files.
3) Access to policy enforcer program files and configurations can be restricted.
4) Changes to a policy enforcer's Windows registry entries can also be monitored, blocked and automatically restored.
The communication and synchronization module 608 is responsible for maintaining connection(s) to the policy server 211 and intelligence server 308 , handling policy updates, and transferring log data to the log and intelligence repository 309 .
The policy scheduler 615 implements maintenance policies set by the administrator or user. A maintenance policy tells the policy scheduler when to perform an action and what the action is. For example, the policy scheduler 615 can be given a maintenance policy that instructs it to perform a nightly scan of all e-mail messages and to delete any e-mail messages older than 90 days.
A maintenance policy uses the same format as a normal policy, but rather than being evaluated in response to an action by a user or application program, the maintenance policy is evaluated at a certain specified date and/or time. The policy scheduler 615 implements any specified obligation or remediation action specified in the maintenance policy.
Variations of implementations of a policy enforcer can take the form of:
1) The policy enforcer includes a policy engine 603 , a local policy repository 604 and one or more policy enforcement points 602 . The local policy repository may reside in volatile or nonvolatile memory of a host computer. The policy enforcer may optionally include any combination of: an auditor 607 , a policy scheduler 615 , obligation handlers 605 , remediation handlers 606 , or a tamper resistance module 609 .
2) The policy enforcer includes a policy engine 603 , a local policy repository 604 , a policy enforcement point 602 and one or more PEP Plug-ins 613 . The local policy repository may reside in volatile or nonvolatile memory of a host computer. The policy enforcer may optionally include any combination of: an auditor 607 , a policy scheduler 615 , obligation handlers 605 , remediation handlers 606 , or a tamper resistance module 609 .
3) The policy enforcer includes a policy engine 603 , a local policy repository 604 and an interface to policy enforcement points. The local policy repository may reside in volatile or nonvolatile memory of a host computer. The policy enforcement point interface provides a means to support additional policy enforcement points (e.g., policy enforcement points provided by a third-party). The policy enforcer may optionally include any combination of an auditor 607 , a policy scheduler 615 , obligation handlers 605 , remediation handlers 606 , or a tamper resistance module 609 .
4) The policy enforcer implements a policy enforcement point plug-in architecture illustrated in FIG. 6 b and the additional policy enforcement points are provided as PEP Plug-ins 613 .
5) The policy enforcer is installed on a host computer without any policies (or rules). Upon startup of the policy enforcer, the policy enforcer communicates with a policy server and the policy server transmits a set of policies to the host computer. On successful transmission of the set of policies, the policy enforcer enforces the set of policies at the host computer.
6) The policy enforcer provides information (e.g., host name, IP address, type of computer or operating system) to the policy server to help determine the set of policies to be transmitted. The set of policies may be a subset of policies managed by the policy server.
7) The policy enforcer is installed on a host computer with a set of default policies (or rules). The set of default policies is enforced by the policy enforcer until a second set of policies is received by the host computer.
8) A set of policies on the host computer (e.g., the set of default policies) is replaced by the second set of policies and the policy enforcer enforces the second set of policies at the host computer.
9) A set of policies on the host computer (e.g., the set of default policies) is combined with the second set of policies and the policy enforcer enforces the combined set of policies at the host computer.
10) The policy enforcer is installed on a host computer with a set of preinstalled policies (or rules). The set of preinstalled policies is enforced by the policy enforcer until a second set of policies is received by the host computer. Upon successful reception of the second set of policies, the policy enforcer enforces both the set of preinstalled policies and the second set of policies at the host computer.
11) A policy enforcer is installed on a host computer with a set of configurable policies (or rules) and a default policy configuration. The configurable policies are enforced by the policy enforcer at the host computer according to the default configuration until a second policy configuration is received by the host computer.
12) A policy configuration on the host computer (e.g., the default policy configuration) is replaced by the second policy configuration and the policy enforcer enforces the configurable policies at the host computer according to the second policy configuration.
13) A policy configuration on the host computer (e.g., the default policy configuration) is combined with the second policy configuration and the policy enforcer enforces the configurable policies at the host computer according to the combined policy configuration.
Policy Engine
A policy engine 603 is an execution unit that processes and executes rules (or policies). The policy engine 603 takes the data collected by an interceptor 610 (and any other pertinent data such as historical data from prior interceptions and configuration and environment data) and applies the policy rules supplied by the policy server to the data to produce a consequence. A consequence may include an effect (e.g., ALLOW, DENY, evaluate another policy or set(s) of policies, query user, or call a custom effect handler) and optionally one or more obligation and remediation tasks. The use of historical data in a policy evaluation is optional. As part of the policy evaluation process, a policy engine may decide that it needs to obtain input form a user before it can proceed with (or complete) policy evaluation. At that time, a policy engine can invoke user interface elements to query the user for input. For example, such input is related to classifying a document (which produces document attribute values) that is required to complete policy evaluation.
Also, as part of the policy evaluation process, a policy engine may decide that it needs to obtain document classification information in order to complete policy evaluation. The process of obtaining document classification information may involve retrieving stored document classification data or dynamically invoking a