CROSS-REFERENCE TO RELATED APPLICATION

[0000] This application claims the benefit of U.S. Application No. 16/224,038 filed December 18, 2018, the disclosure of which is expressly incorporated by reference herein in its entirety.

TECHNICAL FIELD

[0001] The present disclosure generally relates to systems and methods for management of user account access privileges within an organization’s technical infrastructure.

BACKGROUND

[0002] In large-scale corporate environments, managing user access to corporate technology

infrastructure is often burdensome and time consuming. It may take system administrators several days to update or modify user access. This delay may expose the corporation to internal security threats and lead to inefficiencies and system failures during a response to a security threat. In some industries, regulations such as Sarbanes Oxley/Statement on Standards for Attestation Engagement 16 (SOX/S SAE 16) require a regular audit of accounts and account access within the organization. This audit can be both difficult to implement and time consuming.

[0003] It is therefore appreciated that a need exists for improved systems and methods for

managing user account access.

SUMMARY

[0004] In an exemplary embodiment, an account lifecycle management system is provided. The system includes a discovery engine configured to discover and identify an account. The system further includes a policy engine configured to identify privileged access data granted to the account identified by the discovery engine. The system further includes a data modeling engine configured to associate the identified privileged access data with organizational information. The system further includes a remediation engine configured to remediate the account based on the associated privileged access data. In some embodiments, the system further includes a mitigation engine configured to mitigate the account based on the associated privileged access data. [0005] In another exemplary embodiment, a method for account lifecycle management is provided. The method includes identifying an account, identifying privileged access data granted to the account, and associating the privileged access data with organizational information. The method further includes remediating the account based on the associated privileged access data.

[0006] These and other objects, features and advantages of the present disclosure will become

apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] These and other features of the present disclosure will become better understood with

regard to the following description and accompanying drawings in which:

[0008] Figure 1 shows a block diagram of an exemplary account lifecycle management system.

[0009] Figure 2 shows an exemplary account enrichment process.

[0010] Figure 3 shows an exemplary user interface for account lifecycle management.

[0011] Figure 4 shows a view of an exemplary automation workflow.

DETAILED DESCRIPTION

[0012] Aspects and implementations of the present disclosure will be understood more fully from the detailed description given below and from the accompanying drawings of the various aspects and implementations of the disclosure. This should not be taken to limit the disclosure to the specific aspects or implementations, but rather as being provided for further explanation and understanding only.

[0013] In Figure 1, an exemplary account lifecycle management (ALM) system 100 is shown. The account lifecycle management system 100 comprises at least a Discovery Engine 102, a Policy Engine 104, a Data Modeling Engine 106, and a Remediation Engine 108. In some embodiments, the system further comprises a Mitigation Engine 110. In some embodiments, the account lifecycle management system 100 is implemented as software instructions executed by a processor and a memory. In some embodiments, the account lifecycle management system 100 is implemented by a network of Internet connected computers having at least one processor and a memory. In some embodiments, Discovery Engine 102, Policy Engine 104, Data Modeling Engine 106, and Remediation Engine 108 are implemented together on the same computer processing system, and in other embodiments, as separate sub-systems configured to communicate over the Internet, an Intranet network, or some other communications network. As used herein, an engine may be implemented within hardware such as a processor in communication with a memory. In some

embodiments, an engine may be implemented as software instructions, that when executed by computer hardware, cause the computer to perform steps as dictated by the instructions. Other combinations of hardware and software will be apparent to those of skill in the art.

[0014] In some embodiments, Discovery Engine 102 is configured to discover and identify user accounts within an organization. In some embodiments, user accounts are retrieved from sources that feed account and entitlement information and sources that contain information about the account such as ownership and organizational association. In some embodiments, accounts are retrieved from an optimized source list. An optimized source list focuses account retrieval from main account repositories such as KEON (comprehensive Unix security management system), JITOD (comprehensive Wintel security management system), Mainframe/Midrange onboarded to Data Collection Repository (DCR) user tables, and Database user tables. It is appreciated that, in some embodiments, an optimized source list may comprise different account repositories according to user preference. In some embodiments, the sources are read only. In other embodiments, the Discovery Engine 102 is configured to read or write data from a source.

[0015] In an exemplary embodiment, there are two different account types identifiable by

Discovery Engine 102: Single User accounts and Functional accounts. Single User accounts may be defined by their distinct link to a Security Identifier (SID). For Example, in the context of the Microsoft Windows NT line of operating systems, a Security Identifier (SID) is a unique, immutable identifier of a user, user group, or other security principal. A security principal has a single SID for life (in a given domain), and all properties of the principal, including its name, are associated with the SID. This design allows a principal to be renamed (for example, from "Jane Smith" to "Jane Jones") without affecting the security attributes of objects that refer to the principal. [0016] In contrast to Single User accounts, Functional accounts may be defined by the absence of any link to an SID. In some embodiments, Functional accounts are comprised of Shared Interactive accounts, Application-to-Application accounts, Hybrid accounts, Platform Default accounts, and AD (Active Directory) Primary accounts. Shared Interactive accounts are shared amongst a group of users and used interactively within a host or database. Application-to-Application accounts are not used interactively by a user but rather are used to facilitate application functionality or processing. Application-to- Application accounts may be used within a host or between hosts. Hybrid accounts are used both interactively by a user and to facilitate application functionality. Platform Default accounts are accounts that are pre-generated as part of a default installation of main Operating System/Database packages. Active Directory (AD) Primary accounts are accounts that are linked to a mailbox. After Discovery Engine 102 discovers an account and identifies the type of account, the access levels associated with the account may be identified by Policy Engine 104.

[0017] In some embodiments, Policy Engine 104 is configured to identify privileged access data related to an account. In an exemplary embodiment, privilege levels may be described as System Control, Update Data, Appropriate Access, Unvetted Access, and Sensitive Read. In other embodiments, additional and/or alternative privilege levels may be used. A user having System Control privileges can override, modify, or disable technical and security controls. A user having Update Data privileges has the ability to update code, data, database schemas, job-schedules, or other objects that could impact the availability and integrity of the company’s production systems. A user having Appropriate Access privileges can verify that a user has correct entitlements based on their job function, where this is not the case, a break is created to highlight the inappropriate access. A user having Unvetted Access privileges has a functional account which may have file level permissions that make them privileged. A user having Sensitive Read privileges has access to view or “read” personal information (PI) and/or other highly confidential data.

[0018] In some embodiments, Data Modeling Engine 106 is configured to associate privileged access data with organizational information, such as, but not limited to, applications associated with the account, support team information, and specific privileges for business units. Data Modeling Engine 106 may be further configured to integrate with various systems to provide recommendations based on the likelihood an account is a member of the various business units or has specific privileges. [0019] In some embodiments, Remediation Engine 108 is configured to implement remediation actions to single user or functional accounts as they are identified by Discovery Engine 102. Remediation actions can include, for example, Enterprise Password Vault (EPV) Break- Glass, EPV Application Identity Management (AIM), Disable/Remove, Reduce Privileges, Disable as end state, and Vetted non-privileged. In other embodiments, additional remediation actions are available. When EPV Break-Glass is the appropriate remediation action, the account can be placed under managed Break-Glass, which grants emergency privileges to an account for a limited amount of time. In some embodiments, EPV Break- Glass is only available as a remediation action for shared interactive accounts. When EPV AIM is the appropriate remediation action, the account may be placed into an application- to-application account repository. When Disable/Remove is the appropriate remediation action, the account may be set to be disabled and removed after a validation period. In some embodiments, the validation period is manually set. In other embodiments, the validation period is determined based on account characteristics and/or organizational priority. In some embodiments, the identified account is not capable of deletion, so it disabled as an end state, meaning, it will not have a validation period and will remain disabled.

[0020] When Reduce Privileges is the appropriate remediation action, individual privileges (i.e.,

System Control, Update Data, Appropriate Access, and Sensitive Read) may be removed. In some embodiments, Remediation Engine 208 is configured to determine a specific privilege causing a break and removes that privilege. Vetted non-privileged is the appropriate remediation action when an account is an unvetted account that has no associated privileges. Other remediation actions will be apparent to those of skill in the art.

[0021] In some embodiments, the appropriate remediation actions implemented by Remediation Engine 108 are defined by the type of account identified. If an account is identified as a single user account, Remediation Engine 108 may be configured to 1) disable the account with intent to remove the account at a later time (Disable/Remove); 2) Remove privileges from accounts causing breaks (Reduce Privileges); 3) Onboard into EPV Human Readable Accounts (HRA); or, 4) Split the account into a secondary account if needed. EPV

Breakglass (BG) is intended for accounts that are shared, whereas EPV Human Readable Accounts (HRA) are intended for accounts that are tied to a single user.

[0022] When an account is identified as a shared interactive account, the Remediation Engine 108 may be configured to 1) Disable the account with intent to remove at a later time (Disable/Remove); 2) Remove privileges from accounts causing breaks(Reduce Privileges); or 3) Onboard into EPV Break-Glass as a managed account.

[0023] When an account is identified as an application-to-application account, the Remediation Engine 108 may be configured to 1) Disable the account with intent to remove at a later time (Disable/Remove); 2) Remove privileges from accounts causing breaks (Reduce Privileges); or 3) Onboard into EPV AIM as a managed account. In some embodiments, onboarding into the EPV AIM requires agent interaction on the server to make

programmatic changes to request access.

[0024] When an account is identified as a hybrid account, the Remediation Engine 108 is

configured to 1) Disable the account with intent to remove at a later time; 2) Remove privileges from accounts causing breaks; or 3) Split the account into two accounts, one being a shared interactive account, the other being an application-to-application account.

[0025] In some embodiments, account lifecycle management system 100 includes a Mitigation Engine 110. Mitigation Engine 110 may be configured to implement mitigation actions to single user or functional accounts as they are identified by Discovery Engine 102. If an account is identified as a single user account, the primary mitigation option for privileged accounts is to have a documented exception with a Technology Control Officer (TCO) and other relevant approvals. In some embodiments, a TCO and an ID/ Application owner must agree to an exception that is linked to a Control Self Assessment (CSA), Risk Acceptance, or the like. If an account is identified as a shared interactive account, the primary mitigation option for privileged accounts is to have a documented exception with a TCO and other relevant approvals. If an account is identified as an application-to-application account, mitigation options include monitoring of account usage or a documented exception with a TCO and other relevant approvals. If an account is identified as a hybrid account, mitigation actions include splitting the account into two accounts or a documented exception with a TCO and other relevant approvals.

[0026] Figure 2 shows an exemplary account enrichment process 200. At step 202, an account owner may be determined. Every account must have a confirmed owner. In some embodiments, there are three methods to associate an account with an owner: 1) Owner Validation; 2) Suggested Owner Confirmation; and 3) Missing Owner Validation. In some embodiments, additional methods may be implemented to confirm ownership of an account. Owner Validation can be used to identify an account having an owner found in a Non- Employee Identity Management (NEGM), ID Owner, IDCert or EPV linked to the account. Suggested Owner Confirmation may compile a list of possible owners of an account. In some embodiments, the suggested owner list is compiled based on a calculated likelihood of ownership. This calculation may be based on a number of data points that are discovered by the ALM such as the number of hosts, applications, how often it is used, who last used it, and when it was last used. In some embodiments, the suggested owner list is compiled based on a recommendation from another party within the system. If no owner is found by either the Ownership Validation or Suggested Ownership Confirmation methods, an account can be identified using Missing Owner Validation. Missing Owner Validation may identify possible owners that own applications on the same host, and will link those owners with the account.

[0027] At step 204, a human readable description of the account is generated that describes the purpose of the account. Additional reporting may be generated based on keywords to identify common or duplicative accounts.

[0028] At step 206, the account type, such as a single user account or functional account, is

determined. In certain embodiments, all functional accounts must be categorized as shared interactive, application-to-application, or hybrid.

[0029] At step 208, an account remediation or mitigation action is taken. In some embodiments, all accounts are required to have a remediation or mitigation plan to address breaks. This process may be characterized as account enrichment. In certain embodiments the enriched account is fed into the ALM which can configure audit controls and general reporting to drive the reduction of privilege access or help monitor the adoption of the controls.

[0030] Figure 3 shows an exemplary user interface implementation of account lifecycle

management (ALM), for example system 100. In some embodiments, the user interface is referred to as a dashboard or ALM dashboard, however, the terms may be used

interchangeably. In some embodiments, the Dashboard 300 comprises at least User

Information 302, Filters 304, Access Level Information 306, and Account Detail

Information 308. User Information 302 may comprise details about a user of the ALM dashboard such as name, company ID, or organizational title or role. Additional user information may be display according to system administrator preference. Filters 304 are configured to control the types of analysis conducted by the ALM system. Filters may include, for example, OR environment, contains Prod, contains Failover, Contains DR, OR Audit, SOX equal 1, or SSAE16 equal 1, or Application equal TradeVault, or Application Owner equals Chris, or Region equals ASIAPACIFIC. These and other Filters may vary according to user preference and circumstance. Access Level Information 306 may be configured to provide details related to the access types being analyzed by Dashboard 300. In some embodiments, Account Detail Information 308 includes information about the accounts found by the ALM system, according to the Filters 304 and Access Level Information 306. Account Detail Information 308 may include information such as, for example, Ownership Breaks, Description Breaks, Account Type Validation, Application to Account Validation, and Action Not Identified. These and other types may vary according to user preference and application.

[0031] Figure 4 shows an exemplary Automation Workflow 400. The workflow ties together the discovered data with the user enriched data and which flows into the reporting and automation to remediate privileged access. Data Sources 402 is an exemplary list of Account, Entitlement, and Context Information Sources used by the ALM system, e.g. system 100. In some embodiments, Data Sources 402 are Read Only, meaning they cannot be modified by the ALM system. In some embodiments, Data Sources are both Read/Write enabled, meaning they may be modified by the ALM system. As remediation or mitigation actions are taken, certain data sources may need an updated assessment of the user profile. Ownership and Account Information 404 shows an exemplary listing of the data sources that need to be updated with account meta-data and remediation/mitigation actions as they are performed on the account. Account Removal 406 shows an exemplary listing of the data sources that need to be updated with account meta-data and remediation/mitigation actions when account removal is an appropriate remediation action. Remove/Reduce Privileges 408 shows an exemplary listing of data sources that need to be updated with account meta-data and remediation/mitigation actions when account removal/reduce privileges is an appropriate remediation action. Onboard into EPV Break-Glass 410 shows an exemplary listing of the data sources that need to be updated with account meta-data and remediation/mitigation actions when onboarding to EPV break-glass is an appropriate remediation action. It is appreciated that the data sources shown in Figure 4 are non- exhaustive, and can include more or fewer data sources. [0032] It is to be understood that the detailed description is intended to be illustrative, and not limiting to the embodiments described. Other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. Moreover, in some instances, elements described with one embodiment may be readily adapted for use with other embodiments. Therefore, the methods and systems described herein are not limited to the specific details, the representative embodiments, or the illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of the general aspects of the present disclosure.