>Ingesting client data can include identifying features of the client data. For example, a remote node can inspect client data to identify text/phrases of the client data, metadata of the client data, or any other features included in client data that can be used to generate classifications of the client data. In some embodiments, classification information can be retrieved from a client server or provided by the configuration file generator.

In some instances, ingested data can be catalogued/classified 304 to generate classifications 308 of the client data. For example, a classification for client data can be based on any of a domain 306a, subdomain 306b, attribute 306c, or entity classification 306d. The classifications associated with ingested data can provide context to the ingested data that can be utilized in generating insights into the ingested data.

A domain 306a can include a broader domain upon which a set of client data relates. For example, a domain classifier can include any of “people,” “organization,” “product,” etc. As another example, a domain classifier can be indicative of whether the client data includes PII.

A subdomain 306b can include narrower domain upon which the client data is gathered. For example, the subdomain can include a client (e.g., an employer, a bank). For instance, client data can relate to an employer agreement for an employer included in the “people” domain. The client data can be inspected and determined that a subdomain classifier can identify the employer. As another example, the client data can be inspected to identify a type of form included in the client data.

An attribute 306c can be indicative of the type of data included in the client data. For example, an attribute 306c can include any of a name, phone number, email, social security number, credit card number, geographic location, language, etc., included in the client data.

An entity classification 306d can be indicative of a specific entity. For example, the entity classification 306d can be indicative of a specific client. As another example, if a bank has both personal accounts and mortgage accounts, an entity classification 306d can specify that the client data relates to mortgage accounts for the bank.

Metadata Processing

The data masking process may include metadata processing. Metadata processing can include processing obtained classifications and client data to generate labels that provide an anonymized representation of the information included in client data. In some cases, the labels and/or client data can be encrypted.

FIG. 4 is a block diagram 400 illustrating an example process for metadata processing of data. As shown in FIG. 4, data masking 406 can include obtaining any of the generated classifications 402 and/or the ingested client data 404. In some instances, data masking 406 can include acquiring client-specific configuration information (e.g., client-specific labels) to be provided to the client data. Further, data masking 406 can include acquiring client-specific encryption information and hashing information. For example, the encryption information can include a client-specific encryption key (e.g., E-EKEY). The hashing information can include a hash Salt (e.g., H-SALT). The hash SALT could be computer generated via SHA2 512/256, for example.

A tag store (or “configuration file generator”) 418 can be utilized in label creation 412 to generate labels. A label can be a client-specific indicator of the type of information included in a subset of client data. The label may anonymize attributes of the client data that only can be translated using the client-specific configuration information. The label can be generated based on retrieving metadata 410 relating to the ingested data 404 and classifications 402 and performing a label creation process 412. The label creation process 412 can include comparing the input information with a client-specific label set to identify labels that correspond to the input information.

As an example, if a client uses the database field name “FirstName,” corresponding the data class “first name,” a corresponding label can include “La1.” Using the client-specific configuration information, an authorized device (e.g., network-accessible server system 108) can translate the label La1 to identify that the client data relates to the data class “first name.” Accordingly, in this example, unauthorized entities (e.g., entities without access to client-specific configuration information) would be unable to ascertain the type of information indicated by the label, as the labels are anonymized.

The generated labels can provide an impression of the client data that corresponds to various attributes of the client data. In some instances, a label can correspond to multiple attributes of client data. For example, a label can identify ingested data that includes a first attribute indicative of a “First Name” and a second attribute indicative of an “Address.” In some embodiments, the series of labels can comprise a hierarchy of attributes. For example, a hierarchy of labels can include a subset of labels comprising a first tier of attributes, such as a name, address, etc. Furthering this example, the hierarchy of labels can include a second tier of attributes that further define the first tier of attributes, such as three letters of a name attribute and a Soundex of a name attribute.

Data Profiling

The data masking process may include data profiling. Data profiling may include several processing steps that modify input information to optimize matching accuracy for generating insights for the data. For example, data profiling can standardize and variate data before tokenizing profiled data.

FIG. 5 is a block diagram 500 illustrating an example data profiling process. As shown in FIG. 5, data profiling 500 can include obtaining input information. Example input information can include generated labels 502 and/or ingested data 504. The ingested data 504 can include client data that is de-identified.

The data profiling 500 process can include defining attributes 506. An attribute 506 can be indicative of a characteristic or feature of the client data. For example, an attribute 506 can include a date of birth (e.g., Jan. 1, 1990). This can include a month date, day, year date, and/or a full date of birth (DOB). Other example attributes 506 can include an address, name, email address, gender, phone number, social security number, etc. An attribute 506 can also include a label/classification that is indicative of client data.

Data profiling 500 can include standardization 508 of the attributes 506. Standardization 508 can include verification of the data included in the attributes 506 corresponds to the attribute and standardizing a format of the attribute 506 to a uniform format. Data profiling 500 can include multiple standardization processes that can standardize various types of attributes. In many cases, standardization can be modular horizontally and/or vertically.

The standardized attributes can be processed via one or more rules engines 510. A rules engine can further process a standardized attribute that allows for more insights to be derived from the standardized attribute. Example rules engines 510 can include a nick name engine 512a, address library engine 512b, or any other number of rules engines (e.g., rule engine N 512n).

A nickname engine 512 can associate related names with a common identifier. For example, the name Rick is a common nick name for the name Richard. The nick name engine 512 can inspect an attribute to determine if a name has common nick names associated with the name. For example, the nick name engine 512a can identify that the name Richard has a common nick name of Rick. In such an instance, the nick name engine 512a can create a subsequent label or impression of the attribute that identifies the nick name. The profiled data 514 can include a secondary impression that is indicative of common nick names. This secondary impression can be indicative of any attribute or combination of attributes.

An address library engine 512b can include identifying whether an attribute includes an address and adding the address to a repository/listing that includes various addresses. The address library engine 512b can associate an address to a client/entity. Upon processing via the rules engine(s) 510, data profiling can output profiled data 514.

In some embodiments, an example method for masking data may include ingesting a stream of data corresponding to a client. The stream of data corresponding the client may include one or more columns of client data. As noted above, the data masking process may create an impression of the data that is anonymized with any PII removed such that client data is not exposed external to the client server.

In some embodiments, the stream of data can include one or more classifiers indicative of a characteristic of the attribute. The characteristic can be utilized in identifying the first label. The classifier may include any of a domain classifier indicative of a type of information included in the stream of data, a subdomain classifier indicative of a subset of the selected information type identified in the domain classifier, an attribute classifier indicative of a type of identifiable information included in the stream of data, and an entity classifier indicative of a division of an organization associated with the client.

The method may include identifying an attribute from the stream of data. The attribute may include an impression of a portion of data included in the stream of data that prevents transmission of information included in the stream of data from a client node maintaining the stream of data. In some embodiments, the attribute may include data with any PII removed such that the security/privacy of client data is maintained.

The method may include retrieving client-specific configuration information that includes a listing of labels. Each label in the listing of labels can provide a client-specific indication of a type of information included in the dataset. The labels can be anonymized such that only authorized entities with access to the client-specific configuration information can identify the information indicated by the labels.

The method may include identifying a first label included in the listing of labels that corresponds to a type of information in the attribute. For example, if the attribute is a date of birth, the first label can be indicative of a date of birth.

The method may include processing the attribute and the first label via a data profiling process. The data profiling process may include retrieving a set of validation rules and a set of standardization rules that correspond to the first label. The set of validation rules can provide rules indicative of whether the attribute corresponds to the label. The set of standardization rules may provide rules to modify the attribute into the standardized format.

The data profiling process may include comparing the attribute with the set of validation rules to determine whether the attribute corresponds to the label. If it is determined that the attribute corresponds to the label, the attribute can be modified, as noted below.

In other embodiments, the method may include determining that the attribute is not in accordance with the series of validation rules that correspond to the first label. In these embodiments, responsive to determining that the attribute is not in accordance with the series of validation rules, the first label may be disassociated from the attribute. A second label that is different than the first label may be identified, and the attribute may be validated by determining that the attribute is in accordance with a second series of validation rules that correspond to the second label.

The data profiling process may include modifying the attribute into a standardized format according to the set of standardization rules. This may be performed responsive to determining that the attribute corresponds to the first label.

The data profiling process may include processing the attribute through multiple rules engines. The rules engines may include a name engine that associates the attribute with commonly associated names included in a listing of associated names, responsive to determining that the attribute is indicative of a name. The rules engines may also include an address library engine that adds the attribute to a library of addresses associated with the client, responsive to determining that the attribute is indicative of an address.

In some embodiments, the method may include retrieving a set of client-specific encryption information from a secure server. The client-specific encryption information may include a hash salt specific to the client and an encryption key specific to the client. The attribute may be hashed using the hash salt to generate a hashed attribute. The hashed attribute may be encrypted using the encryption key. In some embodiments, the first label may be compared with a tag store including a series of client-specific tags to identify a first tag that corresponds to the first label. A contextualized token may be generated that includes the hashed attribute and the first tag. In these embodiments, the contextualized token can be sent to the network-accessible server system.

In some embodiments, the client-specific encryption information may be encrypted using a hashed message authentication code (HMAC) protocol or transmitted through TLS mechanism, and the hash code may include a computer-generated SHA2 512/256 token.

In some embodiments, the method may include identifying multiple labels included in the listing of labels. The multiple labels may represent multiple types of information included in the attribute. Responsive to determining that the attribute is associated with more than one label, the multiple labels may be combined into a combination label that identifies the multiple types of information included in the attribute via a combination routine.

In some embodiments, the method may include determining that the first label matches a previously-identified label for a previously-identified attribute in the stream of data corresponding to the client. The method may also include combining the first label with the previously-identified label such that both the previously-identified attribute and the attribute correspond to the previously-identified label.

The method may include outputting the processed attribute and first label to a network-accessible server system. The network-accessible server system may maintain a series of processed attributes or tokens relating to the masked data and generate insights into the client data.

Data Tokenizing

The data masking process may include a tokenizing process. Tokenizing can include encoding profiled data such that the data can be stored and inspected to generate insights into client data. Tokenizing data can provide additional security of client data.

FIG. 6 is a block diagram 600 illustrating an example tokenizing process. The tokenizing process can include obtaining profiled data 602 that includes data processed in the data masking process as described herein. The profiled data can be hashed using a hash code generator (e.g., SALT 604). The hash code generator can be called at runtime. The hash salt can be used in hashing the data using a NIST standard cryptographic hash functions such as, Secure Hash Algorithms (SHA 512/256). Hashing the data can generate a tokenized version of the data 606. For example, hashed data can include a 64-character token. The token 606 can be further compressed into a 44-character string using an encoding technique (e.g., Base64 encoding).

In some embodiments, the token 606 can be encrypted using a client-specific encryption key (e.g., E-EKEY) to produce an intermediate encrypted token (e.g., ETOKEN 608). This may provide an additional layer of encryption and security of the client data to further mitigate risks of unauthorized access to the client data.

The token 606 (or, in some cases, the encrypted token 608) can be tagged with metadata to generate a contextualized token 610. In some embodiments, the contextualized token 610 can be tagged with client-specific tags to generate a client-specific contextualized token (e.g., CTOKEN 610). The contextualized token 610 can be generated based on information maintained in a tag store 612.

In some embodiments, the contextualized token 610 can be generated using any of an encryption process and/or a contextualization process. An encryption process can include encrypting the tokenized information using encryption information specific to the client. The contextualization process can include adding context information for the client to the tokenized information. The context information can be either client-specific or utilized across multiple clients.

The tag store 612 can include a series of tags that correspond to various classification types. For example, tag store 612 can maintain an entity classification tag (EE), a domain classification (DD), and a subdomain classification (SDSD). In some cases, the tags can have a length of up to eight characters. The tag store 612 can maintain a unique tagging scheme for each client. The tag store 612 can include encrypted information that is associated with an encryption key. The information included in the tag store 612 can be provided when tagging tokenized data to generate contextualized tokens. The tag store 612 can be securely maintained by network-accessible server system and access to the tag store can be only provided to authorized users.

The contextualized token 610 can be maintained at a network-accessible server system configured to maintain contextualized tokens 610 for the client and generate insights into the data. In some cases, the tokens can be sent from the remote node to a network-accessible server system for data matching and insight generation.

Example Method for Implementing a Data Masking Process

FIG. 7 is a block diagram of an example method 700 for securely classifying and tokenizing data in a data masking process. As shown in FIG. 7, the method may include ingesting a dataset corresponding to a client (block 702). The dataset may include a series of columns of data relating to a client. This information can be maintained at a client node. In some cases, at least a portion of the data included in the dataset includes personally identifiable information (PII).

The method may include inspecting the dataset to identify a classifier that is indicative of a characteristic of an attribute included in the dataset (block 704). In some embodiments, the classifier includes any of a domain classifier, a subdomain classifier, an attribute classifier, and an entity classifier. In some cases, each classifier can be determined based on inspecting the dataset.

The method may include retrieving client-specific encryption information and client-specific configuration information that includes a listing of anonymized labels that are indicative of types of information included in the dataset (block 706). In some embodiments, the client-specific encryption information may be retrieved from a secure server, the client-specific encryption information can be encrypted using a hashed message authentication code (HMAC) protocol, and wherein the hash code can include a computer-generated SHA2 512/256 token.

The method may include identifying a label included in the listing of anonymized labels that corresponds to a type of information in the attribute based on the identified classifier; (block 708). A label can provide an anonymized identifier of a type of information represented in the attribute. The label can be generated based on any of the attribute and the classifier. For example, if an attribute relates to a name, the corresponding label can be “La1.” In these embodiments, only entities with access to a listing of the information corresponding to the labels can identify the type of information identified by each label, thereby anonymizing the data.

The method may include processing the attribute of the dataset to generate a modified attribute that is modified into a standardized format (block 710). This can include the profiling process as described herein.

In some embodiments, processing the attribute of the dataset to generate the modified attribute further comprises retrieving a set of validation rules and a set of standardization rules that correspond to the label. The set of validation rules can provide rules indicative of whether the attribute corresponds to the label. The set of standardization rules can provide rules to modify the attribute into the standardized format. The attribute can be compared with the set of validation rules to determine whether the attribute corresponds to the label. The attribute can be modified into the standardized format according to the set of standardization rules responsive to determining that the attribute corresponds to the label.

In some embodiments, processing the attribute of the dataset to generate the modified attribute further comprises processing the attribute using a series of rules engines. The rules engines can include a name engine that associates the attribute with commonly associated names included in a listing of associated names, responsive to determining that the attribute is indicative of a name. The rules engines can also include an address library engine that adds the attribute to a library of addresses associated with the client, responsive to determining that the attribute is indicative of an address.

The method may include generating a tokenized version of the modified attribute (block 712). Generating the tokenized version of the modified attribute can include tokenizing and encrypting the modified attribute (or a combination of attributes) to generate a label-specific token (block 714). This may include hashing the modified attribute using a hash code included in the client-specific encryption information to generate a hashed modified attribute. The hashed modified attribute can be compressed from a 64-character token to a 44-character string using an encoding scheme.