Traditionally, Identity and Access Management (IAM) involves managing Joiners, Movers, Leavers (JML) processes, user access reviews, standard user and privileged accounts management.
"Active Directory accounts that have not been used in the last 90 days should be disabled or flagged up for further review by the operations or cyber-defense teams"
Today, there are industry leading tools and standards that deal with these processes in small to large scale enterprises. These tools and standards are typically geared towards making these common IAM processes more efficient and user friendly. However, they do not always provide effective controls for the full spectrum of IAM use cases.
When attackers want to penetrate a network, they often target and exploit accounts that are under-managed when compared to the more mature processes used to manage active user accounts. Without well-defined, mature management processes there is a greater risk of account compromise. Service accounts, orphan accounts, and dormant accounts pose significant risk if they are not managed securely and effectively throughout their lifecycle. Below are some best practices to keep in mind:
Service accounts: A service account is a special type of account intended to represent a non-human user that needs to access other services/ systems or data on an application or platform. Examples: software running on application servers will use a service account to access a Database via Java Database Connectivity (JDBC).
The key characteristic of a service account is its persistence beyond the tenure of an individual employee within the organization, i.e. the service account needs to be continuously managed even after the person owning the service account leaves the organization. Service accounts are typically not deleted or disabled, unless no longer needed, and if they are not managed with care, then they may begin to impact production services.
• Managing the Service Accounts Lifecycle: Like user accounts, an effective service account lifecycle management process needs to be defined and implemented. Lifecycle management should include approval, creation, deletion and periodic reviews of service accounts. Since the service accounts are non-user accounts and cannot be easily tied to an identity, lifecycle management becomes more challenging.
There are a few options to overcome these challenges, such as creating the service accounts in a separate Organizational Unit (in Active Directory, for example) or the assignment of an account attribute (such as type=service). A better way to detect a service account is at the origin and time of request, via a request portal. Once a request is approved, the details of the service accounts along with the owner information must be stored in a Configuration Management Database (CMDB.).
Once service accounts are created in such a way that they can be distinguished from regular accounts, then these accounts should be read and represented in the IDM system. The representation in an IDM system can vary from linking the service accounts to an application owner, creating a standalone identity for each Service Account, or creating a persona identity for each User/Owner. For example, to manage serviceaccnt1_app1, serviceaccnt2_app1 etc., a persona identity (e.g.: “John_persona”) is created in the IDM to represent the owner and all the service accounts are linked to this identity. Each of these options could have pros and cons depending on the complexity and the technical landscape of an organization. A suitable option should be chosen that can tailor to the needs of an organization. The key concept behind any approach is tying service accounts to accountable individuals and processes, regardless of whether personnel change.
Once the service accounts are represented in the IDM system, then regular access reviews can be performed so that the validity and the need for those service accounts can be attested by the application owner. In addition, once an application owner moves roles or leaves the organization, the transfer of ownership of the service accounts can be efficiently managed.
Finally, to ensure effective oversight, the service account passwords should be stored in a secure safe and rotated regularly.
Orphan and Dormant Accounts: Orphan accounts are those that are active but not associated with a valid identity (this usually happens when someone leaves the organization and their identity is revoked but some of their downstream application accounts are not revoked). These accounts could be misused by an attacker or malicious insider to elevate their access in the target system. As these accounts are not tied to an active identity, usage of these accounts will go undetected. Dormant accounts are those with no recent login activity and which have not been used for a while. These accounts are also attractive targets for hackers, because the account owner isn’t going to notice account activity.
• Managing Orphan and Dormant accounts: Lately, industry leading IDM vendors have incorporated features to detect orphan accounts from the target systems and applications provided when these targets are enrolled in the IDM tool. After enrolling the target application/system in the IDM system, when the IDM tool reconciles or reads the accounts/ entitlements from the target, a process can be established to detect orphan accounts. This process could involve generating reports of accounts that are not associated with an identity (filtering system level and default accounts), creating risk exceptions and passing it to operations for further analysis. The process could be further enhanced by automating the detection and remediation of these accounts by leveraging the features of the IDM tools.
In addition, a number of IDM tools also provide out-of-the-box options to deal with dormant accounts. Some of these options include configuring rules to detect accounts that have not been used for a certain number of days, then creating alerts or reports to further review these accounts with line managers or the cyber-defense team. For example: Active Directory accounts that have not been used in the last 90 days should be disabled or flagged up for further review by the operations or cyber-defense teams.