Claims:1. A processor-implemented method, comprising:
monitoring (202), via one or more hardware processors, workflow with respect to navigation of a user in an application;
determining (208) whether data in a current application state of the application is to be selectively masked for the user, based on an information disclosure and at least one purpose of the current application state, via the one or more hardware processors;
identifying (212) data to be masked, upon determining that the data in the current application state is to be selectively masked for the user, via the one or more hardware processors;
masking (214) the data that is identified as to be masked, via the one or more hardware processors; and
displaying (216) data that is not to be masked, to the user, wherein access to the data being displayed is restricted based on a User Privacy Policy (UPP) defined for the data being displayed.

2. The method as claimed in claim 1, wherein determining whether data in the current application state needs to be selectively masked for the user, based on the information disclosure and the at least one purpose, comprises:
determining (204) the information disclosure for the current application state, by the data management system 100;
identifying (206) the at least one purpose of accessing the current application state, by the user, in terms of at least one elementary context, by the data management system 100; and
determining (208) whether the data is to be masked, based on the information disclosure and the identified at least one purpose, by the data management system 100.

3. The method as claimed in claim 2, wherein determining whether the data is to be masked, comprises:
comparing the determined information disclosure with the at least one identified purpose of the user, by the data management system 100;
identifying whether any data not matching with the identified at least one purpose constitute at least a portion of the information disclosure of the current application state, by the data management system 100; and
selecting the data identified as not matching with the identified at least one purpose, for masking, by the data management system 100.

4. The method as claimed in claim 2, wherein the information disclosure is total amount of information displayed to the user for the current application state.

5. A data management system 100, said system comprising:
a processing module 107 comprising a one or more hardware processors; and
a memory module 105 comprising a plurality of instructions, said plurality of instructions causing the one or more hardware processors to:
monitor workflow with respect to a navigation of a user in an application, by a workflow monitoring module 102 of the data management system 100;
determine whether data in a current application state of the application is to be selectively masked for the user, based on an information disclosure and at least one purpose of the current application state, by a recommendation module 103 of the data management system 100;
identify data to be masked, upon determining that the data in the current application state is to be selectively masked for the user, by using the recommendation module 103;
mask the data that is identified as to be masked, by using a privacy engine 104 of the data management system 100; and
display data that is not to be masked, to the user, by using an Input/Output (I/O) module 101, wherein access to the data being displayed is restricted based on a User Privacy Policy (UPP) defined for the data being displayed.

6. The data management system 100 as claimed in claim 5, wherein said recommendation module 103 is configured to determine whether data in an application state is to be selectively masked for the user, by:
determining the information disclosure for the current application state;
identifying the at least one purpose of accessing the current application state, by the user, in terms of at least one elementary context; and
determining whether data is to be masked, based on the information disclosure and the identified at least one purpose.

7. The data management system 100 as claimed in claim 6, wherein the recommendation module 103 is configured to determine whether the data is to be masked, by:
comparing the determined information disclosure with the identified at least one purpose of the user;
identifying whether any data not matching with the identified at least one purpose constitute at least a portion of the information disclosure of the current application state; and
selecting data that is not matching the identified at least one purpose, if present, for masking.

8. The data management system 100 as claimed in claim 6, wherein said recommendation module 103 is configured to determine the information disclosure as total amount of information displayed to the user for the current application state.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
METHOD AND SYSTEM FOR SELECTIVE DATA MASKING IN AN APPLICATION

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
The disclosure herein generally relates to data security management, and, more particularly, to selectively masking data in an application based on consent and context.

BACKGROUND
Data/information security is a major concern, especially when data is stored in shared resources. When a user logs into an application, he/she may get exposed to a lot of information, some of which are relevant to that user, and some of which may be irrelevant for the user. The relevance/irrelevance can vary based on the purpose with which the user is accessing the information.
When the user has access to data that is irrelevant to him/her, and when that particular data is sensitive, a data breach scenario is possible. From an organizational perspective, any such event would adversely affect organization’s business as the organization may encounter a potential financial and legal risks. In order to prevent such instances, strict data security measures are enforced.
One way of ensuring data security is by providing an authenticated access by virtue of a password system. However, disadvantage of the existing systems that utilizes password controlled access to data is that the filtering of users and corresponding data requests happen only at a broad level, which means a user with a verified password can login to the application, and can still get access to data that is irrelevant to him/her. In another mode of implementation, the system may use a role based authorization mechanism for each user. However, the role based authorization frameworks may not provide adequate protection if applications are not properly designed and hence may end up exposing more information than needed for a given purpose.

SUMMARY
Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a processor-implemented method is provided. In this method, a data management system monitors, via one or more hardware processors, workflow with respect to navigation of a user in an application. Further, the data management system determines whether data in current application state is to be selectively masked for the user, via the one or more hardware processors. Upon determining that the data in the current application state is to be selectively masked for the user, the data management system identifies data to be masked, via the one or more hardware processors. Further, the data that is identified as to be masked, is masked via the one or more hardware processors, by the data management system. The data management system further displays data that is not to be masked, to the user, wherein access to the data being displayed is restricted based on a User Privacy Policy (UPP) defined for the data being displayed.
In another aspect, a data management system is provided. The data management system comprises of a processing module comprising a plurality of hardware processors; and a memory module comprising a plurality of instructions. The plurality of instructions cause at least one of the plurality of hardware processors to monitor workflow with respect to a navigation of a user in an application, by using a workflow monitoring module of the data management system. Further, data management system determines whether data in a current application state is to be selectively masked for the user, by using a recommendation module. Upon determining that the data in the current application state is to be selectively masked for the user, then using the recommendation module, the data that is to be masked is identified. Further, by using a privacy engine of the data management system, the data that has been identified as to be masked, is masked. The data that is not to be masked, is displayed to the user, by using the I/O interface, wherein access to the data being displayed is restricted based on a User Privacy Policy (UPP) defined for the data being displayed.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
FIG. 1 illustrates an exemplary block diagram of a data management system according to some embodiments of the present disclosure.
FIG. 2 (comprising FIG. 2A and FIG. 2B) is a flow diagram depicting steps involved in a method of selectively masking data using the data management system of FIG. 1, according to some embodiments of the present disclosure.
FIG. 3 illustrates an example scenario of data exposure which can be handled by the data management system of FIG. 1, in accordance with some embodiments of the present disclosure.
FIG. 4 illustrates an example of a work flow graph generated for an application, by the data management system of FIG. 1, in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
Referring now to the drawings, and more particularly to FIG. 1 through FIG.4, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
FIG. 1 illustrates an exemplary block diagram of a data management system 100 according to some embodiments of the present disclosure. The data management system 100 includes an Input/Output (I/O) module 101, a workflow monitoring module 102, a recommendation module 103, a privacy engine 104, a memory module 105, an application navigation module 106, and a processing module 107.
The I/O module 101 is configured to provide at least one interface for the data management system 100 to interact with at least one external entity. The term ‘external entity’ in the context of the data management system 100 is used can refer to a hardware, a software, and/or a combination thereof. In another embodiment, the external entity may be a user who interacts with the data management system 100 for data transfer with respect to activities such as but not limited to user providing an input to the data management system 100, user fetching/collecting output(s) from the data management system 100, and user configuring one or more settings of the data management system 100. The I/O module 101 can be configured to collect inputs specific to user actions on any application, by tracking changes in User Interface (UI) and/or based on keystrokes and/or through any such means.
The workflow monitoring module 102 can be configured to monitor user actions on each application the data management system 100 is handling, and collect all required inputs related to the user’s navigation across different states of the application (for example, if the application is a ‘website’, the ‘different states of application’ can refer to different pages of the website/application, and navigation can refer to the user moving across the different pages). By scanning the application, the workflow monitoring module 102 monitors and collects information pertaining to access path and quantum of information that is being displayed to user, till the latest screen. The term ‘access path’ represents path followed by the user to reach the latest (or current) screen of the application, and total amount of information that is being displayed to user till the latest screen is termed as ‘information disclosure’ for current application state. For example, refer to scenario depicted in Fig. 3. In this scenario, the user logs into the application by entering user name and password. Upon logging in, the user is prompted to select role (one of ‘Admin’ and ‘service’). The user selects ‘Admin’ as the role, and then he/she is redirected to a search page wherein the user can input a value corresponding to one or more fields being displayed to the user. Once the user hits the ‘search tab’, search results are fetched and displayed to the user. In this example scenario, access path is “Login ? Role selection ? Search page ? Search results page”. Similarly, the ‘information disclosure’ in this scenario refers to information (total/collective) exposed while the user is navigating from the login page till the results page.
The information disclosure for a particular application state is represented as:
ID (S) = IDPrev ? U_(i=1)^n R_i --- (1)
Where, assuming information on screen can be visualized in tabular form,
U_(i=1)^n R_i is information related to the current state (or screen) of an application being considered.
Ri is ith record Ri=(ri1,ri2,ri3,….rin). ri1 is value of first attribute of the Rith record. IDPrev = Information disclosed so far (i.e. till the current application state).
Further, the term ‘application state’ refers to current state/screen being displayed (of the application). For example, if ‘login screen’ is being displayed to the user, then the application state refers to the ‘login screen’
The workflow monitoring module 102 further identifies at least one purpose of the user behind accessing the latest screen (i.e. the current application state). Considering the example depicted in Fig. 3, the recommendation module 103 can decide that the user accessed the search page to retrieve only names of customers. In an embodiment, the workflow monitoring module 102 identifies the purpose based on an elementary context that is defined for the application screen being accessed by the user. In an embodiment, the elementary context is a triplet consisting of domain, field, and purpose description, and is defined at a field level. In various embodiments, the elementary contexts for an application are pre-defined or dynamically defined, and are attached to corresponding fields of the application. Capability to dynamically define elementary contexts allows modification of an existing elementary context and/or to define the elementary context on the go. This process further involves defining fields being processed by the application, and attaching purpose(s) to the fields. Further, context is defined at the field level by attaching domain and purpose to it. Consider that the example given in Fig. 3 depicts states of an application in banking domain. In this scenario, ‘domain’ is ‘banking’, ‘field’ can be user name, password, account number, customer identification number (ID), email address and so on, which are being displayed on the current application state, and ‘purpose’ of each field represents ‘purpose or utility’ of the field.
The workflow monitoring module 102 further generates, for the application being scanned, a graphical representation (termed as a ‘work flow graph’), by executing the sequence of steps given below:
Load first page of an application. Create start state node in the application graph called AppG. Assign start state to previous state. Initialize Actions and AccessedFields to empty set.
Execute the action (for example, button, link, dropdown, Keyboard and so on)
Capture the request parameters. If no request parameters is sent, then create an empty set for request parameters.
Capture and parse the application screen generated post execution of action of (step 2)
Create a node in the application graph AppG.
Create an edge from the previous state node to newly created node with label of Action and request parameters. Assign newly created node to previous node.
Extract the purpose from the screen. (In most of cases, title of the screen or header in the beginning of screen state the purpose of the screen).
Add purpose to the list of accessed purposes: AccessedPurposes = AccessedPurposes plus Purpose of the screen
Extract all the fields from the screen
Add fields to the list of accessed fields : AccessedLstFields = AccessedLstFields plus newly accessed Fields
Create a new application state : AppState = Actions U .ActionName
Link AccessedPurposes and AccessedFields to AppState
Execute steps 2-12 until no new state is generated.
The work flow graph generated by executing the aforementioned steps is depicted in Fig. 4. The workflow monitoring module 102 then provides information pertaining to the access path, purpose, and information disclosure as inputs to the recommendation module 103. In an embodiment, information pertaining to the access path is captured separately for each session.
The recommendation module 103 is configured to collect information pertaining to the access path, purpose, and information disclosure for at least one application state of the application being scanned, as input, from the workflow monitoring module 102. The recommendation module 103 further determines whether the information being displayed to the user (as represented by the ‘information disclosure’) matches the identified purpose or not. For example, in the aforementioned example scenario with respect to Fig. 3, as the purpose of accessing the search page is identified as retrieval of information pertaining to only names of the customers and/or address of the customers, the information with respect to account number of each user/customer may not match the purpose. The recommendation module 103, upon identifying that the account numbers are not to be displayed to the users, decides to mask/shield the account number information so as to prevent unnecessary/unauthorized access to sensitive data. The recommendation module 103 further provides information pertaining to the data to be masked, as input to the privacy engine 104.
In an embodiment, the recommendation module 103 uses elementary context specific rules with respect to sharing of data, to determine whether a data is to be masked or not. A few examples of such rules are given below. It is to be noted that any number of such rules can be defined and configured with the data management system 100.
Rule 1: If content being displayed on the screen belongs to the user who is viewing that screen, then information is straight away displayed to end user.
Rule 2: If the purpose behind access of the screen matches with the purposes of elementary contexts of all the fields being accessed, then information is displayed to end user.
Rule 3: If the purpose matches with some of elementary contexts of the fields to be displayed, then privacy engine is invoked for the fields which do not share their purposes with purpose of access.
Rule 4: Privacy engine is invoked for all the fields if none of the elementary contexts matches with purpose behind access of the screen.
In an embodiment, the recommendation module 103, upon processing the information disclosure, purpose, and the rules, may identify that at least one of the purposes matches the information disclosure. In such scenario, in order to provide further data security, the recommendation engine 103 refers to User Privacy Policy (UPP) corresponding to the data to be displayed, wherein the UPP specifies certain user defined preferences/restrictions with respect to data privacy. For example, consider the table given below:
Table. 1
The actions to be triggered in response to a data access request is defined in terms of 4 different preferences. Allow, Notice, Consent, and Deny (as in Table. 1). In an embodiment, the number of preferences/parameters can vary as per requirements. A user can specify the conditions for allowing access to data that belongs to him/her, hence the preferences set in the UPP are also referred to as ‘user consent’. Allow preference allow the sensitive field to be accessed without any restriction. Notice preference notifies user whenever the field is accessed. Consent preference mandates the person accessing the sensitive field to obtain consent from data subject. Deny preference completely denies an access to the sensitive field. These preferences can be stored as user consent. After determining data that needs to be masked, the data masking system 100 can filter the remaining data (the data that is not to be masked) based on the consent/preferences, and then display to the user.
In an embodiment, the recommendation engine 103 can be configured to provide secured data access based on a combination of the rules and the preferences. For example, after determining data to be displayed to a user based on the purpose, the preferences can be utilized for performing another level of filtering, and accordingly data access can be provided.
The privacy engine 104 is configured to collect information pertaining to data to be masked, as input from the recommendation engine 103, and mask the data using any suitable dynamic data masking technique (for example, data masking technique disclosed in the US patent application 9171182 by the same applicant can be used for masking the data).
The memory module 105 can be configured to store any data that is being handled by the data management system 100, as part of providing restricted access to data and for selectively masking data. For example, information such as but not limited to user data, elementary context specific data (including the rules), user consent (preferences), history information pertaining to data access requests made by each user, data masking performed, workflow graph for different applications and so on are stored in any volatile/non-volatile storage space associated with the memory module 105, as per requirements.
The application navigation module 106 is configured to determine and recommend navigation between different application states, such that there is minimum information disclosure to an end user. In an embodiment, input to the application navigation module 106 can be the workflow graph for each application as generated by the workflow monitoring module 102. By taking the workflow graph AppG as input, the application navigation module 106 recommends a new navigation which may reduce the information disclosure to end user. Consider the AppG in Fig. 4. The transition from state S1 to Sm’ is achieved by passing parameters. While transition from Sm’ to Sm is achieved without submitting any information to appplication. Hence, the application can go from state S1 to Sm by passing only those parameters which were required while transiting from the state S1 to Sm’. A new transition edge from the S1 and Sm is created with parameters of the edge S1 to Sm’. The application navigation module 106 can be configured to execute the following sequence of steps to process an application and generate new edges, whenever possible:
Sstart = retrieveStartState(AppG) /* fetch start state from an application graph */
E = retrieveEdges(Sstart) /* retrieve all edges incident on start state */
Enque( E ) /* put all edges in a queue */
While (e = Deque ( E ) != null) /* unless all edges are processed */
{
If (not(isBackedge ( e ))) /* e is not a back edge */
{
If (isEmpty( e )) /* e does not have request parameters attached */
{
s=getState( e ) /* get application state reachable from e */
mark(s) /* mark state s */
if( isMarked( s ) && not(isStartState(prevState( s ))) /* s is marked and previous state of s is not start state */
{
createEdge(prevState(prevState( s )), s) /* create an edge between two states */
E’ = retrieveEdges( s ) /* fetch edges connected to state ‘s’ */
Enque( E’ ) /* add edges to the queue */
}
}
}
}
The processing module 107 can be configured to interact with all other components of the data management system 100, collect instruction pertaining to execution one or more steps (i.e. data processing) with respect to function(s) being handled by each module, using one or more associated hardware processors.
FIG. 2 (comprising FIG. 2A and FIG. 2B) is a flow diagram depicting steps involved in the process of selectively masking data using the data management system of FIG. 1, according to some embodiments of the present disclosure. The data management system 100 is configured to provide secured access to data and selectively mask contents of one or more applications being managed by the data management system 100.
The data management system 100 monitors (202) workflow with respect to user navigation on an application. The term ‘user navigation’ refers to a user’s navigation in the application (through different application states). By monitoring the workflow, and by scanning the application, the data management system 100 identifies (204) and collects information pertaining to access path and information disclosure for the current application state (which refers to latest state of the application). Based on elementary context based rules, the data management system 100 then determines at least one (206) purpose corresponding to the application state. Further, based on the application state and the purpose, the data management system 100 checks whether information disclosure pertaining to current application state of the application matches the identified at least one purpose or not. If any data that constitute at least a portion of the information disclosure is identified as not matching the information disclosure, the data management system 100 determines (208) that the data that is not matching the at least one purpose is to be shielded. If data is to be shielded (i.e. if masking is required), then the data management system 100 selects (212) data to be masked, and then masks (214) the selected data. The data management system 100 then filters data that is identified as not to be masked, based on the defined consent/preferences (as defined in terms of User Privacy Policy (UPP)), and then displays (216) to the user. Various actions in Fig. 2 can be performed in the same order or in a different order. Further, or one or more of the actions in method 200 can be omitted if needed.
The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
The embodiments of present disclosure herein addresses unresolved problem of data security in applications. The embodiment, thus provides a mechanism for selectively masking data based on consent and context. For each field in each application state of an application, an elementary context is defined, wherein the elementary context defines context at a field level by attaching domain and purpose to it. A system being used (i.e. the data management system 100) identifies for any application state, information disclosure as total/cumulative information exposure. The system then checks whether the information disclosure matches purpose, and any data that constitute the information disclosure and which does not match the purpose is masked/shielded. Further, access to data that is being displayed to the user is restricted based on corresponding User Privacy Policy (UPP) which is specific to data.
It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.