Patent Application
20140351943
The present invention relates to a system and method for anonymising data and in particular for selectively anonymising data in a configurable way.
Many businesses are faced with an apparent conflict between the need to respect their clear obligation to protect the security and privacy of their customers in their use of data, and a business imperative to maximise revenue opportunity by either exploiting or enriching the data. These opportunities increasingly involve exposing data to partners and third parties and the movement of data outside the protected network of the business. Protecting the data while still retaining sufficient usable data to enable the opportunity is a key challenge. In addition, in this increasingly global economy, data crosses borders increasingly and organisations need to ensure that they continue to comply with all the relevant regulatory requirements.
The ability to share data between repositories is an essential requirement for many businesses. Sharing data between repositories can become problematic when the data being shared is at least in part confidential, secret or otherwise sensitive.
There are many examples of systems which are arranged to securely share data between repositories, including systems for securing the repositories themselves, and securing the communication channels between repositories.
An additional problem arises when the source repository wishes to only share part of a data set with a destination repository.
Therefore, there is required a system and method that overcomes these problems.
The present invention relates to a system for anonymising and filtering data sets which are leaving a data repository within a secure environment to another environment that may or may not be secure, and a system for de-anonymising the data sets as they are returned back to the secure data repository.
The present invention provides a system and a method of transforming data in real-time, or near real-time from the original data set to an at least partially anonymised, filtered and masked data set suitable for transmission to a third party outside of a secure environment. The invention has the important additional feature of being able to receive an at least partially anonymised data set that has previously been transmitted outside of the secure environment and deanonymise the previously anonymised data, for storing the deanonymised data back in the source repository, or other location within the secure environment. The returning data set does not have to be identical to the original data set, provided that at least one identifier data item remains unaltered. This allows third parties to add to alter or in other ways enrich the transmitted data set prior to returning the data set to the secure environment. Additionally, the present invention provides the capability, using easily modified configuration data, to transform multiple data sets, of differing structure and apply different transformation techniques (for example anonymisation, masking, filtering) to each according to their type.
An anonymisation system and method filters, anonymises and/or otherwise transforms sensitive data before it is sent onwards, for example to an external third party. Furthermore, the anonymisation system is being able to also de-anonymise data as it is sent back to the originating party after analysis or enrichment.
The anonymisation system supports a number of interfaces to route data and can apply a variety of transform and data quality rules to the data.
According to a first aspect there is provided a method of anonymising data comprising the steps of:
Therefore, data may be safely and securely released to third parties as personal, private or other sensitive data may be anonymised, tokenised or protected first and then recovered and processed on return from the third party. For example, this may allow external processing of data to take place outside of a secure boundary or organisation. Upon return, additional information may be utilised as the sensitive and identifying information may be recovered by the originating party so that the external processing and any additional data may be used. The original data may be data that can be used to identify users or their personal information (e.g. telephone number, name, address, date of birth, etc.) The transformation configuration resource may be configurable, customisable or specific to particular received data types and data structures/formats, for example. The stored information may be configuration information, for example.
Advantageously, this provides a faster, in-line, real-time, highly configurable and reversible method of anonymising data.
The method advantageously may consistently anonymised data to the same value when required. This provides referential integrity with data.
The original portion may be replaced with a token as the transformed portion. A token may be a representation or a reference to the original portion in anonymised form so that the original portion may not be inferred or generated from the token without additional information. A token store may be a repository or database of tokens. Tokens that have been used or are in use may be associated with the original data or portion or linked to these in other ways. A lookup or call may be made to the token store to determine the original portion or data that it represents. Access to the token store may be restricted or secured to prevent unauthorised interpretation of the transformed (tokenised) portion.
The transformation configuration resource may be configurable. This makes the method and system easier to update when new or amended data types and structures/formats are received.
Optionally, the stored information may comprise the transformed portion stored with the original portion of received data. For example, the transformed or tokenised portion may have the transformed data stored together with the original portion in a database or token store.
Optionally, the stored information may be cryptographic material for decrypting the transformed portion into the original portion of received data. The transformed data may be an encrypted form of the original data. Therefore, the original data may be recovered by a decryption procedure involving a stored key or other cryptographic material.
Optionally, the stored information may be replaced by a unique, alternative value called a token. The token is stored typically in a database and may be re-used to recover the original value upon return.
Preferably, the transformation configuration resource defines the transformation to be applied. This may be a configuration file or database or repository describing how to transform the original data and other options and procedures that may be carried out, for example.
Optionally, an anonymisation configuration resource may define how the received data provides an output containing the transformed portion, the method further comprising the step of operating or processing according to the anonymisation configuration resource to produce an output. Therefore, a workflow may be pre-defined for the particular received data (i.e. preconfigured for different data types and formats).
Preferably, the anonymisation configuration resource may define any one or more of: an interface for providing the received data; how the received data is read; the transformation configuration resource; an output format; the source of the received data; the destination of the output; and a maximum number of processing threads. The anonymisation configuration resource may define other parameters and procedures to be carried out.
Optionally, the received data may be in a data format defined by a data description configuration resource. Therefore, the received data may be read according to the data description configuration resource. The data description configuration resource may for example, describe where in the received data any or all data items may be located including those data items or portions that are to be transformed.
Optionally the method may further comprise the step of generating an output comprising the transformed portion with or without an untransformed portion of the received data. In other words, an output may be generated from the received data with the original data replaced by the transformed data but with other fields or data in their original form.
Preferably, the output may be formatted according to an output configuration resource. This may include details of an interface used to describe the required output and/or the form of the output file, data, stream or database table.
Optionally, the method may further comprise the steps of:
receiving an input comprising the transformed portion and a new portion; and
using the stored information to recover the original portion from the transformed portion. In other words, these steps describe the receipt of previously transformed data once further processing has been carried out to create or modify data preferably associated or derived from the original data. Upon receipt, the original or identifying portion or portions of the data may be recovered so that the data is deanonymised.
Optionally, the transformation may be encryption.
Preferably, the encryption may be selected from the group consisting of: format preserving encryption; and ephemeral encryption. Other encryption types may be used. Format preserving encryption may allow correct processing of the transformed data. Ephemeral encryption may be used to create different outputs each time for the same input. This can help to prevent third parties who receive the transformed data, from building up user profiles or user specific information. For example, even though they cannot identify the actual user, they may be able to associate multiple items of received data with the same user if the transformation (or token) is identical for each item. Such analysis may be frustrated by using ephemeral encryption.
Optionally, the method may further comprise applying transformations to further original portions of the received data, the further transformations selected from the group consisting of: hashing; redacting; filtering; find and replacing; replacement with random values; validation; and masking. Therefore, the transformed data may contain data fields transformed in different ways. These transformations may be preconfigured or based on the type of the original data, for example.
Preferably, any one or more of the configuration resources may be encrypted. For example, any or all of the transformation configuration resource, the anonymisation configuration resource, the data description configuration resource, the output configuration resource, an input configuration resource, or an interface configuration resource may be encrypted to increase security.
Optionally, the received data may be selected from one or more of the group consisting of: XML; delimited; fixed width; YAML; SOAP; SMOPP; and UCP/EMI. Other data types may be used.
According to a second aspect there is provided an anonymisation system comprising:
Preferably, the interface is further configured to transmit the transformed portion or the transformed portion together with unchanged for untransformed portions of the received data outside of the anonymisation system.
The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium.
The methods described above may be implemented as a complete anonymisation system.
It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention.
The present invention may be put into practice in a number of ways and embodiments will now be described by way of example only and with reference to the accompanying drawings, in which:
It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale.
Example—Source Repository being a Mobile Network Operator. A customer data set for a mobile network customer is stored on a CDR Repository within a secure environment. The customer data set comprises sensitive data items, as shown in use case of
The third party then performs processing on the anonymised data set and adds at least one item of data enrichment to the data set. This data enrichment item can be any additional data which is dependant on at least one data item from the anonymised data set. For example the cell-ID, which in use case 19 has not been anonymised, could be used by the third party as an approximate location identifier for the customer. Using this location identifier the third party adds a contextual text message data item to the data set.
The enriched or amended anonymised data set is then transmitted back to the secure environment. The de-anonymisation system then reads the incoming data set, de-anonymises the anonymised data set.
The de-anonymised data set and the contextual text message is transmitted within the secure environment to an SMSC (Short Message Service Center) which uses the de-anonymised data to send the contextual text message to the customer via SMS (Short Message Service).
In the above example, the third party was provided with enough information to allow them to send a targeted message based on location to a customer without having any direct access to the customer, and importantly, without any private and personal information about the customer being transmitted outside of the secure environment. By de-anonymising the sensitive data items when the anonymised data set is returned to the secure environment, the enriched data set can be associated back to the customer and the enriched data can be utilised.
Configuration files used to configure which data items should be anonymised, filtered and/or masked, and the configuration files defining the layout of the transformed data set can be variable. The inbound transformations need not be the same as the outbound transformation.
The described invention is a configurable approach to addressing data security (for example, by anonymising outgoing data) and data privacy (for example, by masking and/or filtering outgoing data).
An example anonymisation system 10 consists of three logical layers:
File system
HTTP/HTTPS
TCP/IP
Database
Messaging
Data Readers/Writers—This layer is responsible for parsing a variety of data formats, transforming individual data fields by using the transforms within the Transform Engine, and repackaging the result into the same output format for onward transmission. The supported data formats are:
Delimited
Fixed Width
XML
HTML
YAML
SMPP
UCP
HTTP
SOAP
Transform Engine—This is responsible for transforming individual data fields in a variety of ways, in order to anonymise and de-anonymise them. The supported transforms are as follows:
Filtering
Masking
Ephemeral Encryption/Decryption
Format Preserving Encryption/Decryption *
Hashing *
Find and Replace
Redaction
Validation
Random Number Generation *
Detokenisation *
* Starred transforms are “tokenisable transforms”, which means tokenisation can be turned on for them. Tokenising is explained in detail later in the description. The detokenisation transform is used to reverse tokenisable transforms.
The following is a summary of the method carried out by the anonymisation system 10:
The anonymisation system 10 ingests data from an interface;
The data is interpreted into records/fields by a reader/writer;
Fields may be modified by one or more transforms defined in a transformset or transformation configuration resource;
The transformed data is returned into its original or similar format by a reader/writer; and
The anonymisation system 10 transmits the data to its destination via an interface.
A number of transforms which have complex properties, including encryption, are defined via “Transform Schemas”. These schemas allow a complex transform to be specified once and then consistently used, possibly many times.
For example, a schema to encrypt a common field, e.g. MSISDN could be used consistently across a number of routes and interfaces to allow consistent encryption and decryption.
A glossary is provided, which explains the technical terms used by this description.
The anonymisation system 10 is preferably multithreaded and can perform many of these actions, at high speed, concurrently.
The anonymisation system 10 is stateless and maintains no history or status of activities performed or in progress. Furthermore, with the exception of tokenisation, it does not store any data. Therefore transactions are atomic. Once an action is complete, the system disregards the action and commences a new one. Should the anonymisation system 10 be interrupted, for example by system failure, then on restart (or by another resilient instance), the entire transaction would need to be repeated. If the system fails while processing data on a file based interface, the file data would remain on the server in an unprocessed state, allowing a system administrator to attempt to reprocess the data later. When using a TCP/IP interface, if the system fails the TCP/IP connection will be terminated and no further data will be processed. Data could then be sent through the system again once it has been restarted.
Variations in format and protocol between input and output may be made. For example, this may include reading from a database and writing to a file.
In one implementation, the anonymisation system 10 is a Java application which can be run on any operating system with a Java Virtual Machine (JVM). The minimum suggested version of Java is 1.6. For production environments, the following Operating Systems are recommended:
Redhat Enterprise Linux 5; and
Debian Squeeze
Example suitable versions are:
Linux RHEL version 5.x
Debian Squeeze version 6
Java JRE Version 1.6
Tomcat Version 7
Jpam (if using the GUI) Version 1.1
Other environments may be used.
An example execution of the anonymisation system 10 may be as follows:
Navigate to the “input” directory and open the “input.csv” file using a text editor. Example input to the system may be as follows:
12345678,Test,447777123456
To inspect the input data to the system and rename the input.csv file to “input.csv.ready”. The system picks it up, processes it and writes the output to a new file in an output directory. As shown in this example below, the first field has been masked, the second filtered and the third partially encrypted, i.e.:
“12****78”,“ ”,“448555422322”
Data Interfaces, Data Readers/Writers and Transform Engine provide a flexible framework to receive, transform and output any type of data. These may be configured via a configuration file in XML format. The format for each component within the configuration file is described below.
Configuration files are preferably stored securely in an encrypted and digitally signed form
XML Configuration Format
The data flow through the application may be defined in XML. The high level structure recommended for the XML file is as follows:
Interfaces
Reader/Writers
Transform Sets
Routes
A “Route” defines a data flow or an anonymisation procedure through the system, linking together a Data Interface, a Data Reader/Writer and the relevant set of transforms. The route or anonymisation procedure may be defined by a configurable anonymisation procedure resource. An example configurable anonymisation procedure resource is shown below in XML format:
Failed Routes
If a failure occurs on an interface which means the route either cannot start correctly, or continue to run, it will be moved to a pool of failed routes. A RouteManager thread runs in the background all the time that the anonymisation system 10 is running, and periodically attempts to restart the failed routes. By default, this period is set to every 30 seconds, but this is configurable.
If a route is successfully restarted, it will be removed from the failed routes pool. If a route fails to restart, it will remain in the failed routes pool until the next time the Route Manager attempts to start the failed routes.
Interface types may be defined in the configuration file and loaded when the anonymisation system 10 is started. New interfaces can be defined using product Extension API.
File Based The anonymisation system 10 will read data files from a configurable input directory. Transformed files are written back out to an output directory.
HTTP(S) The anonymisation system 10 listens for HTTP messages on a configurable address. It then forwards transformed messages to an output port.
TCP/IP The anonymisation system 10 can listen for any generic communications over a TCP/IP socket.
Database The anonymisation system 10 can read raw data from a database table and write back to another table.
Messaging The anonymisation system 10 can process messages from a JMS queue and put the result back on another queue or topic.
Every interface may have two generic configuration parameters:
filesystem
For example:
File System Interface
The file system interface has the following properties available for configuration.
Example Configuration File Section
The following is an example of the section of XML required to define the file system interface.
This interface will poll every 20 seconds for files in the “/Data/in” directory (relative paths from the location where the anonymisation system 10 was started are allowed, but it is recommended that absolute paths be used to avoid confusion). The interface will pick up any files with the “.xml” suffix, and the resulting output files in “/Data/out” will end with .xml.pickup (since the input suffix is not being removed).
If multiple files with the same file name are inserted into the input directory for processing by the anonymisation system 10 (for example, a second file is inserted after the first file has been processed) there may be collisions when The anonymisation system 10 attempts to rename files.
In order to avoid this, the anonymisation system 10 may attempt to identify filenames that have previously been processed and for which the processed files are still present in the input or output directories.
A unique file name may be assigned to the input file which does not clash with any of the processing or processed files in the input and output directories. Where a collision is found, a number will be appended onto the end of the base file name. For example:
Files appearing in the input directory are created by virtue of an “atomic operation” when ready. This means that a partially written file cannot be picked up by the system.
Error Handling
If an I/O error occurs on the interface (reading and writing files to disk) the route may fail and be moved to the failed routes pool.
HTTP/HTTPS Interface
The HTTP(S) interface listens on a TCP/IP connection for HTTP or HTTPS protocol requests on a configured address. The content portion of the request is considered the data which is interpreted by the Data Readers and transformed accordingly. The interface has the following configurable properties:
For HTTPS, appropriate certificates may be installed in the Java HTTPS keystore.
The following is an example of the section of XML required to define the HTTPS interface.
TCP/IP Interface
The TCP/IP interface listens on a configured address for TCP/IP connections. Once connected, data can be passed and transformed in either direction on the socket. The raw data arriving is passed directly to the Data Reader/Writer for transformation. The interface has the following configurable properties:
When a connection is established on the specified incoming port, a new Socket will be opened, a new connection will be established to the outgoing address and the corresponding input and output data streams for both directions will be passed down to the Data Reader/Writers. The application will then continue to listen on the specified port. A Reader/Writer of the same data type will be created in each direction. Transforms can be configured to act in either direction.
The following is an example of the section of XML required to define the TCP/IP interface.
In this case, this interface will listen on port 9201 and make a connection to port 8080 on IP address 1.2.3.4. “localhost” may be used for the outgoing hostname if the destination application is hosted on the same server as The anonymisation system 10.
Database Interface
The database interface reads raw data from a database table and inserts transformed data into another table. The input database table must consist of a primary key column and a data column. The interface has the following configurable properties:
outputDBName: The name of the output database schema.
The database interface will read all rows in the input table, passing the data from the data column to the reader writer layer for each row. Once the data has been successfully transformed, the transformed data will be written to the output database and the original row from the input database will be deleted.
The following is an example of the section of XML required to define a database interface:
Error handling
If a database connectivity issue occurs, the route may fail and be moved to the failed routes pool (see
Messaging Interface The message interface is used for reading messages from a JMS queue and writing them to another queue or topic.
The configuration parameters are:
An example XML configuration section for the Messaging Interface is as follows:
Reader and Writer Configuration
The data reader/writer configuration consists of a specified data type and a set of fields which are available to be transformed. A field represents a particular piece of information in a specified location in the incoming data stream. For example, if the data type is HTML, a field could be a particular element, defined by its XPath location. The configuration to define where a field is located in the input data is called the “Field Definition”. The format of this parameter is described for each reader in this section. The supported data types are listed below.
Every reader writer has two generic configuration parameters:
The rest of this section describes the specific configurable properties for each reader/writer.
Delimited Reader
The delimited reader will read a stream of delimited data, split it into individual rows and fields, pass fields to the configured transforms and repackage the resulting delimited data stream. The configurable properties for the delimited reader are as follows:
The “Field Definition” for delimited data is the 0-based index which corresponds to the field in the incoming data. Optionally, the fields may be reordered, in which case the field definition should be a comma separated pair of the initial index and the desired output index.
An example of the XML section to configure the delimited reader is as follows:
Fixed Width Reader
The Fixed Width Reader is responsible for reading lines of fixed width data. The configurable properties for the fixed width reader are:
The Field Definition for Fixed Width data is a comma separated pair of their start position within the line (0 based) and the length of the field. Only the fields that are to be transformed need to be specified, the reader will copy all unspecified fields untransformed.
An example of the XML section to configure the fixed width reader is as follows:
If fixedFormat is specified, and the transformed length is less than the length of the original field, the transformed field will be padded with spaces.
If fixedFormat is specified, and the transformed length is greater than the length of the original field, an error will be thrown.
If fixedFormat is set to false, the output will be a concatenation of all the fields after they have been transformed.
XML
An XML reader is responsible for reading XML data and extracting fields to transform based on XPath expressions. XPath can be used to define specific elements or attributes to be transformed, these are collectively known as nodes. A configurable property for the XML reader is:
Fields are configured by an XPath expression. All nodes matching the expression belong to the same field. The text content of the node is the field value which will be transformed.
An example of the XML configuration for the XML reader is as follows (See section 2.9 for a full configuration file example):
For example, the following HTML data could be used as input to this reader:
In this case, the values “Title”, “Author”, “Description” would be picked up for transformation by the fields “title”, “author”, “description” in the configuration file. For example, if the destination system is dependent on the value of a specific element, the transform should not be configured to set the value of this element to an invalid value.
HTML
An HTML reader is responsible for reading HTML data and extracting fields to transform based on XPath expressions. The configurable property for the HTML reader is:
Fields are configured by an XPath expression. All nodes matching the expression belong to the same field. The text content of the node is the field value which will be transformed. An example of the XML configuration for the HTML reader is as follows:
For example, the following HTML data could be used as input to this reader:
In this case, the values “Heading 1”, “Heading 2”, “Heading 3” would be picked up for transformation by the fields “field1”, “field2”, “field3” in the configuration file.
SOAP
The SOAP reader is responsible for reading SOAP data and extracting fields to transform based on XPath expressions. XPath can be used to define specific elements or attributes to be transformed; these are collectively known as nodes. The configurable property for the SOAP reader is:
Fields are configured by an XPath expression. All nodes matching the expression belong to the same field. The text content of the node is the field value which will be transformed.
An example of the XML configuration for the SOAP reader is as follows:
HTTP
The HTTP reader/writer is responsible for extracting and transforming data from within an HTTP request body, and extracting and transforming HTML elements using XPath in the HTTP response. There are no configurable properties for the HTTP reader.
An example XML configuration for the HTTP reader is as follows:
This data reader/writer is effectively a composite reader which processes HTTP request data on the outbound path, and delegates to the HTML reader to transform HTML data on the HTTP response. The field definition consists of the name of the field in the case of a request, and an XPath expression in the case of the response. In order to define which direction a transform is applicable to, a property <direction> must be set within the transform configuration. This value must be set to either OUTBOUND or INBOUND, for request and response respectively.
The following is an example of the transform set configuration for use with the reader definition above
YAML
The YAML reader is responsible for extracting and transforming data from a YAML data stream. There are no configurable properties for the YAML reader.
An example XML configuration for the YAML reader is as follows:
Object-Graph Navigation Language (OGNL) is used as the expression language to choose fields of data from a YAML object map.
It is possible to specify a particular field in a list using square brackets e.g. items[1].descrip. This would correspond to the descrip field of the object at index 1 (zero-based) in the items list. If the specified indexed item does not exist then a warning will be logged to state that the system was unable to transform this field definition as it does not exist and the application would continue.
SMPP Protocol
SMPP Protocol v3.4 messages can be accepted as a data type as per the specification [5]. This includes long SMS messages. The following messages are available for transformation:
In these messages only the following fields are available for transformation (where available):
All other messages will be sent through the filter unaffected.
An example SMPP reader configuration XML fragment is as follows:
Fields are configured by a slash separated pair of message type and field name, both according to the SMPP specification.
UCP Reader
The UCP Reader will read messages according to the UCP-EMI specification v4.3c [6]. The following Message Types are supported:
All other Message Types will pass through the filter unaffected.
The following fields are available for transform in the outgoing message and response:
There are no configurable properties for the UCP reader.
An example XML configuration fragment for the UCP Reader is as follows:
Fields to transform are configured by a slash separated list of message type, message operation and field name. Message type must be one of CallInputOperation or SMTAlert. Please see the UCP specification [6] for details of each message type. Message direction must be either Operation or Result and field name must be either adc or oadc.
Transform Configuration
Transforms are configured in the XML file by mapping specific fields (defined by the reader/writers) to a transform type, and specifying any required properties for the transform. Multiple transforms can be applied to a single field.
The available transforms are described in the following table, and this section details the functionality and configuration parameters for each transform. Some transforms are “tokenisable”, meaning that the generated values will be stored against the input values in a token store, for future lookup. See below in table 2 for more information on tokenisation.
Tokenisation
Tokenisation enables the output of certain transforms to be stored in a token store along with the input value which generated them. In other words, transformed fields are recoverable. The token value may be derivable from the input or original value (e.g. by an encryption or other function) or may be unconnected. The tokenisation process follows these steps:
The anonymisation system 10 application comes with a Database token store. The transforms that support tokenisation are:
To reverse the tokenisation process, a detokenisation transform can be used. This is effectively a tokenisable transform which doesn't have an implementation of how to transform data, and assumes that the token is present for every value received.
Transform Configuration Format
Transforms are configured as entries in a transform set, which is defined in XML using the <transformSet> tag. A transformSet is defined by the following configuration parameter:
The following is an example configuration of a transform set:
The following configuration parameters may be present for every transform:
Additionally, the following two properties are optional for every transform:
The rest of this section defines the configurable properties for each transform type. Some of the properties may refer to transform schemas, which are more complicated sections of XML, rather than just a plain value. The use of properties to refer to schemas is documented specifically for each transform type. See the full configuration file at the end of the section for a full example.
Filter Transform
The filter transform removes a field from the data. This may mean removing the field entirely, or just removing the field's value, depending on the data type. Example behaviour is defined in the following paragraph.
The exact process for filtering is dependent on the specific data reader/writer, as follows:
Note: This transform is one way and not reversible. A filtered value cannot be reinstated.
An example of the XML required to configure the filter transform is as follows:
Masking Transform
This transform replaces a subset of characters within a field with a specified character.
The configurable properties available for the masking transform are:
For example, if character=*, Anchor=START, Offset=2 and numberMasked=4:
An example of the XML required to configure this transform is as follows:
This example will mask the 3rd—6th characters in the input (if present) with a series of * characters.
Encryption and Decryption
The encryption transform will encrypt the data using a defined encryption schema. The available encryption schemas are loaded at system start up from configuration. Encryption keys to be used by these transforms need to be added to the application keystore using the Configuration Management Utility. Without a valid encryption key defined in the application keystore, these transforms cannot be used.
Two example types of encryption are described:
“12345” could encrypt to “X13f9s3gGsGh25DB” on the first attempt and “IR3d2xSggs9DssH3” on the second time. Both of these values would decrypt to “12345”.
“12345” could encrypt to “98627”. “67890” could encrypt to “46602”. Then “98627” would decrypt back to “12345” and “46602” would decrypt to “67890”.
Optionally, only a substring can be encrypted using an anchor/offset mechanism in a similar way to the masking transform
An encryption schema may be specified in the XML configuration file in order for an encryption or decryption transform to be configured.
An encryption schema is defined by the following parameters:
anchor (Format preserving only)—Used to define a substring to encrypt. Whether to work from the beginning or end of the input value when applying the offset and encryptionLength properties. If specified, must be START or END. Defaults to START
Examples of configuration for both types of schema are as follows:
In the above Format Preserving Encryption example, characters 3-22 will be encrypted (if present).
Transform Configuration
The encryption and decryption transforms are configured by the following property:
Example Transform Configuration
An example of the XML configuration for encryption and decryption transforms are as follows:
Hashing Transform
The hashing transform uses an algorithm with a secret key to create a hash of the supplied value. The secret key may be kept in the application key store and referred to in the same way as an encryption key. This key needs to be added to the application keystore using a Configuration Management Utility in the same way as encryption keys. Without a valid key defined in the application keystore, this transform cannot be used.
The configuration parameters for the hashing transform are:
An example configuration XML segment for the hashing transform is as follows:
Find and Replace Transform
The Find and Replace Transform will replace any instances of defined strings within a field with another value. The value to find may optionally be a regular expression. The configuration parameters for the find and replace transform are as follows:
Find and Replace Schema Definition
A Find and Replace schema is defined by a name and a list of pairs of find and replace values. Each entry may have the following configuration parameters:
An example find and replace schema is as follows:
Example Transform Configuration
An example for the configuration of a find and replace transform using a defined schema is as follows:
The list of values to find and replace are applied in the order defined in the configuration file, the output of each being used as the input of the next.
Redaction Transform
The Redaction Transform will remove any instances of defined strings. No padding with spaces or replacing with “black blocks” will be performed. If any form of padding is required, the Find and Replace transform can be used, setting the replace value to a string of spaces or another appropriate character. The configuration parameters for the redaction transform are as follows:
Redaction Schema Definition
A Redaction schema is defined by a name and a list of values to remove. Each entry may have the following configuration parameter:
An example redaction schema is as follows:
Example Transform Configuration
An example for the configuration of a redaction transform using a defined schema is as follows:
Random Number Generation Transform
The Random Number Generation Transform takes a String value as input and returns a random number generated using the a randomising algorithm between specified upper and lower bounds. The application's built in secure random number generator will be used to generate the random numbers. Note that this transform is not dependent on the input value and is intended for use only with tokenisation enabled. The following configuration parameters are available for this transform:
An example configuration XML segment for this transform is as follows:
Validation Transform
The validation transform checks the input value against a regular expression. If it matches the value will pass through the transform unchanged. If it doesn't match it can either be removed, replaced with another value, or pass through anyway (with a warning logged). The action to perform on validation failure is defined by the configuration parameters. The configuration parameters for this transform are as follows:
regularExpression—the regular expression to check the input value against
actionOnFailure—the action to take if validation is unsuccessful. Must be one of:
DONOTHING—the value will pass through the transform anyway
FILTER—the value will be filtered (using the same rules as the filter transform)
REPLACE—the value will be replaced by the value defined in the “replacementValue” property
replacementValue—the value to be used as a replacement, if the actionOnFailure parameter is set to REPLACE
logWarningFlag—whether a warning message should be logged when a field fails validation. Defaults to false
An example of the XML configuration required for this transform is as follows:
Detokenisation Transform
The detokenisation transform is used to look up previously defined values in a token store. It is intended to be used as the reverse of one of the other tokenisable transforms (encryption, hashing, random number generation) with tokenisation enabled. It does not have any functionality as a standalone transform. The only configuration parameter is:
An example of the configuration for this transform is as follows:
Tokenisable Transform Configuration
Any transform for which tokenisation is available (encryption, hashing, random number generation) must specify a tokenisation schema to use. This schema specifies the type of tokenisation and the configuration parameters for that specific type of tokenisation. The anonymisation system 10 comes with database tokenisation built in, and provides a Java API for a custom token store to be written.
The existence of the tokenisation database is a prerequisite when turning on tokenisation for any tokenisable transform.
If tokenisation is enabled on a transform, the token store may be checked every time the transform is invoked using the following process:
A tokenisation schema is specified by a name, the type of tokenisation and a list of tokenisation properties, specific to the type of tokenisation being used. This section describes how to use the built in database token store.
To use the built in database token store, a database table may be used, which has two String based columns (e.g. VARCHAR), each of which must have unique constraints. There may be other columns in the table, but they must all have default values.
Tokenisation configuration parameters for the database token store may be:
An example of the XML required to configure a tokenisation schema is as follows:
Please note. It may be desirable to populate the token store manually before starting the anonymisation system 10, for example so the tokens do not have to be generated but are already present when the system is started.
Validation Rules and Standardisation
Standardisation and simple format fixing can be achieved by using a combination of validation, find and replace and redaction transforms. For example, the following specific fields could be standardised as follows:
MSISDN
IMEI
ICCID
IMSI
IP Address
IPV4: nnn.nnn.nnn.nnn
IPV6: hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh
IPV6: hhhh-hhhh-hhhh-hhhh-hhhh-hhhh-hhhh-hhhh
A Redaction transform to remove whitespace
Route Configuration
How the data flows through the system may be configured (i.e. workflows). These are known as routes, and are configured preferably in the XML file using the following parameters:
File Interface—The number of threads which can process files concurrently
HTTP—The maximum number of HTTP requests which can be processed simultaneously. Optimally, this should be set to the maximum number of expected concurrent requests.
TCP/IP—The number of threads which can process data from TCP/IP connections at once. Note that one thread per TCP/IP connection will be used, so this should be set to the maximum number of expected connections via this interface.
Messaging—The number of threads which will concurrently listen to the input queue.
Database—The number of threads which can process database data at once.
The following is an example of the XML configuration required for a Route:
Example Configuration File
The following is an example of a complete configuration file, specifying the following components:
Format preserving encryption, encrypting up to 20 characters from an offset of 2 from the beginning, using the alphabet 0123456789
Filter—the second field is removed
Mask, masking up to 4 characters with a #, with an offset of 2 from the start
It is possible to split the configuration across multiple configuration files, for example all interfaces could be defined in one file, all readers in another, and so on. Alternatively, all components related to each route could be defined in separate files.
Please note that the reference to URLs at the top of the configuration file is specifying various XML namespaces required by some of the application libraries. No internet connection is required to run the anonymisation system 10.
Graphical User Interface
A GUI (graphical user interface) application provides a facility to edit and manipulate commonly changed features of any of the described configuration files. These include the list of transforms in use by a particular route, the properties of those transforms and the schemas that they need to function correctly.
Typical Use Case
This section outlines an example use case for the GUI. These are the steps required to modify and save changes to a configuration file:
The anonymisation system 10 application groups transform together into Transform Sets based on the list of transforms defined within each <transformSet> element in the configuration file. These are ordered lists of transforms which are applied, as a whole, to routes. Each route will have exactly one Transform Set applied to it; however a single Transform Set may be used by several different routes. This relationship is defined in each configuration file.
The default naming scheme will be the transform type followed by its position in the transform set relative to other transforms of the same type. For example in a transform set containing the following transforms (in order):
The generated names would be
These names can be edited by the user using the Edit Transform feature.
Changing the Order of Transforms
A transform may have its position changed, relative to other transforms in a set.
Schemas
Most transform types may be simple and have a basic set of properties that can be edited, however some have a more complicated structure which require the use of a “Schema” to define their properties. For example, the Find and Replace transform maintains a list of things to look for and what to replace each item with. This list can get quite long so it makes sense to group it together into a Schema which can then be shared by several instances of the same transform.
Several Schemas may be defined within a configuration file, each applicable to different types of transform and each of these schemas may be editable by the GUI application.
Extension API
Overview
This section explains the API, which may be used to implement new modules for in the anonymisation system 10. The module types which can be created are:
Creating new modules involves writing a Java class in a package com.detica.*, adding a DDSFModule annotation to the class and updating the anonymisation system 10 configuration file appropriately. For the system to be able to use the new module(s), the Java classes should be compiled into a JAR and included on the Java classpath when starting the anonymisation system 10. Here is a simple example, applicable for Data Interfaces, Reader/Writers and Transforms.
Class Structure for Extensions
The DDSFComponent interface is a root level class for all system components and defines the following two methods:
void initialise( )—This method has the purpose of validating properties and initialising any external resources required by a component, for example database connections.
void clean( )—This method has the purpose of clearing down any external resources which were started up in the initialise method, for example closing down a database connection created in the initialise( ) method.
Every component should preferably implement these methods. Where a superclass already defines these methods, the call “super.initialise( )/super.clean( )” should be used as the first line in the method.
Data Interfaces
Data Interfaces are responsible for processing incoming data from a source and writing it to an output interface. An anonymisation system Framework provides a class called AbstractDataInterface which should preferably be extended to implement data interfaces.
Another class, PollingDataInterface, is defined which extends AbstractDataInterface and defines extra logic for the polling of a source at a specified interval.
The following sections explain which methods need to be overridden when implementing a new custom Data Interface of each type.
Every Data Interface is responsible for creating a SimplexDataStream object for each data unit to process. The SimplexDataStream contains an input channel and an output channel which define where the data is being read from and written to respectively.
AbstractDataInterface
The AbstractDataInterface class contains two methods, which must be overridden by implementing classes. They are described in the following tables 3, 4 and 5.
PollingDataInterface
The PollingDataInterface class can be extended to create a Data Interface which polls an input source for content at a specified interval. For example, the FileSystemInterface within anonymisation system 10 is an extension class of PollingDataInterface. The PollingDataInterface class itself handles all the polling code, and the main method which needs to be implemented is described in the following table 6:
Reader/Writers
Reader/Writers are responsible for reading data from a data interface, splitting it up into individual records and fields, sending the fields off to the transform engine for processing and packaging the resulting data back up into the same form for writing back to the data interface.
The anonymisation system framework provides the AbstractReaderWriter class for extension in order to define new Reader/Writers. The “initialise” and “clean” methods of the DDSFComponent interface are also applicable to the Reader/Writers and should be overridden.
Transforms
A Transform class is responsible for performing a transformation on a piece of data and returning the result. To create a custom transform, the anonymisation system Framework provides the AbstractTransform class which should be extended. The “initialise” and “clean” methods of the DDSFComponent interface are also applicable to the Transform and should be overridden.
Tokenisers (Token Stores)
The anonymisation system 10 includes a database implementation of a token store, for use when using a tokenisable transform with tokenisation turned on. It is also possible to create a custom token store.
The anonymisation system 10 is mostly stateless and multithreaded and can scale both horizontally and vertically easily.
The anonymisation system 10 utilises encryption for various purposes:
There are several types of “Key” used by the anonymisation system 10:
The Configuration Management utility is a command line tool which provides the following functionality to manage the encryption aspects of the system:
A storage master key may be required, and all associated Startup keys should be provided on application start-up.
The following describes an example of an anonymisation system 10 deployment. This deployment will utilise the file, HTTP and TCP/IP interface, processing a variety of data formats. A high level architecture is shown in
The deployment consists of 3 main data flows:
Example Input/Output Data
The Configuration file is set up with multiple interfaces and this section gives examples of input and output values for each interface defined above.
File Based Interface
The file based interface is set up to read CSV files consisting of Name, MSISDN and IMEI. An example input file would be:
John Smith,447789123456,123456789012345
Joe Bloggs,447982794563,320247543723897
The name field is set to be partially masked, the MSISDN set to be encrypted, and the IMEI left untransformed, so the output might be as follows:
John #####,985572987352,123456789012345
Joe B#####,952953756154,320247543723897
HTTP Data Interface
The HTTP Data Interface is set up to transform HTTP request data, encrypting the MSISDN and decrypting the MSISDN in the resulting HTML page on the response.
The input would be creating by submitting a form on a web page, but the resulting underlying HTTP request body could be:
msisdn=447789123456&submit=Submit+Query
This msisdn will be encrypted, so the output value could be:
msisdn=671968471158&submit=Submit+Query
This is intercepted and the MSISDN field decrypted by The anonymisation system 10 to the output:
This is intercepted and the MSISDN field decrypted by the anonymisation system 10 to the output:
TCPIP Interface
Two TCP/IP interfaces are set up, one for SMPP and one for UCP. Each of them are set up encrypt a MSISDN field. Example input and output values are shown in
SMPP (The first record shown in
UCP (The first line shown in
Masking may include removing detail and granularity from data items, for example location data for cell-IDs could be masked to generalise the location information to a particular town, county or country.
Of course, the anonymisation system can be configured to anonymise any type of data item and any combination of these data items in a data item set. The invention is not limited to use in anonymising and filtering mobile network data or Customer Data Record (CDR) data, and can be applied to any data having a predefined data structure.
As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims.
Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1112665.3 | Jul 2011 | GB | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/GB2012/051751 | 7/20/2012 | WO | 00 | 6/11/2014 |
