Automatic system access review using inter-system mapping

Abstract

Techniques are described for a computing system to maintain security by (a) detecting updates from a plurality of interrelated systems; (b) determining a risk account having an inappropriate access level with reference to the detected update and mapping set; and (c) in response to determining the risk account, providing an alert of the risk account to the entity authorized to change or remove the risk account. Systems, apparatuses, and computer program products for performing the methods and similar methods are also described.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 382,831, entitled “AUTOMATED SYSTEM ACCESS REVIEW USING INTER - SYSTEM MAPPINGS,” filed on November 8, 2022, under 35 USC § 119(e), the entire content of which is incorporated herein by reference. Background Art

[0003] Organizations typically have large information technology (IT) infrastructures that include many different hardware and software systems. Many different individuals are granted access to some or many of these systems via user accounts, depending on the nature of their work or other relationships with the organization. IT system administrators typically perform system access reviews occasionally to review the systems and associated accounts within the organization to ensure that all accounts are associated with known individuals authorized to access the appropriate levels of the systems. Summary of the Invention

[0004] However, performing such occasional system access reviews by IT system administrators can be difficult, inefficient, incomplete, and untimely. For example, large organizations can include a large number of disparate systems, and information about who has what access rights may not always be easily located, especially if only some of the systems are updated with the correct information in a timely manner. Additionally, even if IT administrators perform system access reviews regularly once a quarter, there may be months during which inappropriate access can occur. Moreover, even if IT administrators correctly and fully follow all rules and procedures, it is possible for certain users or groups of users to have access to systems that are unnecessary for their work or tasks.

[0005] Accordingly, it is desirable to implement a tool that allows data from different interconnected systems to be correlated and mapped so as to automatically notify administrators that specific accounts may need to be reviewed. This can be achieved by maintaining a mapping between events generated by multiple interconnected systems and specific accounts that are considered to be at risk due to those changes. The system collects event data from multiple systems, correlates the data with the mapping, and generates warnings about at - risk accounts. In some embodiments, a specific risk level can be evaluated for any at - risk account, and the warning can be customized for that specific risk level.

[0006] In one embodiment, a method for a computing system to maintain security is described, which includes: (a) detecting updates from a plurality of interconnected systems; (b) referring to the detected updates and a set of mappings to determine risk accounts with inappropriate access levels; and (c) in response to determining a risk account, providing an alert of the risk account to an entity authorized to change or remove the risk account. Systems, devices, and computer program products for performing this method and similar methods are also described. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Based on the following description of specific embodiments of the present disclosure, the foregoing and other objects, features, and advantages will be apparent, as illustrated in the accompanying drawings, where like reference numerals refer to like parts in different views. The drawings are not necessarily to scale, but rather focus on illustrating the principles of the various embodiments.

[0008] Figure 1 Example systems, devices, computer program products, and associated data structures for use in conjunction with one or more embodiments are illustrated.

[0009] Figure 2 Example methods in accordance with one or more embodiments are illustrated. DETAILED DESCRIPTION

[0010] A tool is provided that allows data from different interconnected systems to be correlated and mapped so as to automatically notify an administrator that a particular account may need to be reviewed. This can be achieved by maintaining a mapping between events generated by a plurality of interconnected systems and specific accounts that are considered at risk due to those changes. The system collects event data from multiple systems, correlates the data with the mapping, and generates warnings about risk accounts. In some embodiments, a specific risk level can be evaluated for any risk account, and the warning can be customized for that specific risk level.

[0011] Figure 1 An example environment 30 for use in conjunction with various embodiments is depicted. Environment 30 includes a network 35, an access review computing device (ARCD) 32, a user computing device 70 operated by a user 82, and a collection of reporting systems 60. Network 35 can be any type of communication network or collection of communication networks, such as, for example, a LAN, WAN, SAN, the Internet, a wireless communication network, a virtual network, a fabric of interconnected switches, etc.

[0012] Reporting system 60 is a computing system that provides services to an organization and reports certain changes and updates. For example, in one embodiment, as depicted, reporting system 60(a) is an Identity Provider (IdP) system that manages identities and accounts for accessing various systems and resources (not depicted) within the organization's environment 30. The IdP system 60(a) can detect various updates, such as those shown in Table 1.

[0013] Update identifier Update 1.0 Detect IdP 1.1 Detect new user 1.2 Detect removed user 1.3 Detect new application 1.4 Detect removed application 1.5 Detect new group membership 1.6 Detect removed group membership

[0014] Table 1. IdP System Updates

[0015] As another example, in one embodiment, as depicted, reporting system 60(b) is a Human Resources (HR) Information System (HRIS) that manages the organization's core HR requirements, including automatically synchronizing HR-related data. The HRIS 60(b) can detect various updates, such as those shown in Table 2.

[0016]

[0017]

[0018] Table 2. HRIS Updates

[0019] As another example, in one embodiment, as depicted, reporting system 60(c) is a monitoring system that monitors the usage of various systems of the organization in environment 30. The monitoring system 60(c) can detect various updates, such as those shown in Table 3.

[0020] Update identifier Update 3.0 Detect metadata of marked accounts 3.1 Detect data created by users 3.2 Detect user's last login 3.3 Detect user security task assignment 3.4 Detect user task completion 3.5 Detect user applications 3.6 Detect user groups 3.7 Detect user titles 3.8 Detect user departments 3.9 Detect user levels 3.10 Detect user hire dates 3.11 Detect user managers 3.12 Detect user locations 3.13 Detect system 3.14 Detect system types 3.15 Detect system risk levels

[0021] Table 3. Monitoring System Updates

[0022] As another example, in one embodiment, as depicted, reporting system 60(d) is a connected vendor system that manages connections to one or more external vendor systems. The connected vendor system 60(d) can detect various updates from the external vendor systems, such as those shown in Table 4.

[0023] Update identifier Update 4.0 Detect account data 4.1 Detect new accounts 4.2 Detect user roles 4.3 Detect user permissions 4.4 Detect user resources 4.5 Detect user's last login 4.6 Detect vendor changes 4.7 Detect new vendors 4.8 Detect removed vendors

[0024] Table 4. Connected Vendor System Updates

[0025] The reporting systems 60 are each configured to send the detected updates 62 (e.g., the detected updates in Tables 1 - 4) to the ARCD 32 via the network 35.

[0026] Both the ARCD 32 and the user computing device 70 can be any kind of computing device, such as, for example, a personal computer, a laptop computer, a workstation, a server, an enterprise server, a tablet computer, a smart phone, etc. Both the ARCD 32 and the user computing device 70 can include a processing circuit 36, a network interface circuit 34, and a memory 40. In addition, the user computing device 70 further includes a user interface (UI) circuit 38 for connecting to a UI input device 84 and a display device 86. The ARCD 32 and the user computing device 70 can also include various additional features known in the art, such as, for example, an interconnect bus, etc.

[0027] The processing circuit 36 can include any kind of processor or collection of processors configured to perform operations, such as, for example, a microprocessor, a multi-core microprocessor, a digital signal processor, a system-on-chip (SoC), a collection of electronic circuits, a controller of a similar kind, or any combination of the above.

[0028] The network interface circuit 34 can include one or more Ethernet network cards, a cellular modem, a Fibre Channel (FC) adapter, an InfiniBand adapter, a wireless network adapter (e.g., Wi-Fi), and / or other devices for connecting to the network 35.

[0029] The memory 40 can include any kind of digital system memory, such as, for example, random access memory (RAM). The memory 40 stores an operating system (OS (not depicted), such as Linux, UNIX, Windows, MacOS, or a similar operating system), various drivers, and other applications and software modules configured to execute on the processing circuit 36, as well as various data.

[0030] The UI circuit 38 can include any circuitry required to communicate with and connect to one or more user input devices 84 and a display screen 86. The UI circuit 38 can include, for example, a keyboard controller, a mouse controller, a touch controller, a serial bus port and controller, a universal serial bus (USB) port and controller, a wireless controller and antenna (e.g., Bluetooth), a graphics adapter and port, etc.

[0031] The display screen 86 can be any type of display, including, for example, a CRT screen, an LCD screen, an LED screen, etc. The input device 84 can include a keyboard, a keypad, a mouse, a touchpad, a trackball, a pointing stick, a joystick, a touch screen (e.g., embedded within the display screen 86), a microphone / voice controller, etc. In some embodiments, the input device 84 and / or the display screen 86 can be embedded within the user computing device 70 (e.g., a cellular phone or a tablet computer with an embedded touch screen), rather than external to the user computing device 70.

[0032] The memory 40 of the user computing device 70 stores a graphical user interface (GUI) 90, which is configured to execute on the processing circuitry 36 of the user computing device 70 to interact with a user 82 (e.g., a system administrator) operating UI devices 84, 86 by displaying a GUI display 88 on a display 86. In some embodiments, the GUI 90 may include a web browser configured to interact with a remote web server.

[0033] The memory 40 of the ARCD 32 stores an access review module 42, which is configured to execute on the processing circuitry 36 of the ARCD 32. The access review module 42 is configured to receive updates 62 from a reporting system 60 and store them as received updates 43. The access review module 42 is also configured to maintain a mapping database (DB) 44 and use the mapping DB 44 to identify one or more risk accounts 45. For example, the mapping DB 44 includes mappings between different types of updates 62, which indicate that a particular account may be unauthorized, overauthorized, underauthorized, or otherwise at risk. The mapping may also map relationships between accounts or between users and accounts. In some embodiments, these mappings may initially be created by a system administrator (such as user 82). In some embodiments, the access review module 32 may operate to automatically create some or all of the mappings in the mapping DB 44. For example, when a new vendor account is created (possibly during the process of adding a new vendor system), the access review module 32 may establish a mapping between an employee identified by the HRIS 60(b) and the new vendor account provided by the connected vendor system 60(d), and the access review module 32 may also establish a mapping between a user account maintained by the IdP system 60(a) and the new vendor account provided by the connected vendor system 60(d). In some embodiments, the access review module 32 may establish these mappings by looking for matching patterns (such as, for example, matching usernames or identifiers shared between accounts, or by looking at identifying email addresses).

[0034] As an example, an update 62 identified by an update identifier 2.5 (see Table 2) may indicate that an employee has been terminated and should therefore be removed as a user of all locally administered accounts (see update identifier 1.2 in Table 1), and vice versa. As another example, an update 62 identified by an update identifier 2.4 (see Table 2) may indicate that a new employee has been hired and should therefore be added as a user of all locally administered accounts (see update identifier 1.1 in Table 1), and vice versa. The update identifier 3.10 (see Table 3) may also be involved in these cases. The mapping DB 44 can be referenced to map from one update class to another update type (e.g., 2.5 to 1.2) and to map from one user or account to another account (e.g., map employee X identified by HRIS 60(b) to accounts Y and Z maintained by the IdP system 60(a)).

[0035] As another example, an update 62 identified by an update identifier 2.1, 2.2, or 2.3 (see Table 2) may indicate that an employee has changed positions and should therefore have access to various applications added or removed (see update identifier 1.3 or 1.4 in Table 1) and / or an employee's user account should be added or removed from certain groups (see update identifier 1.5 or 1.6 in Table 1), and vice versa. The update identifiers 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, and 3.9 (see Table 3) may also be involved in these cases. Again, the mapping DB 44 can be referenced to map from one update type to another (e.g., 2.1 - 2.3 to 1.3 - 1.6) and to map from one user or account to another account (e.g., map employee X identified by HRIS 60(b) to accounts Y and Z maintained by the IdP system 60(a)).

[0036] As another example, an update 62 identified by an update identifiers 3.1, 3.2, and 3.5 (see Table 3) may indicate that a user has recently (e.g., in the last 6 months or 1 year) used or not used a particular application, and it may therefore be appropriate to remove the user's access to that application (see update identifier 1.4 in Table 1).

[0037] As another example, an update 62 identified by update identifier 2.5 (see Table 2) may also indicate that an employee has been terminated and should thus be removed as a user of all vendor accounts (known to exist due to a previously received update identified by update identifier 4.1). Similarly, an update 62 identified by update identifier 2.4 (see Table 2) may also indicate that a new employee has been hired and should thus be added as a user of all relevant vendor accounts (see update identifier 4.1 in Table 4). The mapping DB 44 can be referenced to map from one update type to another (e.g., 2.4 to 4.1) and from one user or account to another (e.g., map employee X identified by HRIS 60(b) to external accounts P and Q managed by the connected vendor system 60(d)).

[0038] The access review module 42 also includes an alert module 48 that is configured to send an alert 72 indicating a risk account to one or more user computing devices 70. Depending on the embodiment or use case, the alert 72 may be presented to a user 82 of the receiving user computing device 70 as a notification 92 or a message 94. In some embodiments, alerts 72 regarding different risk accounts may be aggregated and sent to the user 82 at periodic intervals (e.g., once a day).

[0039] In some embodiments, the access review module 42 also includes a risk evaluator module 46 that is configured to evaluate a risk value 47 associated with a risk account 45. For example, in one embodiment, the risk evaluator module 46 evaluates a risk value 47 of level 4 for a risk account 45 in a risk state that is considered to be at risk due to an update 43 of the type indicated in Table 1 received; a risk value 47 of level 3 for a risk account 45 in a risk state that is considered to be at risk due to an update 43 of the type indicated in Table 2 received; a risk value 47 of level 2 for a risk account 45 in a risk state that is considered to be at risk due to an update 43 of the type indicated in Table 4 received; and a risk value 47 of level 1 for a risk account 45 in a risk state that is considered to be at risk due to an update 43 of the type indicated in Table 3 received.

[0040] The alert module 48 can be configured to change the type of alert 72 it issues for any given risk account 45 based on its associated evaluated risk value 47. For example, in one embodiment, for a risk account 45 with an associated evaluated risk value 47 of level 4, the alert module sends an alert 72 as a GUI notification 92, which is configured to appear in a section of the GUI 90 dedicated to upcoming access reviews (e.g., only visible within the GUI display 88 when the user 82 selects to view the page describing the upcoming access review); for a risk account 45 with an associated evaluated risk value 47 of level 3, the alert module sends an alert 72 as a GUI notification 92, which is configured to appear in a more prominent section of the GUI 90 (e.g., the home page); for a risk account 45 with an associated evaluated risk value 47 of level 2, the alert module sends an alert 72 as a GUI message 94 to a specific user 82 assigned to perform an access review on that type of account; and for a risk account 45 with an associated evaluated risk value 47 of level 1, the alert module sends an alert 72 as a GUI message 94 to all administrators of the environment 30 to ensure it is seen quickly. In some embodiments, alerts 72 regarding risk accounts with less urgent risk values 47 (e.g., risk values 47 of levels 3 and 4) can be aggregated together and sent to the user 82 at periodic intervals (e.g., once a day), while alerts 72 regarding risk accounts with more urgent risk values 47 (e.g., risk values 47 of levels 1 and 2) can be sent in real time.

[0041] It should be understood that the creation of one alert 72 can also trigger the creation of a second alert 72. For example, if an employee has been terminated (see update identifier 2.5 from Table 2), triggering an alert 72 that the employee should thus be removed as a user of all local administrative accounts (see update identifier 1.2 from Table 1), then another alert 72 can also be generated to indicate that any vendor accounts mapped to the local administrative accounts of that employee should also be removed by the connected vendor system 60(d). As another example, if a user has recently used or not used a particular application (see update identifiers 3.1, 3.2, and 3.5 in Table 3), triggering an alert 72 that it may be appropriate to remove the user's access to that application (see update identifier 1.4 in Table 1)), then another alert 72 can also be generated to indicate that any vendor accounts mapped to the local administrative accounts of that employee should also have access to a similar application removed by the connected vendor system 60(d).

[0042] In some embodiments, the access review module 42 further includes a remapping module 49, which is configured to detect an action performed by the user 82 in response to an alert 72 and update the mapping DB 44 accordingly. For example, if a risk account 45 identified in response to a received specific type of update 43 is routinely shelved without taking action as a response, the remapping module 49 can update the mapping DB 44 to remove or modify the mapping that indicates that the received specific type of update 43 indicates this type of risk account 45. As another example, if employee X was initially mapped to user account Z, but after sending an alert 72 (in response to an update regarding employee X) to the user 82 that recommends taking a certain action on account Z, the user 82 does not take the recommended action on account Z (e.g., change account permissions), but instead takes the recommended action on account T, then the remapping module 49 can note and update the mapping DB 44 to remove the mapping of employee X to user account Z and replace it with a mapping of employee X to user account T.

[0043] The memory 40 may also store various other data structures used by the OS, modules 42, 46, 48, GUI 90, and various other applications and drivers. In some embodiments, the memory 40 may also include a persistent storage portion. The persistent storage portion of the memory 40 may consist of one or more persistent storage devices, such as, for example, a disk, a flash drive, a solid state storage drive, or other types of storage drives. The persistent storage portion of the memory 40 is configured to store programs and data even when the computing devices 32, 70 are powered off. The OS, modules 42, 46, 48, GUI 90, and various other applications and drivers are typically stored in this persistent storage portion of the memory 50 so that they can be loaded into the system portion of the memory 40 when the system is rebooted or as needed. The OS, modules 42, 46, 48, GUI 90, and various other applications and drivers, when stored in a non-transitory form in the volatile or persistent portion of the memory 40, each form a computer program product. The processing circuitry 36 that runs one or more applications thus forms a dedicated circuit that is constructed and arranged to perform the various processes described herein.

[0044] Figure 2Illustrates an example method 100 for providing security-related information performed by a computing device (e.g., ARCD 42). It should be understood that any time a piece of software (e.g., OS, modules 42, 46, 48, GUI 90, etc.) is described as performing a method, process, step, or function, it means that the computing device (e.g., ARCD 32 or user computing device 70) on which the piece of software runs performs the method, process, step, or function when executing the piece of software on its processing circuitry 36. It should be understood that one or more of the steps or sub-steps of method 100 may be omitted in some embodiments. Similarly, in some embodiments, one or more steps or sub-steps may be combined together or performed in a different order. The dashed lines indicate that the steps or sub-steps are optional or represent alternative embodiments or use cases.

[0045] In step 110, the access review manager 42 detects an update 62 from a plurality of interconnected systems 60 (e.g., receives the update 62 and stores it as the received update 43).

[0046] In step 120, the access review manager 42 refers to the received update 43 and a set of mappings (e.g., stored within the mapping DB 44) to determine a risk account 45 with an inappropriate access level. In some embodiments, step 120 may include sub-step 125, where the risk assessment module 46 evaluates an assessed risk value 47 associated with the risk account 45.

[0047] In step 130, the alert module 48 provides an alert 72 (e.g., a notification 92 or a message 94) of the determined risk account 45 to an entity (e.g., user 82) authorized to change, add, or remove the risk account 45. In some embodiments, step 130 includes sub-step 135, where the alert module considers the assessed risk value 47 associated with the risk account 45 when determining what type of alert 72 to send. For example, the alert may be a notification 92, which is a simple GUI flag (e.g., visible only on a specific page of the GUI 90) or an enhanced GUI flag (e.g., visible on the home page or all pages of the GUI 90) or a message 94 sent only to the assigned user 82 or all (or many) administrators of the environment 30. In some embodiments, as part of step 130, the alert 72 may be sent to one of the reporting systems 60, where the alert 72 is used to direct the reporting system 60 to automatically make the recommended changes.

[0048] In some embodiments, in step 140, the remapping module 49 detects an action taken in response to an alert 72 (e.g., by user 82). Then, in step 150, the remapping module 49 selectively modifies the mapping DB 44 (such as by removing, adding, or modifying mappings in the mapping DB) in response to the action detected in step 140. In some embodiments, machine learning can be used to perform step 150, such as by inputting one or more of the response action, received updates 43, determined risk accounts 45, and evaluated risk values 47 into a neural network.

[0049] Accordingly, a tool has been provided that allows data from different interconnected systems 60 to be correlated and mapped so as to automatically notify an administrator 82 that a particular account 45 may need to be reviewed. This can be achieved by maintaining a mapping (e.g., within the mapping DB 44) between events 43 generated by multiple interconnected systems 60 and particular accounts that are considered to be at risk due to those changes. The system collects event data 43 from multiple systems 60, correlates the data with the mapping DB 44, and generates warnings 72 regarding risk accounts 45. In some embodiments, a particular risk level 47 can be evaluated for any risk account 45, and the warning 72 can be customized for that particular risk level 47.

[0050] While various embodiments of the present invention have been specifically shown and described, those skilled in the art will understand that various changes may be made in form and detail without departing from the spirit and scope of the invention as defined by the appended claims.

[0051] It should be understood that although the various embodiments have been described as methods, software embodying these methods is also included. Accordingly, one embodiment includes a tangible computer-readable medium (such as, for example, a hard disk, floppy disk, optical disk, computer memory, flash memory, etc.) programmed with instructions that, when executed by a computer or collection of computers, cause one or more of the methods described in the various embodiments to be performed. Another embodiment includes a computer programmed to perform one or more of the methods described in the various embodiments.

[0052] Furthermore, it should be understood that although the access review module 42 has been described as stored in the memory 40 of the ARCD 32 and executed on the processing circuitry 36 of the ARCD 32, this is by way of example only. In other embodiments, the functions of the access review module 42 and its various components can alternatively be distributed across multiple computing devices similar to the ARCD 32.

[0053] Moreover, it should be understood that all of the embodiments described can be combined with each other in all possible combinations unless such combinations are explicitly excluded.

[0054] Finally, nothing in this specification should be construed as an admission of any kind. Even if a technique, method, apparatus, or other concept is specifically labeled as "background" or "conventional," the applicant does not admit that such technique, method, apparatus, or other concept is actually prior art under the relevant laws, and such determination is a legal determination that depends on many factors, not all of which are known to the applicant at this time.

Claims

1. A method for maintaining security executed by a computing system, the method comprising: Detecting updates from a plurality of interconnected systems; Determining, with reference to the detected updates and a mapping set, risk accounts with inappropriate access levels; And In response to determining the risk accounts, providing an alert of the risk accounts to an entity authorized to change or remove the risk accounts.

2. The method according to claim 1, wherein The method further comprises: Detecting actions taken by the entity in response to the notification; and In response to detecting the actions, selectively modifying the mapping set.

3. The method according to claim 2, wherein, Selectively modifying the mapping set includes one of: removing, adding, and modifying mappings in the mapping set.

4. The method according to claim 2, wherein Selectively modifying the mapping set includes performing machine learning.

5. The method according to claim 1, wherein Determining the risk accounts with the inappropriate access levels includes evaluating risk levels associated with the risk accounts.

6. The method according to claim 5, wherein, Providing the alert of the risk accounts to the entity includes making the type of the alert based on the evaluated risk levels.

7. The method according to claim 6, wherein, Making the type of the alert based on the evaluated risk levels includes: For a first risk account with the lowest evaluated risk level, setting the alert to a notification, the notification being configured to be displayed within a graphical user interface (GUI) of the entity authorized to change or remove the risk account only when the entity selects to view the notification; and For a second risk account with the highest evaluated risk level, setting the alert to a message, the message being configured to be immediately displayed within the GUI of all administrators of the computing system.

8. The method according to claim 7, wherein Making the type of the alert based on the evaluated risk levels further includes: for a third risk account with an intermediate evaluated risk level, setting the alert to a notification or a message, the notification or the message being configured to be immediately displayed within the GUI of the entity authorized to change or remove the risk account.

9. The method according to claim 1, wherein The plurality of interconnected systems includes: An identity provider system that manages identities and accounts for accessing various systems and resources; and A monitoring system that monitors the usage of various systems.

10. The method according to claim 1, wherein, The method further includes establishing the mapping set by looking for matching patterns.

11. A computer program product comprising a non-transitory computer-readable storage medium storing instructions that, when executed by a processing circuit of a computing system, cause the computing system to maintain security by: Detecting updates from a plurality of interconnected systems; Determining, with reference to the detected updates and a mapping set, risk accounts with inappropriate access levels; And In response to determining the risk accounts, providing an alert of the risk accounts to an entity authorized to change or remove the risk accounts.

12. The computer program product according to claim 11, wherein, The instructions, when executed by the processing circuit, further cause the processing circuit to: Detect actions taken by the entity in response to the notification; and In response to detecting the actions, selectively modifying the mapping set.

13. The computer program product according to claim 11, wherein, Determining the risk accounts with the inappropriate access levels includes evaluating risk levels associated with the risk accounts.

14. The computer program product according to claim 13, wherein, Providing the alert of the risk accounts to the entity includes making the type of the alert based on the evaluated risk levels.

15. The computer program product according to claim 14, wherein making the type of the alert based on the evaluated risk level includes: For a first risk account with the lowest evaluated risk level, setting the alert as a notification, the notification being configured to be displayed within the graphical user interface (GUI) of the entity authorized to change or remove the risk account only when the entity selects to view the notification; And For a second risk account with the highest evaluated risk level, setting the alert as a message, the message being configured to be immediately displayed within the GUI of all administrators of the computing system.

16. A computing system, comprising: A network interface circuit configured to connect to a plurality of interconnected systems; And A processing circuit coupled to a memory, the processing circuit being configured to cause the computing system to maintain security by: Detecting updates from the plurality of interconnected systems; Referring to the detected updates and a set of mappings, determining a risk account with an inappropriate access level; And In response to determining the risk account, providing an alert of the risk account to an entity authorized to change or remove the risk account.

17. The computing system according to claim 16, wherein, The processing circuit system coupled to the memory is further configured to: Detect an action taken by the entity in response to the notification; and In response to detecting the action, selectively modify the set of mappings.

18. The computing system according to claim 16, wherein, Determining the risk account with the inappropriate access level includes evaluating a risk level associated with the risk account.

19. The computing system according to claim 18, wherein, Providing the alert of the risk account to the entity includes making the type of the alert based on the evaluated risk level.

20. The computing system according to claim 19, wherein, Making the type of the alert based on the evaluated risk level includes: For a first risk account with the lowest evaluated risk level, setting the alert as a notification, the notification being configured to be displayed within the graphical user interface (GUI) of the entity authorized to change or remove the risk account only when the entity selects to view the notification; and For a second risk account with the highest evaluated risk level, setting the alert as a message, the message being configured to be immediately displayed within the GUI of all administrators of the computing system.

Images