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 DYNAMIC WEIGHT BASED ASSESSMENT OF RISKY PERMISSIONS IN CLOUD ENVIRONMENT

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

Preamble to the description:
The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
[001] The disclosure herein generally relates to the field of cloud computing and, more particularly, to a method and system for dynamic weight based assessment of risky permissions in cloud environment.
BACKGROUND
[002] Cloud computing is an on-demand availability of computing services including servers, storage, databases, networking, software, analytics, and intelligence over the internet to offer faster innovation, flexible resources, and economies of scale. Since multiple stakeholders are involved in the cloud environment, access control is a key aspect. Access control in cloud computing refers to the ability to restrict access to information stored on the cloud. This allows companies to ensure their information is secured and helps minimize risk. In any cloud access control model, users are allowed certain permissions based on different aspects, such as, context data, and user requirements by using Identity and Access Management (IAM) policies or roles. A compromised usage of a permission may increase risk and lead to severe damage to an organization. These permissions can be termed risky.
[003] In conventional systems, either administrator has to manually analyze and assign permissions as risky and continuously monitor them; or they’re identified based on previously known access data, vulnerabilities and risks. However, risk levels of permissions are not always constant and may change with each user. Thus, a user-specific analysis and continuous monitoring of risk levels of permissions is necessary.
SUMMARY
[004] 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 method for dynamic weight based assessment of risky permissions in cloud environment is provided. The method includes receiving, by one or more hardware processors, an access event generated by a user associated with an organization, wherein the access event comprises one of a) a permission usage and b) a resource access. Further, the method includes obtaining by the one or more hardware processors, a permission graph associated with the organization, wherein the permission graph comprises a plurality of permission nodes, a plurality of edges denoting interlink between each of the plurality of permission nodes and, wherein each of the plurality of permission nodes comprises a plurality of attributes. Furthermore, the method includes computing by the one or more hardware processors, an Outward Permission Area (OPA) metric for each of the plurality of nodes associated with the permission graph based on the access event. Furthermore, the method includes generating by the one or more hardware processors, an initial risky permission list based on the calculated OPA metric, a percentile of OPA value for the access event and, a percentage of high clearance required permissions that are reachable from each of the plurality of permissions using an initial risk computation technique. Furthermore, the method includes computing by the one or more hardware processors, a plurality of metrics associated with each of the plurality of permissions in the initial risky permission list, wherein the plurality of metrics comprises a permission usage pattern, an admin ignore-list of non-risky permissions, the OPA value of the permission, a clearance level of the user, a classification level of the permission, a permission distance, and an access to use permission, wherein each of the plurality of the metrics is associated with a corresponding dynamic weight. Furthermore, the method includes normalizing by the one or more hardware processors, each of the plurality of metrics associated with each of a plurality of risky permissions in the initial risky permission list using a normalization technique, wherein the normalization is performed to fit the value associated with each of the plurality of metrics in a predefined interval. Furthermore, the method includes computing by the one or more hardware processors, a risk value associated with each of the plurality of nodes pertaining to the permission graph based on a corresponding normalized metric value and the dynamic weight associated with each of the plurality of metrics. Furthermore, the method includes updating by the one or more hardware processors, the dynamic weight associated with each of the plurality of metrics based on a correlation between the computed risk value and the associated metric value corresponding to each of the plurality of permissions in the permission graph. Furthermore, the method includes updating (218), by the one or more hardware processors, the permission graph based on the computed risk value associated with each of the plurality of permission nodes and the updated dynamic weight associated with each of the plurality of metrics. Furthermore, the method includes determining by the one or more hardware processors, a user specific risky permission list corresponding to each of the plurality of users based on the updated permission graph. Finally, the metho includes determining by the one or more hardware processors, an organization level risky permission list based on the user specific risky permission list and a plurality of risk analysis thresholds.
[005] In another aspect, a system for dynamic weight based assessment of risky permissions in cloud environment is provided. The system includes at least one memory storing programmed instructions, one or more Input /Output (I/O) interfaces, and one or more hardware processors operatively coupled to the at least one memory, wherein the one or more hardware processors are configured by the programmed instructions to receive an access event generated by a user associated with an organization, wherein the access event comprises one of a) a permission usage and b) a resource access. Further, the one or more hardware processors are configured by the programmed instructions to obtain a permission graph associated with the organization, wherein the permission graph comprises a plurality of permission nodes, a plurality of edges denoting interlink between each of the plurality of permission nodes and, wherein each of the plurality of permission nodes comprises a plurality of attributes. Furthermore, the one or more hardware processors are configured by the programmed instructions to compute an Outward Permission Area (OPA) metric for each of the plurality of nodes associated with the permission graph based on the access event. Furthermore, the one or more hardware processors are configured by the programmed instructions to generate an initial risky permission list based on the calculated OPA metric, a percentile of OPA value for the access event and, a percentage of high clearance required permissions that are reachable from each of the plurality of permissions using an initial risk computation technique. Furthermore, the one or more hardware processors are configured by the programmed instructions to compute a plurality of metrics associated with each of the plurality of permissions in the initial risky permission list, wherein the plurality of metrics comprises a permission usage pattern, an admin ignore-list of non-risky permissions, the OPA value of the permission, a clearance level of the user, a classification level of the permission, a permission distance, and an access to use permission, wherein each of the plurality of the metrics is associated with a corresponding dynamic weight. Furthermore, the one or more hardware processors are configured by the programmed instructions to normalize each of the plurality of metrics associated with each of a plurality of risky permissions in the initial risky permission list using a normalization technique, wherein the normalization is performed to fit the value associated with each of the plurality of metrics in a predefined interval. Furthermore, the one or more hardware processors are configured by the programmed instructions to compute a risk value associated with each of the plurality of nodes pertaining to the permission graph based on a corresponding normalized metric value and the dynamic weight associated with each of the plurality of metrics. Furthermore, the one or more hardware processors are configured by the programmed instructions to update the dynamic weight associated with each of the plurality of metrics based on a correlation between the computed risk value and the associated metric value corresponding to each of the plurality of permissions in the permission graph. Furthermore, the one or more hardware processors are configured by the programmed instructions to update the permission graph based on the computed risk value associated with each of the plurality of permission nodes and the updated dynamic weight associated with each of the plurality of metrics. Furthermore, the one or more hardware processors are configured by the programmed instructions to determine a user specific risky permission list corresponding to each of the plurality of users based on the updated permission graph. Finally, the one or more hardware processors are configured by the programmed instructions to determine, an organization level risky permission list based on the user specific risky permission list and a plurality of risk analysis thresholds.
[006] In yet another aspect, a computer program product including a non-transitory computer-readable medium having embodied therein a computer program for dynamic weight based assessment of risky permissions in cloud environment is provided. The computer readable program, when executed on a computing device, causes the computing device to receive an access event generated by a user associated with an organization, wherein the access event comprises one of a) a permission usage and b) a resource access. Further, the computer readable program, when executed on a computing device, causes the computing device to obtain a permission graph associated with the organization, wherein the permission graph comprises a plurality of permission nodes, a plurality of edges denoting interlink between each of the plurality of permission nodes and, wherein each of the plurality of permission nodes comprises a plurality of attributes. Furthermore, the computer readable program, when executed on a computing device, causes the computing device to compute an Outward Permission Area (OPA) metric for each of the plurality of nodes associated with the permission graph based on the access event. Furthermore, computer readable program, when executed on a computing device, causes the computing device to generate an initial risky permission list based on the calculated OPA metric, a percentile of OPA value for the access event and, a percentage of high clearance required permissions that are reachable from each of the plurality of permissions using an initial risk computation technique. Furthermore, computer readable program, when executed on a computing device, causes the computing device to compute a plurality of metrics associated with each of the plurality of permissions in the initial risky permission list, wherein the plurality of metrics comprises a permission usage pattern, an admin ignore-list of non-risky permissions, the OPA value of the permission, a clearance level of the user, a classification level of the permission, a permission distance, and an access to use permission, wherein each of the plurality of the metrics is associated with a corresponding dynamic weight. Furthermore, the computer readable program, when executed on a computing device, causes the computing device to normalize each of the plurality of metrics associated with each of a plurality of risky permissions in the initial risky permission list using a normalization technique, wherein the normalization is performed to fit the value associated with each of the plurality of metrics in a predefined interval. Furthermore, the computer readable program, when executed on a computing device, causes the computing device to compute a risk value associated with each of the plurality of nodes pertaining to the permission graph based on a corresponding normalized metric value and the dynamic weight associated with each of the plurality of metrics. Furthermore, computer readable program, when executed on a computing device, causes the computing device to update the dynamic weight associated with each of the plurality of metrics based on a correlation between the computed risk value and the associated metric value corresponding to each of the plurality of permissions in the permission graph. Furthermore, computer readable program, when executed on a computing device, causes the computing device to update the permission graph based on the computed risk value associated with each of the plurality of permission nodes and the updated dynamic weight associated with each of the plurality of metrics. Furthermore, computer readable program, when executed on a computing device, causes the computing device to determine a user specific risky permission list corresponding to each of the plurality of users based on the updated permission graph. Finally, computer readable program, when executed on a computing device, causes the computing device to determine, an organization level risky permission list based on the user specific risky permission list and a plurality of risk analysis thresholds.
[007] 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
[008] 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:
[009] FIG. 1 is a functional block diagram of a system for dynamic weight based assessment of risky permissions in cloud environment, in accordance with some embodiments of the present disclosure.
[0010] FIGS. 2A and FIG. 2B (collectively called FIG. 2) is an exemplary flow diagram illustrating a processor implemented method for dynamic weight based assessment of risky permissions in cloud environment implemented by the system of FIG. 1 according to some embodiments of the present disclosure.
[0011] FIG. 3 is an exemplary permission graph for the processor implemented method for dynamic weight based assessment of risky permissions in cloud environment implemented by the system of FIG. 1 according to some embodiments of the present disclosure.
[0012] FIG. 4 is an exemplary permission graph with risk values for the processor implemented method for dynamic weight based assessment of risky permissions in cloud environment implemented by the system of FIG. 1 according to some embodiments of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS
[0013] 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.
[0014] Access control in cloud computing refers to the ability to restrict access to information stored on the cloud. This allows companies to ensure their information is secured and helps minimize risk. In any cloud access control model, users are allowed certain permissions based on different aspects, such as, context data, and user requirements by using Identity and Access Management (IAM) policies or roles. A compromised usage of a permission may increase risk and lead to severe damage to an organization. These permissions can be termed risky.
[0015] In conventional systems, either administrator must manually analyze and assign permissions as risky and continuously monitor them; or they’re identified based on previously known access data, vulnerabilities, and risks. However, risk levels of permissions are not always constant and may change with each user. Thus, a user-specific analysis and continuous monitoring of risk levels of permissions is necessary.
[0016] Embodiments herein provide a method and system for dynamic weight based assessment of risky permissions in cloud environment. The present disclosure overcomes the above mentioned drawbacks by a dynamic risk analysis method which continuously evaluates risk levels of permissions in a user session and at organization level.
[0017] For example, consider exemptions table in a payroll dataset. A payroll department personal P accessing exemptions table may be of legitimate use while a regular employee E accessing the exemptions table may not be legitimate use. This access present with regular employee E can be termed risky but the level of risk can be determined by continuously observing the reach of the employee and various other factors that are dynamic in nature.
[0018] Referring now to the drawings, and more particularly to FIGS. 1 through 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.
[0019] FIG. 1 is a functional block diagram of system 100 for a dynamic weight based assessment of risky permissions in cloud environment, in accordance with some embodiments of the present disclosure. The system 100 includes or is otherwise in communication with hardware processors 102, at least one memory such as a memory 104, an I/O interface 112. The hardware processors 102, memory 104, and the Input /Output (I/O) interface 112 may be coupled by a system bus such as a system bus 108 or a similar mechanism. In an embodiment, the hardware processors 102 can be one or more hardware processors.
[0020] The I/O interface 112 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface 112 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, a printer and the like. Further, the I/O interface 112 may enable the system 100 to communicate with other devices, such as web servers, and external databases.
[0021] The I/O interface 112 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the I/O interface 112 may include one or more ports for connecting several computing systems with one another or to another server computer. The I/O interface 112 may include one or more ports for connecting several devices to one another or to another server.
[0022] The one or more hardware processors 102 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, node machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the one or more hardware processors 102 is configured to fetch and execute computer-readable instructions stored in the memory 104.
[0023] The memory 104 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, the memory 104 includes a plurality of modules 106. The memory 104 also includes a data repository (or repository) 110 for storing data processed, received, and generated by the plurality of modules 106.
[0024] The plurality of modules 106 include programs or coded instructions that supplement applications or functions performed by the system 100 for dynamic weight based assessment of risky permissions in cloud environment. The plurality of modules 106, amongst other things, can include routines, programs, objects, components, and data structures, which performs particular tasks or implement particular abstract data types. The plurality of modules 106 may also be used as, signal processor(s), node machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the plurality of modules 106 can be used by hardware, by computer-readable instructions executed by the one or more hardware processors 102, or by a combination thereof. The plurality of modules 106 can include various sub-modules (not shown). The plurality of modules 106 may include computer-readable instructions that supplement applications or functions performed by the system 100 for dynamic weight based assessment of risky permissions in cloud environment.
[0025] The data repository (or repository) 110 may include a plurality of abstracted piece of code for refinement and data that is processed, received, or generated as a result of the execution of the plurality of modules in the module(s) 106.
[0026] Although the data repository 110 is shown internal to the system 100, it will be noted that, in alternate embodiments, the data repository 110 can also be implemented external to the system 100, where the data repository 110 may be stored within a database (repository 110) communicatively coupled to the system 100. The data contained within such external database may be periodically updated. For example, new data may be added into the database (not shown in FIG. 1) and/or existing data may be modified and/or non-useful data may be deleted from the database. In one example, the data may be stored in an external system, such as a Lightweight Directory Access Protocol (LDAP) directory and a Relational Database Management System (RDBMS). Working of the components of the system 100 are explained with reference to the method steps depicted in FIG. 3, FIGS. 6A and FIG. 6B.
[0027] FIG. 2 is an exemplary flow diagram illustrating a method 200 for dynamic weight based assessment of risky permissions in cloud environment implemented by the system of FIG. 1 according to some embodiments of the present disclosure. In an embodiment, the system 100 includes one or more data storage devices or the memory 104 operatively coupled to the one or more hardware processor(s) 102 and is configured to store instructions for execution of steps of the method 200 by the one or more hardware processors 102. The steps of the method 200 of the present disclosure will now be explained with reference to the components or blocks of the system 100 as depicted in FIG. 1 and the steps of flow diagram as depicted in FIG. 3. The method 200 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method 200 may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communication network. The order in which the method 200 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 200, or an alternative method. Furthermore, the method 200 can be implemented in any suitable hardware, software, firmware, or combination thereof.
[0028] At step 202 of the method 200, the one or more hardware processors 102 are configured by the programmed instructions to receive an access event generated by a user associated with an organization. The access event includes a permission usage or a resource access. For example, considering exemptions table in a payroll dataset, a payroll department personal accessing exemptions table is a resource access.
[0029] At step 204 of the method 200, the one or more hardware processors 102 are configured by the programmed instructions to obtain a permission graph associated with the organization. The permission graph includes a plurality of permission nodes, a plurality of edges denoting interlinks between each of the plurality of permission nodes and, wherein each of the plurality of permission nodes comprises a plurality of attributes. In an embodiment, the plurality of attributes includes the risk value, an ignore-list status, the OPA value and a classification level. In an embodiment, the risk value represents the potential risk associated with user accessing the permission in a user session. The ignore-list status states whether the permission is added to an ignore-list (whitelist) by administrator so as to not consider its risk value during access processing. The classification level states the security level for a permission (for example, general permission, low security permission, classified or highly secure permission).
[0030] FIG. 3 illustrates an example permission graph with two users and a plurality of permissions. In an embodiment, the permission graph maintains the list of users, permissions available in the organization and the permission paths through which a permission may provide other permissions. For example, FIG. 3 shows the permission paths and permissions leading to a permission to update a table in a database. There can be many ways to update a table. User may initially login into a laptop, then access browser, login into a website, make a server connection request, login into a database and update the table; or the user may directly access server console in a physical manner by entering the server room. Permission graph maintains all the possible permission paths by maintaining a comprehensive graph of all connections possible among the permissions and resources. Permission graph also maintains various attributes related to each node and one such attribute, risk value, is shown in the figure.
[0031] At step 206 of the method 200, the one or more hardware processors 102 are configured by the programmed instructions to compute an Outward Permission Area (OPA) metric for each of the plurality of nodes associated with the permission graph based on the access event. In an embodiment, the OPA metric for a permission node ‘p’ associated with the permission graph is a count of permission nodes accessible from the permission node ‘p’.
[0032] For example, considering the FIG. 3, OPA(Api.call) = 2. (outgoing permission to ServerConnection.create and Object.view). Similarly, OPA(ServerConnection.create) = 1 and OPA(Browser.open) = 2.
[0033] At step 208 of the method 200, the one or more hardware processors 102 are configured by the programming instructions to generate an initial risky permission list based on the calculated OPA metric, a percentile of OPA value and the percentage of resources and permissions with “a high clearance required” requirement that are reachable from each permission using an initial risk computation technique.
[0034] In an embodiment, an Initial risky permission list is a set of permissions whose initial risk (IR score) is greater than a predefined percentile value (threshold percentile), where IR score for a permission depends on type of the permission (read, write, or owner and such with increasing value), percentile of OPA value of the permission, number of high clearance resources/permissions reachable from the permission. An example initial risky permission list is shown in Table 1A and 1B. Now referring to Table 1A, OPA percentile is calculated based on the highest OPA value observed. In this case, 25 is the maximum OPA value observed.
Table 1A
Permission OPA OPA percentile Percentage of resources with high clearance requirement or secure classification
Api.call 10 40 60
ServerConnection.create 8 10 80
Browser.open 25 100 40

[0035] Further, each of the categorical type of metrics are first converted into continuous type. A categorical type of metric is a set of values that can be categorized into a countable number of groups based on a characteristic. Many of the statistical, machine learning or deep learning algorithms do not work with categorical [ and string] values. Thus, these categorical values are to be first converted into continuous [and numerical] type of metric. This conversion process is implemented using a number of available techniques like Label Encoder, One Hot encoder, converting numerical bins to numbers, or dummy coding. Then, average of the given metrics for a permission is determined. Then, all the permissions with the average greater than predefined threshold average (IR) are determined as initial risky permission list. Now referring to Table 1B, if the threshold IR value is considered 0.6, then all the permissions with IR greater than 0.6 are added to initial risky permission list. For example, here “initial risky permission list” = {Api.call, Browser.open}.
Table 1B
Permission OPA (A) OPA percentile (B) Percentage of resources with high clearance requirement or security (C) IR (initial risk) (AVG(A,B,C))
Api.call 0.4 0.4 0.6 0.7
ServerConnection.create 0.2 0.1 0.8 0.4
Browser.open 1 1 0.4 0.8
[0036] At step 210 of the method 200, the one or more hardware processors 102 are configured by the programming instructions to compute a plurality of metrics associated with each of the plurality of permissions in the initial risky permission list, wherein the plurality of metrics includes a permission usage pattern (metric 1), an admin ignore-list of non-risky permissions (metric 2), the OPA value of the permission (metric 3), a clearance level of the user (metric 4), a classification level of the permission (metric 5), a permission distance (metric 6) and an access to use permission (metric 7), wherein each of the plurality of the metrics is associated with a corresponding dynamic weight.
[0037] In an embodiment, the permission usage patterns is the percentage of the permission p and permission paths leading to permission p used across sessions of different users and user’s current session. The admin ignore-list of permissions: permission p present in this list, then consider this metric value as 0, or else as 1. The OPA value of the permission: the value for this metric is calculated in the step 206. The clearance level of user: higher the clearance level, lower the value for this metric. The classification level of resource/permission: Higher the metric value, higher the classification level. The permission distance: lower the metric value, higher the permission distance. The access to use permission: if user has access to use permission p then this metric value is 0, if not then metric value is 1.
[0038] At step 212 of the method 200, the one or more hardware processors 102 are configured by the programming instructions to normalize each of the plurality of metrics associated with each of a plurality of risky permissions in the initial risky permission list using a normalization technique. The normalization is performed to fit the value associated with each of the plurality of metrics in a predefined interval. For example, the predefined interval is [0,1].
[0039] For example, whenever an action is performed or a permission is requested by user, each of the plurality of metrics are calculated and the risk values of different permissions are updated. For example, let’s assume Laptop.login permission is used. Then, the value of each metric for each permission is computed and normalized as given in Table 2. Now referring to metric 1 of Table 2, if the number of permission paths used are more, the value of metric 1 will be more. At the same time, if the paths used are frequently observed in other user’s sessions, then metric’s value will be less. For example, for Browser.open permission, there is only one path leading to the permission and only one is accessed (a->1/1 i.e., 100%). And assuming this is frequently accessed (b->observed in 80% of user sessions), Metric’s value can be calculated (with variation in weights for a and b) as required by administrator. Here, one such calculation (with weightage 0.75 for a and 0.25 for b) is followed. And the difference in these weighted a and b is the value of metric 1. Now referring to metric 2, if the permission is in admin’s ignore-list of permissions, then the value of metric 2 is 0. Considering Browser.open permission in the ignore-list, the value of metric 2 is 0.
[0040] Now considering the metric 3, the OPA is computed as explained in step 206. Now considering metric 4 of Table 2, considering there are 5 clearance levels in the enterprise for a user and the current user is having 3rd clearance level. So, the value of metric 4 is 0.6 (after normalizing the metric). Now considering metric 5 of Table 2, security classification level of each resource is identified and normalized similar to metric 4. Now considering metric 6 of Table 2, for example, the distance from laptop.login to browser.open is 1 (on average across all permission paths). For example, database.edit permission distance is avg(5,6) -> so the value of metric 6 is 6. Then the metric is to be normalized in inverse relationship manner. So, if the permission distance is found out to be 0.4 then the metric value is 1-0.4=0.6. Now considering metric 7 of Table 2, based on whether access to use this permission is available to the user, metric value is either 1 (no access) or 0 (has access). In cases where there are number of paths leading to a permission and max of decisions for each path are not allowed, then the metric is 1 (not allowed).
Table 2
Permission
\ Metric Metric 1 Metric 2 Metric 3 Metric 4 Metric 5 Metric 6 Metric 7
Browser.open (0.75*1 – 0.25*0.8) = 0.55 0 1 0.6 0.1 0.9 0
Web.access 0.55 0 1 0.6 0.1 0.8 0
Api.call 0.75 1 0.4 0.6 0.2 0.7 0
ServerConnection.create 0.85 1 0.2 0.6 0.4 0.6 1
Database.edit 0.45 1 0.2 0.6 0.6 0.6 0
Table.update 0.45 1 0.2 0.6 0.6 0.5 0
[0041] At step 214 of the method 200, the one or more hardware processors 102 are configured by the programming instructions to compute a risk value associated with each of the plurality of nodes pertaining to the permission graph based on a corresponding normalized metric value and the dynamic weight associated with each of the plurality of metrics. In an embodiment, the dynamic weight (importance value) corresponding to each metric is initially predefined when the system is first executed. Sum of the importance values for all the metrics should be one. In the above example, let’s consider the initial metric weight is as shown in Table 3. In an embodiment, the risk value of a permission p is calculated as the summation of (each metric value multiplied by the metric’s importance value).
Table 3
Name of the Metric Initial weight
Metric 1 0.21
Metric 2 0.2
Metric 3 0.05
Metric 4 0.06
Metric 5 0.14
Metric 6 0.08
Metric 7 0.26
[0042] FIG. 4 is an exemplary permission graph with risk values for the processor implemented method for dynamic weight based assessment of risky permissions in cloud environment implemented by the system of FIG. 1 according to some embodiments of the present disclosure. Now referring to FIG. 4, the node “Browser_access” is updated with a risk value 0.8. Similarly, “Web_access” is updated with 0.4 and the like.
[0043] At step 216 of the method 200, the one or more hardware processors 102 are configured by the programming instructions to update the dynamic weight associated with each of the plurality of metrics based on a correlation between the computed risk value and the associated metric value corresponding to each of the plurality of permissions in the permission graph.
[0044] For example, if the calculated risk value is not proportional with the metric’s value, then that metric’s importance value is changed (increased or decreased) for the next calculation. Change in the metric’s importance value depends on the historical data (metric’s values and their corresponding risk values). Correlation between the metric’s values and their corresponding risk values is calculated. If the calculated risk value and the metric’s value is not proportional as the calculated correlation, then the necessary change in the metric’s importance value is determined.
[0045] For example, after a few sessions when the historical values for the metrics and risk values of each permission is gathered, average of the metric values from each session is determined and their correlation with the risk value is determined as shown in Table 4. Let’s consider the following table for these determined values for the permission ‘Browser.open’. In this embodiment of the system, Pearson Correlation coefficient is used to calculate the correlation value. So, in current user session, if the metric value and risk value correlation match the observed correlation (shown in Table 4) (positive or negative correlation), then metric importance value are not modified. If not, the metric importance values are modified gradually to match the observed correlation score.

Table 4
Metric Average metric value in each session Risk value Correlation value b/w metric and risk value
1 {0.6,
0.5,
0.4,
0.6,
0.5,
0.6,
0.6} {0.8,
0.6,
0.2,
0.8,
0.5,
0.8,
0.8} 0.98
2 0… 0.8… 0.73
3 0.6… 0.8…. 0.5
4 0.6… 0.8… 0.59
5 0.1 0.8 0.34
6 0.9 0.8 0.72
7 0 0.8 0.98
[0046] At step 218 of the method 200, the one or more hardware processors 102 are configured by the programming instructions to update the permission graph based on the computed risk value associated with each of the plurality of permission nodes and the updated dynamic weight associated with each of the plurality of metrics.
[0047] At step 220 of the method 200, the one or more hardware processors 102 are configured by the programming instructions to determine a user specific risky permission list corresponding to each of the plurality of users based on the updated permission graph. The plurality of user specific risky permissions are obtained by executing the following steps. The steps include (i) obtaining a plurality of information rich user sessions from among a plurality of user sessions associated with the organization by excluding the plurality of user sessions with one of, a) a session span less than a predefined session threshold and b) a plurality of sessions where the lowest number of permissions are used (ii) computing an average of risk value for each of the plurality of permissions from the permission graph associated with each of the plurality of information rich sessions, and (iii) obtaining a plurality of overall risky permissions based on the computed average risk value associated with each of the plurality of nodes from the permission graph, wherein a permission with a corresponding risk value greater than a predefined risk threshold are identified as an overall risky permission.
[0048] At step 222 of the method 200, the one or more hardware processors 102 are configured by the programming instructions to determine an organization level risky permission list based on the user specific risky permission list and a plurality of risk analysis thresholds. For example, a plurality of permissions that are commonly found (or found in more than 3/4ths) in user specific risky permissions with high clearance are considered as organization level risky permissions. Similarly, the plurality of permissions that are commonly found (or found in more than 3/4ths) in user specific risky permissions lists of all the users, or users of a group obtained after clustering, are considered as organization level risky permissions. Here, the clustering is based on user roles.
[0049] the plurality of permissions that are commonly found (or found in more than 3/4ths) in user specific risky permissions lists of all the users after clustering are considered as organization level risky permissions.
[0050] a plurality of permissions that are commonly found (or found in more than 3/4ths) in user specific risky permissions when segregated into groups with their peers and the plurality of permissions that are commonly found (or found in more than 3/4ths) in user specific risky permissions lists of all the users are considered as organization level risky permissions.
[0051] 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.
[0052] The embodiments of present disclosure herein address the unresolved problem of dynamic weight based assessment of risky permissions in cloud environment. The present disclosure provides a dynamic risk analysis method which continuously evaluates risk levels of permissions in a user session and at organization level. A plurality of unique metrics is used in the present disclosure and each of the plurality of metrics are associated with a dynamic weight which is updated after each event. This dynamic weight helps in dynamic evaluation of risks in the dynamic cloud environment.
[0053] 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, GPUs and edge computing devices.
[0054] 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., 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.
[0055] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.
, Claims:We Claim:

1. A processor implemented method (200), the method comprising:
receiving (202), by one or more hardware processors, an access event generated by a user associated with an organization, wherein the access event comprises one of a) a permission usage and b) a resource access;
obtaining (204), by the one or more hardware processors, a permission graph associated with the organization, wherein the permission graph comprises a plurality of permission nodes, a plurality of edges denoting interlink between each of the plurality of permission nodes and, wherein each of the plurality of permission nodes comprises a plurality of attributes;
computing (206), by the one or more hardware processors, an Outward Permission Area (OPA) metric for each of the plurality of nodes associated with the permission graph based on the access event;
generating (208), by the one or more hardware processors, an initial risky permission list based on the calculated OPA metric, a percentile of OPA value for the access event and, a percentage of high clearance required permissions that are reachable from each of the plurality of permissions using an initial risk computation technique;
computing (210), by the one or more hardware processors, a plurality of metrics associated with each of the plurality of permissions in the initial risky permission list, wherein the plurality of metrics comprises a permission usage pattern, an admin ignore-list of non-risky permissions, the OPA value of the permission, a clearance level of the user, a classification level of the permission, a permission distance, and an access to use permission, wherein each of the plurality of the metrics is associated with a corresponding dynamic weight;
normalizing (212), by the one or more hardware processors, each of the plurality of metrics associated with each of a plurality of risky permissions in the initial risky permission list using a normalization technique, wherein the normalization is performed to fit the value associated with each of the plurality of metrics in a predefined interval;
computing (214), by the one or more hardware processors, a risk value associated with each of the plurality of nodes pertaining to the permission graph based on a corresponding normalized metric value and the dynamic weight associated with each of the plurality of metrics;
updating (216), by the one or more hardware processors, the dynamic weight associated with each of the plurality of metrics based on a correlation between the computed risk value and the associated metric value corresponding to each of the plurality of permissions in the permission graph;
updating (218), by the one or more hardware processors, the permission graph based on the computed risk value associated with each of the plurality of permission nodes and the updated dynamic weight associated with each of the plurality of metrics;
determining (220), by the one or more hardware processors, a user specific risky permission list corresponding to each of the plurality of users based on the updated permission graph; and
determining (222), by the one or more hardware processors, an organization level risky permission list based on the user specific risky permission list and a plurality of risk analysis thresholds.
2. The method as claimed in claim 1, wherein the plurality of user specific risky permissions are obtained by:
obtaining a plurality of information rich user sessions from among a plurality of user sessions associated with the organization by excluding the plurality of user sessions with one of, a) a session span less than a predefined session threshold and b) a plurality of sessions where the lowest number of permissions are used;
computing an average risk value based on the risk values of the plurality of permissions associated with each of the plurality of information rich sessions; and
obtaining a plurality of overall risky permissions based on the computed average risk value associated with each of the plurality of nodes from the permission graph, wherein a permission with a corresponding risk value greater than a predefined risk threshold is identified as an overall risky permission.
3. The method as claimed in claim 1, wherein a copy of the permission graph associated with the organization is maintained for every user associated with the organization.
4. The method as claimed in claim 1, wherein the permission usage patterns is the percentage of the permission ‘p’ and permission paths leading to permission p used across sessions of different users and user’s current session.
5. The method as claimed in claim 1, wherein OPA metric for a permission node associated with the permission graph is a count of permission nodes accessible from the permission node.
6. The method as claimed in claim 1, wherein plurality of attributes comprises the risk value, an ignore-list status, the OPA value and a classification level.
7. A system (100) comprising:
at least one memory (104) storing programmed instructions; one or more Input /Output (I/O) interfaces (112); and one or more hardware processors (102) operatively coupled to the at least one memory (104), wherein the one or more hardware processors (102) are configured by the programmed instructions to:
receive an access event generated by a user associated with an organization, wherein the access event comprises one of a) a permission usage and b) a resource access;
obtain a permission graph associated with the organization, wherein the permission graph comprises a plurality of permission nodes, a plurality of edges denoting interlink between each of the plurality of permission nodes and, wherein each of the plurality of permission nodes comprises a plurality of attributes;
compute an Outward Permission Area (OPA) metric for each of the plurality of nodes associated with the permission graph based on the access event;
generate an initial risky permission list based on the calculated OPA metric, a percentile of OPA value for the access event and, a percentage of high clearance required permissions that are reachable from each of the plurality of permissions using an initial risk computation technique;
compute a plurality of metrics associated with each of the plurality of permissions in the initial risky permission list, wherein the plurality of metrics comprises a permission usage pattern, an admin ignore-list of non-risky permissions, the OPA value of the permission, a clearance level of the user, a classification level of the permission, a permission distance, and an access to use permission, wherein each of the plurality of the metrics is associated with a corresponding dynamic weight;
normalize each of the plurality of metrics associated with each of a plurality of risky permissions in the initial risky permission list using a normalization technique, wherein the normalization is performed to fit the value associated with each of the plurality of metrics in a predefined interval;
compute a risk value associated with each of the plurality of nodes pertaining to the permission graph based on a corresponding normalized metric value and the dynamic weight associated with each of the plurality of metrics;
update the dynamic weight associated with each of the plurality of metrics based on a correlation between the computed risk value and the associated metric value corresponding to each of the plurality of permissions in the permission graph;
update the permission graph based on the computed risk value associated with each of the plurality of permission nodes and the updated dynamic weight associated with each of the plurality of metrics;
determine a user specific risky permission list corresponding to each of the plurality of users based on the updated permission graph; and
determine an organization level risky permission list based on the user specific risky permission list and a plurality of risk analysis thresholds.
8. The system of claim 7, wherein the plurality of user specific risky permissions are obtained by:
obtaining a plurality of information rich user sessions from among a plurality of user sessions associated with the organization by excluding the plurality of user sessions with one of, a) a session span less than a predefined session threshold and b) a plurality of sessions where the lowest number of permissions are used;
computing an average risk value based on the risk values of the plurality of permissions associated with each of the plurality of information rich sessions; and
obtaining a plurality of overall risky permissions based on the computed average risk value associated with each of the plurality of nodes from the permission graph, wherein a permission with a corresponding risk value greater than a predefined risk threshold is identified as an overall risky permission.
9. The system of claim 7, wherein a copy of the permission graph associated with the organization is maintained for every user associated with the organization.
10. The system of claim 7, wherein the permission usage patterns is the percentage of the permission ‘p’ and permission paths leading to permission p used across sessions of different users and user’s current session.
11. The system of claim 7, wherein OPA metric for a permission node associated with the permission graph is a count of permission nodes accessible from the permission node.
12. The system of claim 7, wherein plurality of attributes comprises the risk value, an ignore-list status, the OPA value and a classification level.

Dated this 17th Day of May 2023

Tata Consultancy Services Limited
By their Agent & Attorney

(Adheesh Nargolkar)
of Khaitan & Co
Reg No IN-PA-1086