BACKGROUND
Software testing is an integral part of software development. Ideally, the data used when testing software will resemble live data that is expected when the software is deployed. However, for security reasons, live data is not always available.
For example, some software deals with personal or confidential information. A banking application may access a database that has names, addresses, social security numbers, and bank balances of customers. Besides possibly being in violation of the law, providing such information to testers may not be desirable because the testing environment might not otherwise need to have the security safeguards in place to adequately protect the data.
Accordingly, testing may be done with data that does not resemble live data. However, such an approach can easily lead to inadequate testing. As a result, certain problems with the software are later found after the application is put into production, leading to dissatisfied users.
Although there are certain data masking software packages available, they are not sufficiently flexible and do not lend themselves well to use in a variety of settings.
Therefore, there still remains need for technologies to address shortcomings of current data masking techniques. ,,, , .
SUMMARY
A variety of techniques can be used for supporting data masking. As described herein, a wide variety of data sources and execution mechanisms can be supported. Configuration for a wide variety of scenarios can be achieved via a configurable data masking tool without having to write data masking code.
A configurable data masking tool that pan be accessed in a variety of ways can be helpful because developers need not start from scratch or re-code if data masking is desired for a particular software development project. Instead, the tool can easily be tailored to work within the particularities of the project via configuration data..
Flexibility of a data masking tool can accommodate data from a variety of sources, including different technology platform types.
The data masking tool can inputand output; data in a common, editable format (e.g., extensible markup language) so that a variety pfptter tools can be used.
Data can be extracted from a metadata management tool to avoid re-entry of data.
If desired, a Mersenne Twister random number generation technique can be employed for high quality randomness.
As described herein, a variety of other features and advantages can be incorporated into the technologies as desired. ,
The foregoing and other features and advantages will become more apparent from the following detailed description of disclosed embodiments, which proceeds with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE FIGURES
FIG. 1 is a block diagram of an exemplary data masking tool.
FIG. 2 is a flowchart of an exemplary methpd pf;masking data and can be implemented in a data masking tool such as that shown in, FIQ. 1. .
FIG. 3 is a block diagram of an exemplary daty masking tool with an application programming interface (API).
FIG. 4 is a block diagram of an exemplary data masking tool with an application programming interface (API) that can be used to specify configuration data outside of the tool.
FIG. 5 is a flowchart of an exemplary method of masking data in response to a call to an application programming interface. , .
FIG. 6 is a block diagram of an exemplary da& masking tool that supports a variety of execution mechanisms.
FIG. 7 is a block diagram of an exemplary data masking tool working in concert with an external configuration tool. , ", > /,.j'. . i
FIG. 8 is a block diagram of an exeniplaiy data masking topi system that is invoked by a custom transformation via a hosting application. , j t,.,
FIG. 9 is a flow chart of an exempJary method of invoking a data masking tool with a
' ' V.i,'"; V ' ; - ,■■■'■ ■
custom transformation executed by a hosting application ,
FIG. 10 is a block diagram of an exemplary dato masking tool that supports a variety of source data types. i , , i .
FIG. 11 is a block diagram of an exemplary data masking profile.
FIG. 12 is a block diagram of afi exeniplary executable data masking task.
'' i ' " ;'.<'■!' wi V') :{'■'.''ii *!■''>'',■■•
FIG. 13 is a block diagram of an exemplary data masking tool working in concert with a metadata management tool. .v
FIG. 14 is a flow chart of an exemplary method of extracting data masking configuration data from a metadata management tool.
FIG. 15 shows an exemplary architecture for aidata masking tool.
FIG. 16 shows another exemplary architecture for a data masking tool.
FIG. 17 shows exemplary connectivity for a data masking tool.
FIGS. 18, 19, 20, 21, 22, 23, 24, 25,26, 27,28, and 29 are screen shots of a web interface to a data masking tool.
FIG. 30 shows a spreadsheet-based cohfigurition of a data masking tool.
FIGS. 31A-C and FIGS. 32A-B show exemplary data masking rules.
FIGS. 33, 34, 35, 36, 37, 38, and. 39 ^how'exemplary screen shots for implementing a custom transform for a hosting application tljat invokes^a data masking tool.
FIG. 40 is a block diagram jpf ar\ ex?mj>lary suitable computing environment for implementing any of the technologies described herein.
."'■i. i .1
DETAILED DESCRIPTION
Example 1 - Exemplary System Employing a Combination of the Technologies
FIG. 1 is a block diagram of an exemplary implemented in a data masking tool such as that shown in FIGS. 3 or 4. ,, . , ',
At 510, a call to the API is received. At 520, responsive to the call, confi^uratipn daty is read.
At 530, masking rules are applied (e g., b^ a data masking engine) as indicated via configuration data. " ,, ,
At 550, the masked data is output.
'■ - . i ' • ? i '
■ • •» . ' • ' " •
,.• /■ \ / r ' . V - '
. M \ \ ■ .P
Example 7 - Exemplary Execution Mechanisms
FIG. 6 is a block diagram of an^ekemplary data masking tool 600 that supports a variety of execution mechanisms.
In the example, the API 640 can accept calls from a web interface 660. For example, a web interface can present configuration screens by which a user can create configuration data (e.g., a data masking profile) and execute one or more profiles against source data.
The API 640 can also accept calls from'other interfaces 670 (e.g., any application that can issue API calls or serve as a hosting application for a data masking tool plug in). For example, it may be desirable for an application to have access to data masking functionality, or a custom front end can be provided. , , •
The API 640 can also accept calls as a result of a command given at a command line 680. For example, a command can be configured to invoke the API 640 with specified configuration data.
The API 640 can also be invoked, from a Service Oriented Architecture (SOA) endpoint 690. Thus, data can be masked via th^ SPA. iecb^ue (e.g., through a web service without installing the data masking software at a local machine). *
Example 8 - Exemplary External Configuration ToqI <
FIG. 7 is a block diagram of an exemplary data masking tool 700 working in concert with
an external configuration tool 790. . j f v - , . ' : 'i. .f'- '!. j ft i . '
In the example, an interface 770 can. invoke the API 740 and specify that the data masking tool 120 apply the configuration data 755.
The configuration data 770 can be generated by an external configuration tool 790. For example, the data masking tool ;72Q cafv be configured to recognize a language (e.g., XML), and the configuration tool 790 can generate ponfiguration data for consumption by the data masking tool 720 in the language.
In this way, a commonly available application (e.g., MICROSOFT EXCEL software)
. ./; ' It*.. : ' '.1 .
can be used to generate the configuration data 755.
. •:./, ...■ , Example 9 - Exemplary Hosting Application "
FIG. 8 is a block diagram of an exemplary data masking tool system 890 that is invoked
by a custom transformation 860 via a h'osting application 870. One example of a hosting
application 870 is INFORMATICA software; other software that can support access to a custom
transform 860 can be used. ' ' u.
In the example, the hosting application 870 has access to input data 815 and can send the
data to the custom transformation 860 to generate appropriate configuration data 855 and invoke
the data masking tool 120 (e.g., via API 840) to perform data masking. The custom
transformation 860 can provide the unmasked data 810 and retrieve the masked data 880, which
is then relayed back to the hosting application 870, which stores it as output data 895.
Such an arrangement can be particularly useful if the hosting application 870 can access
data in specialized environments, such as in I mainframe environment. The hosting application
870 can serve as a broker between the specialized environment and the data masking tool 120.
Example 10 - Exemplary Hosting Application, Method ,
FIG. 9 is a flow chart of an exemp^ ^eth^ jipO of invoking a data masking tool with a custom transformation executed by a ho^ng ^p^ic^ion. , ,
At 910, input data is read with the hosting application. At 920, the input data is sent to the custom transformation. For example, in a flat file situation, the flat file can be read and then sent to the custom transformation (e,g., the entire file, or record by record). Data can be sent via a port arrangement. ..,,. A r ,
At 930, the data masking tool AJPI is invpked.with the custom transformation to perform data masking. : . . . ■
At 950, the masked data is received fj;om the data masking tool. For example, the custom transformation can specify a target locationat,, which thetool will place the data.
At 950, the masked data is related ,to ^h? homing application. A port arrangement can be
used.
Example 11-Exemplary Source Data types
FIG. 10 is a block diagram of an exemplary data masking tool 1000 that supports a variety of source data types.
'iW ' ' ' M l • .
In any of the examples herein, the data masking tool 120 can support a variety of source data types. For example, unmasked flatt file data 1010A, unmasked database data 1010B, and unmasked other data 1010C (e.g., data passed When the data masking tool is a plug in hosted by
an application) can be supported. c ■ . .V
i • ,t
Similarly, the output (e.g., target) data types can be of different kinds 1030A, 1030B, and
1030C.
If desired, a hybrid approach can be used (e.g., input of one type of data and output of another).
Further, the data sources and data targets ean be from different technology platform types (e.g., mainframes, microcomputer-based desktops, UNIX-based systems, and the like). Similarly, a platform-hybrid approach (a data source from one platform type and a data target on another platform type) can be implemented- "
. \ ,v <4/ ■ }'[ii : i'
Example 12 -Use with Flat Files <
In any of the examples herein, thedata masking,tool can be used to mask data in flat files. Features to assist in masking can be offeied,'such as automatically detecting details about the format of a table represented in a flat fil^.fore^amplej the tpol can be configured to read a table in a flat file and determine the number of columns,' mane of columns (e.g., if stored in the first row of the flat file), data type, size, precision^ and lhe like. The format (e.g., list of column names) of the table in the flat file arid the fields therein can be presented to the user for confirmation. Because the column narne? arelistel'
If desired, incomplete information c£n be completed based on partially-populated configuration information. For example, a user can choose the appropriate masking rules to be applied to the respective columns in a table. ' f
However, it is also possible for the metadata management tool to store the masking rules and masking parameters as part of its metadata, leading to a more integrated configuration information management approach.
At 1450, data masking is performed with the data masking configuration information, including that obtained from the metadata management tool.
Example 16- Exemplary Executable Data Masking Task
FIG. 12 is a block diagram1 ofan exemplary Meeutable data masking task 1200. In the example, the executable d^ta inking task 1200 includes one or more names or locations of data masking profiles that ate executed when the executable data masking task 1200 is invoked. In this way, more th^i one pjpfil^jSaii b? #nmg together to achieve more complex functionality or to re-use functionality already ayailabj||.
Example 17- Exemplary Architecture: J2EEApplication
FIG. 15 shows an exemplary archi|ec^e forj a ^ata masking tool. The data masking tool can be developed as a three-tier J,2EE application comprising a web application and data tiers. Tiers of the application can have one or more components.
The client tier need not be considered a part of the system because a standard browser can be used. However, it can be considered the client side of the data masking system in some implementations. ^ ^ tr, . r,
The web tier can include the pres^^tionjWith JJ5IV forming the view and Struts providing the control as depicted in FIG., 15, The wesb tier can implement the user interface of the tool providing the user with the -to. ,4efin^^n^ning. the various entities like Source Definitions, Profiles, Data Sets, and Executions. t .
" "/ '■ ' " ; * ' ' ... ' . ■ 1 '",/.'•'' V . "
'• ""•... j'!:'., 1 . • : !' , I V .: ■ .t *,, ;
The application tier Cati incllids^ ihfi&^etore, execution, and I/O components to provide execution control, logic implementation, and file system access respectively as depicted in the diagram. r ; :VV-
The I/O Component can perform the task of reading the input source data, passing it to the execution component, and subsequently receiving tfiis masked output data from the execution component. j " >
The Execution Component can iAcliide the data masking logic and algorithms. The component can perform the following; , applying the rules defined in the profile to the input dataset (e.g., source data) received from the I/O component; return the masked output dataset (e.g., target data) to the I/O component; compose the fexecution details into XML format. The execution component can be self-sufficient and expose an interface that can be invoked from other applications. X '' ^ ■ / - - f
The Infrastructure Component can be Used for-functions like logging, error handling, and the like. - V ; '
The Data tier implements access 1.0. the mapping rules persisted in the data store. The persistence component can encapsulate the database interaction logic and be accessed by the web component and the execution component. . ^ 4 , -
Example 18- Another Exemplary Architecture
FIG. 16 shows another exemplary^cljitectipe for a data masking tool.
Example 19 - Exemplary Connectivity , . ,
FIG. 17 shows exemplary conn^tiyity fpr a dJita ,masking tool.
• IV t J J . . ^ (
Example 20 - Exemplary Web Interface .
FIGS. 18-29 are screen shots of ,,a yveb, interface, for driving a data masking tool and can be used in any of the examples herein.
FIG. 18 shows a login screen. The user can login to the tool using a valid login id and password. Clicking on "Submit" starts,tfie tool.
FIG. 19 shows a screen for creating a source definition. The user provides details about the source text file (e.g., the location, the delimiter used in the file, and the like).
After the information about the rspurcestext is available to the tool, the tool can fetch the metadata from the file (e.g., the number of columns, name of columns, their data type, size or precision, and the like), and displays it'to the usen ■
FIG. 20 shows a screen for editing a-source definition. The user can edit the text file details by clicking on the "Edit" button;' A user can add a new column, delete an existing column, alter the data type and size of the column, and the like.
FIG. 21 shows a screen for adding a n^w column to the source definition. A user can add new columns to the text file. The user can ijse the option when the text file does not have its first row as column names. The user can add column names and give the data type and precision of the column.
Be default, the tool treats the first row of data in the text file as the column names.
FIG. 22 shows a screen for creating the source definition. The user can create the source definition (e.g., metadata about the source text file) by clicking on the "Submit" button.
The tool can display whether the cr^atiop \yas^|tcpessful or a failure on the screen.
FIG. 23 shows a screen for enterinp infcjrmatioi^ for a data masking profile. The user can provide the information about the masking rules that are to be applied to the source data file. The user can select the relevant source definition from the list of source definitions provided by
the tool (e.g., such as one created by a qser using the previous screens).
i
FIG. 24 shows a screen for creating the new data masking profile. The user can give a name to the profile to be created. In order to create the profile, the user can give the masking rule information by clicking on the "Edit" byttojj.
FIG. 25 shows a screen for providing marking information. The tool can display the column details in the source file to the user with an Option of choosing a masking rule from the drop down list.
. . ' , , . ' ' 'v • •
After the user selects the masking rules for the columns, the information can be submitted with the "Submit" button.
FIG. 26 shows a screen by which the profile is created. The user can create the new
i !>y '
profile by clicking on the "Submit" button. .. The tool can display whether the creation was successful or a failure on the screen.
\ v , .,1 . I
"•' ■ i i ' -4 '■■;< i. ■': .1*.'*',' •
FIG. 27 shows a screen for defining an executable data masking task (or "execution"). The tool executes the rules on the Murcefdata fil6, ;and creates a masked data file based on information provided by the usier. 'vf^'1/ '
FIG. 28 shows a screen for creating the executable data masking task. The user creates the task by selecting the profile created and giving the location of the source data file. The user can also give a name to the task for the tool'to save the details in a database for later use.
FIG. 29 shows a screen for running aj task. The user can run the task by submitting the task details. The tool can apply the rules provided in the profile by the user and create a masked
data file. i , s'
i
Example 21 - Exemplary Spreadsheet-based Configuration of Data Masking Tool
FIG. 30 shows an example of spreadsheet-based configuration for the data masking tool. The user can provide the metadata about the source data file in a spreadsheet. A template can be provided into which the user enters appropriate ,data. :.
The tool can read the spreajdsbeets,an<| <^reajf XfylL from it. The tool or a separate tool can read the XML to file the source of th£ data (e.g., real time data or from a text file).
If real time data is indicated, th^n the tool acts on the data using the masking rules provided by the user in the spreadsheet. th^^ourQg is a, text file, then the tool acts on the data in the text file, masking it based on the user information in the spreadsheet.
The tool can easily be extended to any data SQUijpe because the tool can use a spreadsheet to obtain the metadata about the source.
-. ' i.... Vr, , • .. ■ I'M !'■'■■■
Example 22 - Exemplary XML Tag Definitions
The following tags can . be defined when, . representing data masking configuration information in extensible markup language* In any of the examples herein, corresponding data masking configuration information can be^tored and implemented by the data masking tool.






Example 23 - Exemplary Data MqskingRules ..• •
FIGS. 31A-C and FIGS. 32A-B shjaw exiemplatydata masking rules.
Static substitution is shown in FJG/ S-l A," A ^olmnn is replaced with a static values for al the rows in the Name field. For example;all names c&ibe replaced with "ZZZ ZZZZZ."
Dataset substitution is shown in FI£; 31$: A cblumn is replaced with a value from a pre- defined dataset. For example, the names dataset can fce used to replace all the rows in the Name column.
Random substitution is shown in JrlG. 31C. A column is replaced with a random value within a range such that the value is random (e.g., replace a data with a random date between a range).
Encryption is shown in FIG; 32A. The d^ata in a column is encrypted using a secure encryption algorithm (e.g., replace the Name columrt^with an encrypted string).
Shuffling is shown in FIG. 32B. The column values of a dataset are shuffled like a pack of cards (e.g., the column Name is shuffle^ without changing the SSN column).
Example 24 - Exemplary Implementation Custom Transform for Hosting Application , . • FIGS. 33-39 show exemplary screen shots! for, -implementing a custom transform for a hosting application that invokes a,data njaskinjg jool. t :
In the example, a Java custom transform is used in INFORMATICA software. A data masking tool can take advantage v of, the PowerMart and PowerCenter features of INFORMATICA software to allow access to and from a wide variety of data sources and formats.
A package containing a qomponent, (^.g., "pj^a^a-dH" and "pcjava2.jar") can be installed by which the custom transform can be imj^lfn^ept^d^, :
The PowerCenter Designer c^ .be started^ and an external object from the package pcjava.xml can be imported. The. Trapformatipn Developer can be opened, and a new Advanced External Transformation (ATX) can be created as shown in FIG. 33.
The properties can be edited by ddubl^jClicking^he ATX as shown in FIG. 34.
" *.,. "L » ■ ■' i ■. w . . .." • . \ •
The ATX can be renamed to describe the custom transform. The ports section can be left as it is (e.g., empty) for now, and proceed to4he Properties section as shown in FIG. 35. The ATX can be configured as shown, v^ote that if the pmjava2.dll is installed in any other directory than the ExtProc directory of tjte PowerCenter server, the Runtime Location setting must be overridden. The Runtime Location should contain the absolute path to the directory that PCJava is installed. ,\V.,*rrk
Then proceed to the Initialization Properties page as shown in FIG. 36, configuring as shown. .»? ■
The port tab defines input and output ports, as shown in FIG. 37. The changes can be saved to the repository, and the mapping created. A sample mapping is created to read records from a flat file and invoke the custom transformation. The custom transformation can create a flat file from the records and invoke the data masking tool to process the file. After the data masking operation is completed, the records in the masked output file are fed back to the, INFOI^MATICA software, which creates a target file. ,, ,
A sample mapping is shown in JFIG,: 38. "
After the mapping is; stored in, the repository, a reusable workflow component can be created to execute the flow as shown in FIG, 39.
The following operational steps can-be performed:
* The flat file containing the data to b? marked can be placed in the source file directory of the INFORMATICA software
* Each record in the flat file can f^icjced up by.thie INFORMATICA software and passed to the custom transformation component.
* The custom transformation component creates a flat file of all the records and invokes the data masking tool .
* The data masking tool masks the data in the flat file as per the rules specified in its configuration XML and generates £ qutput flat file consisting of the masked data
* The masked data file is further loaded into the INFORMATICA software by the custom transformation. „
* The INFORMATICA software then creates the.target file in the Target directory.
The data masking tool can perform the following: .. • .
* The data masking tool provides masking functionality based on the predefined rules and configurable number of columns specified in the controller XML file.
* A stand alone data mask application can service connections to a socket which obtains the
path to the controller XML file as a message.
■v ■ ' b t ■ - 1 ."■
* The service responds to the requesting application on completion of masking.
* To start the data mask application, a script (e.g., Mask.sh) can be executed, which in turn can run a Java program (e.g., Provider Java).
The custom transform can perform the following:
* The masking custom transform invokes a Java program which uses the PCJava APIs of the INFORMATICA software to create a flat file from the input records and load back the output records back to the INFORMATICA software. '
* The properties set for the custom transform specifies the location of the masking XML file, Input data file and the name of the output dajta file to be created.
* This Java program then connects to tjhe masking application using sockets to mask the records in the flat file created. ' . .
* The custom transformation Java jpropram completes execution after loading the masked records back to the INFORMATICA s^ware. ,;
Example 25 - Exemplary Uses
The technologies described herein can be used in any of a variety of scenarios but are particularly useful in the field of software development, such as in software testing. Data masking as described herein can be applied to prodijction data to generate test data suitable for use in testing environments. , , , f , v
Example 26 - Exemplary Randomization , (
In any of the examples herein, randomization can be achieved via a random number generator that applies a Mersenne Twister random ^umber generation technique. For example, data shuffling can be achieved via such a random number generator. A Mersenne Twister random number generation technique cah,exhibit very high periodicity and other advantages.
Example 27-Exemplary Computing Environment
FIG. 40 illustrates a generalized exarfiple of a suitable computing environment 4000 in which the described techniques can be implemented: The computing environment 4000 is not intended to suggest any limitation as toscope, of use or functionality, as the technologies may be implemented in diverse general-purpose or, special-purpose computing environments. A mainframe environment will be different' from that shown, but can also implement the technologies and can also have computer-readable media, one or more processors, and the like.
With reference to FIG. 40, the computing environment 4000 includes at least one processing unit 4010 and memory 4020: ' In FIG. 4€, this most basic configuration 4030 is included within a dashed line. The processing unit 4010 executes computer-executable instructions and may be a real or a virtual processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory 4020 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or spme combination of the two. The memory 4020 can store software 4080 implementing any of the ^chnologies described herein.
A computing environment may h$vet additional features. For example, the computing environment 4000 includes storage 4040,' one or more input devices 4050, one or more output devices 4060, and one or more; communication connections 4070. An interconnection mechanism (not shown) such as a bus, contrpjler, pr network interconnects the components of the computing environment 4000. Typically, ,op^ratin£ system software (not shown) provides an operating environment for other software executing in the computing environment 4000, and coordinates activities of the components of the computing environment 4000.
The storage 4040 may be rempv^ble pr non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, QP-RWs, DVDs, or any other computer-readable media which can be used to store information and whiph, can be accessed within the computing environment 4000. The storage 4Q40 can store software 4080 containing instructions for any of the technologies described herein.
The input device(s) 4050 may be a touch input.device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing environment 4000. For audjo, the input .device(s) 4050 may be a sound card or similar device that accepts audio input in analog qr digital form, or a CD-ROM reader that provides audio samples to the computing erivironjnent. The output device(s) 4060 may be a display, printer, speaker, CD-writer, or another device that provides output from the computing environment 4000. , , ,
The communication connection(s), 4070 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio/video or other media information, or other data in a modulated data signal. A modulated delta signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communicatiofi media include wired or wireless techniques implemented with an electrical, optical, RF, infrared; acoustic, or other carrier.
Communication media can embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other
• > .. ■ ' 'V' '* ■ t '
v '.-.'.. i. ■ .11 r . -
transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more qf itsi chafacteristics set or changed in such a manner as to encode information in the signal. Communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above can also be included within the scope of computer readable media. ( ; v " > / . '
The techniques herein can be described in tlje general context of computer-executable instructions, such as those included in (prograrp < modules, being executed in a computing environment on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, compoqeqts, data structures, etc., that perform particular tasks or implement particular abstract dat^ types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer- executable instructions for program m6du,les may be executed within a local or distributed computing environment. 3 .
Methods in Computer-Readable Media < ,
Any of the methods described herein can be, implemented by computer-executable
■ ■ ■ ■ ■■■ ■ .-
instructions in one or more computer-readabje fmedj^ (e.g., computer-readable storage media or other tangible media). The tedmologie^; describedijierein can be implemented in a variety of programming languages. vs,, v:
Alternatives
The technologies from any example can be combined with the technologies described in any one or more of the other examples. In view of the many possible embodiments to which the principles of the disclosed technology may be appliecl, it should be recognized that the illustrated embodiments are examples of the disclosed technology and should not be taken as a limitation
• " .r - . . 1''
• * ■ , :> •.■«...
on the scope of the disclosed technology. Rather, the scope of the disclosed technology includes what is covered by the following claims. We therefore claim as our invention all that comes within the scope and spirit of these claims.

We claim:
1. A data masking tool encoded on one or more computer readable storage media, the data masking tool comprising:
a masking rule engine configured to apply a plurality of masking rules to source data, the masking rules comprising static substitution rules, dataset substitution rules, random substitution rules, shuffling rules, and encryption rules; and
an application programming interface configured to receive a command to perform data masking on the source data as indicated by specified masking configuration data, wherein the application programming interface is configured to receive an indication of the specified masking configuration data;
wherein the masking configuration data comprises an indication of which of the plurality of masking rules are to be applied to the source data; and
wherein the data masking tool is configured to apply the masking rule engine to the source data and generate masked data as indicated by the masking configuration data.
2. The data masking tool of claim 1 wherein:
the data masking tool is configured to output masking configuration data as extensible markup language (XML); and
the data masking tool is configured to" input masking configuration data as XML.
3. The data masking tool of claim 1 wherein:
the data masking tool is configured to connect- to a metadata management tool, receive metadata regarding the source data from the metadata management tool, and
store the metadata regarding the source data as data masking configuration information.
4. The data masking tool of claim 1 wherein:
the data masking tool is configured to be executed from a web-driven user interface, a command line, a service oriented architecture end point and a hosting application.
5. The data masking tool of claim 1 wherein:
the data masking tool is configured, to accept* source data in the form of a flat file; and
the data masking tool is configured to accept source data in the form of a database.
6. The data masking tool of claim ! wherein:'
the data masking tool is configured to. accept source data from a plurality of different technology platform types. ^; ^
7. The data masking tool of claim 1 where in
the data masking tool is configured to accept source data in the form of a flat file;
the data masking tool is configured to determine from the flat file, the column names of a table represented in the flat file; and ' ; < 1 r
the data masking tool presents columns for the table represented in the flat file with the column names in a user interface by which a user can select data masking rules for respective of the presented columns.
8. The data masking tool of claim 1 wherein the application programming interface is configured to receive a location of ^ masking' i configuration file containing the masking configuration data. "V;"'
9. The data masking fool of claim 1 wherein the application programming interface is configured to receive a location of the source data. <
10. The data masking tool of claim 1 Wherein the data masking tool is configured to be invoked by a custom transformation in a host application.
11. The data masking tool of claim 10 wherein the source data resides on a mainframe computer system. ■.
12. The data masking tool of claim; 10 wherein the host application serves as a broker between the data masking tool and a mainframe 'computer system.
13. The data masking tool of claim 10 wherein the host application serves as a broker
between the data masking tool and a database. ' ' •-'•
14. The data masking tool of claim 1 wherein:
the masking rule engine is conffgibred to shuffle- records via a Mersenne Twister random number generation technique. ■ > ■r .-r •;■•.,.
15. A method of masking •
receiving a call to an application programming interface configured to receive a command to perform data masking on the source data as indicated by specified masking configuration data, wherein the application programming interface is configured to receive an indication of the specified masking configuration data,.and wherein the masking configuration data comprises an indication of which of the plurality of masking rules are to be applied to the source data;
responsive to receiving the call to > the application programming interface, reading the specified masking configuration data and applying a masking rule engine to the source data, wherein the masking rule engine is configured to apply a plurality of masking rules to source data, the masking rules comprising-' substitution rules, random
substitution rules, shuffling rules, and encryption rules;and
outputting masked data via .the masking rule engine as indicated by rules in masking configuration data.
16. One or more computer-readable media comprising computer-executable instructions causing a computer to perform the method of claim 15.
17. A method of obtaining data masking configuration data for source data, the
method comprising:
connecting to a metadata management too storing metadata for the source data;
receiving from the metadata management tool, metadata regarding the source data;
storing the metadata regarding the source data as data masking configuration information;
performing data masking via the data masking configuration information.
18. The method of claim 17 wherein the metadata is received in the form of extensible markup language (XML).
19. The method of claim 17 wherein the metadata comprises column names for one or more tables in the source data.
20. The method of claim. 17 wherein the metadata comprises a data type for one or more columns in one or more tables in the source data.