Method and apparatus for providing a data masking portal

An approach is provided for de-personalizing data. A request is received from an application for retrieval of data. An end user associated with the request is authenticated. A determination is made whether to mask the data based on the request and the authentication. In response to the determination, a masking algorithm is selected to apply to the data and to output mask data.

BACKGROUND OF THE INVENTION

Globalization and innovations in communication systems have changed the manner in which society lives, does work, etc. Information technological revolutions, such as the Internet, have created a virtual world without boundaries; such exemplars include virtual offices, virtual businesses, virtual hospitals, and online trading. Moreover, modern information technology (IT) operations and IT enabled services can become virtual in terms of off shoring and near shoring. Data management and protection play a key role in advancing these services. It is recognized that while in transit from one physical location to another, personal, business, or governmental sensitive data need to be protected.

In fact, data protection is necessary to ensure compliance with various privacy laws mandated by numerous countries. For example, in many jurisdictions, sensitive data is not permitted to enter foreign land. Consequently, data that crosses a foreign boundary needs to be de-personalized or sanitized. De-personalization, if performed effectively, can stimulate more offshore work.

Conventionally, cryptography has been utilized to ensure data protection. Even though classical cryptographic techniques address the concerns of privacy when data is in transit, such techniques do not effectively resolve the handling of data after its decryption. In addition, it is difficult to implement total communication security; such approach is not only costly, but key management is tedious. Further, because data can be accessed through any application (which protects user level authorization), the data can be inadvertently disclosed to an unauthorized end user.

Therefore, there is a need for an approach for de-personalizing data as to accommodate a wide range of applications.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

A system, method, and software for masking data are 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 is apparent, however, to one skilled in the art that the various exemplary embodiments may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the exemplary embodiments.

Although the various exemplary embodiments are described with respect to data masking, it is contemplated that these embodiments have applicability to any mechanisms that de-personalizes data.

FIG. 1is a diagram of a system capable of providing data masking, according to an exemplary embodiment. A data masking architecture is shown in which a data source100supplies data to a data destination110. By way of example, the data source100may be a database or file. Also, the data destination110can be a database, a file, an application, a browser, a proxy, or a client application. Whenever the data from the data source100is accessed by the data destination110, the data is de-personalized (or sanitized).

According to one embodiment, the data masking architecture includes a data masking proxy120, a data masking configuration wizard130, a policy store140, a masking algorithm engine150, a database access engine160, and a report server170. These components constitute a data masking portal172for masking the data while accessing the data source100. The architecture, according to various embodiments, can accommodate a variety of clients (as shown inFIGS. 6-11): a browser, an application server, a Structure Query Language (SQL) client, a Lightweight Directory Access Protocol (LDAP) client, a mainframe client (e.g., TN3270 client), an editor, etc. The data masking operation, in an exemplary embodiment, can be performed on-the-fly.

Before these clients can access data from the source100, the end user is authenticated against an enterprise wide authentication system180, such as Single Sign On (SSO) or Windows Domain system. Based on the authentication and user configuration policy (resident within the policy store140), the data masking portal172determines whether to mask the data.

Policies that are created through the configuration wizard130are stored in the policy store140. In general, the policy store140provides secure storage of sensitive data. The data masking proxy120retrieves and checks the policy from this policy store140for updating of such policies.

Under this architecture, the report server170provides for logging of transactions of the portal172. In an exemplary embodiment, the report server170creates and stores logs for debugging and tracing purposes. In this manner, graphical reports and text reports can be generated based on the transactions. This reporting process can be performed on a daily basis to record information about daily transactions.

The portal172can provide either static or dynamic masking. To de-personalize the data either in static or dynamic mode, various techniques can be employed (including, for example, known methods). In case of static masking of a relational database (for instance), a large number of rows are processed, whereas dynamic masking handles a single table/view or a join of more than one table/view. In this example, de-personalized data can be available in different environments, including production and non-production scenarios. Masking is one of the processes for de-personalizing the data by protecting sensitive information in non-production databases from unauthorized visibility. Even though a development team may not require live data, the development team may need de-personalized/sanitized data for testing of an application and trouble shooting of particular scenarios or errors in a static mode. Depersonalization (or sanitization) of data poses several challenges in testing and production environments.

Data de-personalization/sanitization extends beyond the technical obstacles. As noted previously, such de-personalization of data is mandated by law. The legal requirements for data sanitization vary from country to country. In the United States for example, the Gramm-Leach-Bliley Act requires institutions to protect the confidentiality and integrity of personal consumer information. The Right to Financial Privacy Act of 1978 creates statutory Fourth Amendment protection for financial records and there are a host of individual state laws. There are also a number of security and privacy requirements for personal information included in the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

With the European Union, Directive 95/46/EC of the European Parliament provides strict guidelines regarding individual rights to data privacy and the responsibilities of data holders to guard against misuse. The United Kingdom Data Protection Act of 1998 extends the European Parliament directive and places further statutory obligations on the holders of personal, private or sensitive data.

Thus, any organization that, for example, outsources test and development operations needs to be conscious of the specific laws regulating the transmission of information across national borders. However large the legal liabilities associated with such violations are, the costs may be trivial in comparison to the losses associated with the catastrophic loss of business confidence that is caused by a large scale privacy breach.

FIG. 2is a flowchart of a data masking process, according to various exemplary embodiments. By way of example, the data masking portal172performs the data masking process, which is described as follows. In step200, the portal172detects a request for data, and authenticates the end user (step202). Next, the user configuration policy stored in the policy store140is retrieved, as in step204. Based on the user configuration policy and the authentication process, the portal172determines, per steps206and208, whether the user has access to this data source. If the determination is in the affirmative, the portal172can obtain a masking policy and check whether the user has privilege to view the real data or masked data, per steps210and212. If the determination is in the negative, the portal172can retrieve data corresponding to the request, and subsequently sending the actual data to the user, as in steps214and216. Next, the transaction is logged by the report server170, per step284.

Returning to step212for the determination of whether the masked data is to be viewed, if the determination is negative, the portal172can retrieve the data per step220. In step222, a masking algorithm is loaded according to the masking policy. The portal172then applies the masking algorithm to the retrieved data (step224). In step226, the policy is released from memory. This transaction is then logged by the report server170, per step218. The masked data is then forwarded to the user, as in step228.

Data masking client components, such as static masking client, SQL client, LDAP client, Editor, TN3270, web browser, or applications, connect to the data masking proxy120for accessing any of the applications or databases of the data source100. The data masking proxy120, according to one embodiment, can act as a Windows service, a web service, or hypertext markup language (HTML) proxy.

It is recognized that the data masking requirement for any large organization can be rather extensive.FIGS. 3-5and8-10illustrate some exemplary scenarios involving different data sources and data destinations.

FIG. 3is a diagram showing the system ofFIG. 1configured to provide static data masking in which the data from production system to non-productions are carried out, according to an exemplary embodiment. In particular, a static masking application is shown, whereby production data needs to be ported during the pre-production environment for various testing and development activities. Whenever an issue arises in the production system for a particular scenario, the data is required in the testing environment to resolve the problem. Conventionally, obtaining access to production data require clearing legal hurdles and can be a manually intensive process. In this example, the data source300can be either a database or a flat file.

During the configuration of any database or file, a masking extensible markup language (XML) policy, for example, can be created with the option of masking either onetime or predetermined interval or on demand. Based on the policy and instruction given, the system can transform the masked data to the data destination310, which can be either a file or a database. Whenever there is a need of masked data, the user can employ the data masking configuration wizard130with authorized user logged in using SSO/Domain authentication system180to generate the masked data on-demand using the data masking portal172. According to one embodiment, the user can schedule the masking activity for at periodic intervals to carry out the masking from the data source300to data destination310.

FIG. 4is a diagram showing the system ofFIG. 1configured to support a Structure Query Language (SQL) masking client that accesses a live production system in real-time, according to an exemplary embodiment. Specifically, this example involves a masking SQL client application accessing data in real-time; such a capability is typical of a database administration function. In other words, the data source400communicates with a SQL client410to provide data stored as a database or file. Under this scenario, the portal172can utilize role based access control mechanism. It is recognized that conventionally even though a role based access control system is utilized, there is no mechanism to prevent a user from viewing the data.

By contrast, the portal120ofFIG. 4can prevent data from being viewed online. The SQL masking client410can be installed anywhere in the network and can be accessed by any number of users. According to one embodiment, the SQL client410always connect to the data masking portal172to fetch the data from the data source400. The data masking proxy120interprets the request from the SQL client410; based on this interpretation, the proxy120obtains any applicable policy from the policy store140and fetches the data from the data source400(e.g., database or file). Per the policy, the masking of the data is preformed, and the resultant output is provided to the client410.

In an exemplary embodiment, the SQL client410is equipped with the tree-view control to browse through various databases in the network, various tables in the database as well as each field in the table. In addition, the SQL client410can include a command line interface so that the end user can execute any SQL query, wherein the output is the masked data. Using this client410, the proxy120can further provide any type of select query, data manipulation queries, and data definition queries; the output from the database is always masked. On invoking this application, the client side authentication takes place with SSO/Domain authentication180, and the associated policy is invoked. If the user configuration specifies masking, the resultant output is masked; otherwise, the data is rendered as is to the client410without masking.

FIG. 5is a diagram showing the system ofFIG. 1configured to support a Lightweight Directory Access Protocol (LDAP) client capable of accessing a live production system in real-time, according to an exemplary embodiment. In this scenario, the data source500is an LDAP server, which stores data accessible by an LDAP client510. The client510, in one embodiment, is a real-time LDAP masking client; this capability is needed for a user who assumes an LDAP administrator role. The LDAP masking client510can be installed anywhere in the network and utilizes the data masking portal172to retrieve data from the LDAP server500. The data masking proxy120interprets requests from the LDAP client510, and based on the interpretation, the proxy120obtains an appropriate policy from the policy store140for fetching of the data from the LDAP server500. The masking of data is performed according to the policy; such masked data is then supplied to the client510.

In an exemplary embodiment, the LDAP client510, as with the client410ofFIG. 4, is equipped with a tree-view control browse through various LDAP elements in the network, as well as the various schemas in the LDAP (as well as each field in the schema). In addition, the client510can provide a command line interface for the end user to execute LDAP queries; the responses to such queries are masked. Through the use of the LDAP client510, masking can be applied to resultant data corresponding to any type of select query, data manipulation queries, and data definition queries.

The workflow of the SQL/LDAP Mask Client with Graphical User Interface (GUI) inFIG. 6is explained as follows. In step600, a user undergoes an authentication procedure with the SSO domain. Next, a determination is made whether the user is authenticated, as in step602. If the user has been authenticated, the user can load, as in step604, the configuration(s) from the policy store140associated with the user; however, if the user is not authenticated, the workflow ends.

In step606, the process determines whether the user has an associated file(s)—i.e., configurations. If so, per step608, the user can select any policy configuration and perform operation on any policy configuration. Thereafter, it is determined whether to mask the data for the user, per step610. The user is checked for privileges, which specify whether show the real data or masked data.

Upon determining that the data is to be masked, per step612, the policy configuration is loaded, as in step614. In step616, data is then retrieved. Also, the mask algorithm is loaded according to the policy, per step618. Next, the mask algorithm is applied, as in step620, and the data is sent back to the user (e.g., client), per step622. Thereafter, the action is logged, as in the step624, and the workflow ends.

Back in step612, if the data is not masked, the data is simply retrieved (step626). Such data is forwarded to the user, and the transaction is logged, per steps622and624.

In another exemplary process, the workflow of a SQL/LDAP Mask Client with Command Line Interface (CLI), as seen inFIG. 7, is explained as follows. In step700, when the user is trying to connect a data source100(e.g., server), the masking proxy120can intercept and request for authentication with the SSO domain (step702). If the user is authenticated, as determined in step704, the user can load the configuration(s) from the policy store140associated with the server100(step706); if not, the workflow ends.

At this point, the remaining steps708-728of the process resemble corresponding steps in the process ofFIG. 6. Per step708, if the user is determined to have any file(s) or configuration(s), any policy configuration can be selected, per step710. In step712, user is checked for the proper privileges for revealing the real data or masked data.

If the data is to be masked, as determined in step714, the masking policy is retrieved and such policy configuration is loaded, as in step716. In step718, data is retrieved, and the mask algorithm is loaded according to the policy, per step720. Next, the mask algorithm is applied, per step722; and the data is transmitted to the user, per step724. This transaction is then logged (step726). If the data is not masked, the data is retrieved (step728), and steps724and726are performed.

FIG. 8is a diagram showing the system ofFIG. 1configured to provide a real-time masking editor for securely accessing files, according to an exemplary embodiment. The data source800in this scenario can include a log file, or files associated with office productivity applications such as Microsoft Word, Microsoft Excel and Microsoft PowerPoint. A masking editor810processes, in real-time, these files to ensure data privacy. The editor810connects to the data masking proxy120to fetch the data. As explained previously, the data masking proxy120applies data masking based on any applicable policy designated for the application.

FIG. 9is a diagram showing the system ofFIG. 1configured to provide a real-time masking client associated with a mainframe application, according to an exemplary embodiment. A user accesses a mainframe application900via a TN3270 client910. Because mainframes are utilized to store and process critical and sensitive data, the data requires protection to be performed efficiently. As part of the interface with mainframe system900, a TN3270 client910, for example, can be used to access and perform various support activities. As with the other applications (FIGS. 4-5), this client910communicates via the data masking portal172to retrieve data.

Operationally, the client910can interact with the mainframe application900similar to the other clients ofFIGS. 4-5. Specifically, when the data masking proxy120receives a request from the TN3270 client910, a policy is retrieved from the policy store140. The proxy accesses the data and masks the data according to the policy. The TN3270 client910can also employ a tree-view control to navigate through the mainframes within the entire network, along with the associated databases. Further, the client910can utilize a command line interface generating data queries. The resultant data from the application900is masked and provided to the client910.

FIG. 10is a diagram showing the system ofFIG. 1configured to provide real-time data layer masking for new or existing applications, wherein masking can occur on-the-fly, according to an exemplary embodiment. It is recognized that conventional applications do not effectively account for data protection, and understandably so, as they are not designed to provide data protection. In general, an application1010may have one or more of the following layers: application layer1020, business layer1030, data access layer1040, and a data bus1050. According to one embodiment, the data bus1050establishes connection to the data masking proxy120. The data masking proxy120, in an exemplary embodiment, can provide a wrapper to all database calls, so that the data that is retrieved from the database is masked in the data masking proxy120and sent to the application1000in form of a masked data bus1060per the masking policy of the application1070.

Additionally, the masked data can be sent across to the application1000for further businesses processing. Such application1000can point to the masking proxy120as the application1000configures a connection to the data source1000. There will not be any code change in the existing application to enable masking. It can support any coding language and any data base.

The above described processes relating to data masking may be implemented via software, hardware (e.g., general processor, DSP chip, an application specific integrated circuit (ASIC), field programmable gate arrays (FPGAs), etc.), firmware, or a combination thereof. Such exemplary hardware for performing the described functions is detailed below.

FIG. 11illustrates a computer system1100upon which an embodiment according to an exemplary embodiment can be implemented. For example, the processes described herein can be implemented using the computer system1100. The computer system1100includes a bus1101or other communication mechanism for communicating information and a processor1103coupled to the bus1101for processing information. The computer system1100also includes main memory1105, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus1101for storing information and instructions to be executed by the processor1103. Main memory1105can also be used for storing temporary variables or other intermediate information during execution of instructions by the processor1103. The computer system1100may further include a read only memory (ROM)1107or other static storage device coupled to the bus1101for storing static information and instructions for the processor1103. A storage device1109, such as a magnetic disk or optical disk, is coupled to the bus1101for persistently storing information and instructions.

The computer system1100may be coupled via the bus1101to a display1111, such as a cathode ray tube (CRT), liquid crystal display, active matrix display, or plasma display, for displaying information to a computer user. An input device1113, such as a keyboard including alphanumeric and other keys, is coupled to the bus1101for communicating information and command selections to the processor1103. Another type of user input device is a cursor control1115, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor1103and for controlling cursor movement on the display1111.

According to one embodiment contemplated herein, the processes described are performed by the computer system1100, in response to the processor1103executing an arrangement of instructions contained in main memory1105. Such instructions can be read into main memory1105from another computer-readable medium, such as the storage device1109. Execution of the arrangement of instructions contained in main memory1105causes the processor1103to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the instructions contained in main memory1105. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement certain embodiments. Thus, the exemplary embodiments are not limited to any specific combination of hardware circuitry and software.

The computer system1100also includes a communication interface1117coupled to bus1101. The communication interface1117provides a two-way data communication coupling to a network link1119connected to a local network1121. For example, the communication interface1117may be a digital subscriber line (DSL) card or modem, an integrated services digital network (ISDN) card, a cable modem, a telephone modem, or any other communication interface to provide a data communication connection to a corresponding type of communication line. As another example, communication interface1117may be a local area network (LAN) card (e.g. for Ethernet™ or an Asynchronous Transfer Model (ATM) network) to provide a data communication connection to a compatible LAN. Wireless links can also be implemented. In any such implementation, communication interface1117sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. Further, the communication interface1117can include peripheral interface devices, such as a Universal Serial Bus (USB) interface, a PCMCIA (Personal Computer Memory Card International Association) interface, etc. Although a single communication interface1117is depicted inFIG. 11, multiple communication interfaces can also be employed.

The network link1119typically provides data communication through one or more networks to other data devices. For example, the network link1119may provide a connection through local network1121to a host computer1123, which has connectivity to a network1125(e.g. a wide area network (WAN) or the global packet data communication network now commonly referred to as the “Internet”) or to data equipment operated by a service provider. The local network1121and the network1125both use electrical, electromagnetic, or optical signals to convey information and instructions. The signals through the various networks and the signals on the network link1119and through the communication interface1117, which communicate digital data with the computer system1100, are exemplary forms of carrier waves bearing the information and instructions.

The computer system1100can send messages and receive data, including program code, through the network(s), the network link1119, and the communication interface1117. In the Internet example, a server (not shown) might transmit requested code belonging to an application program for implementing an exemplary embodiment through the network1125, the local network1121and the communication interface1117. The processor1103may execute the transmitted code while being received and/or store the code in the storage device1109, or other non-volatile storage for later execution. In this manner, the computer system1100may obtain application code in the form of a carrier wave.

In the preceding specification, various preferred embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that flow. The specification and the drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

The following patent applications are incorporated herein by reference in their entireties: co-pending U.S. patent application 11/839827 filed Aug. 16, 2007 , entitled “Method and System for Masking Data”; and co-pending U.S. patent application 11/839802 filed Aug. 16, 2007, entitled “Method and System for Masking Real-time Data.”