\newpage \subsection*{Orphan Account } \subsection*{Alternative Forms } \begin{enumerate} \item  Dormant Account  \item  Orphan  \item  Orphaned Account  \item  Uncorrelated Account  \end{enumerate} \subsection*{Definitions } \begin{DIC_Def}{Definition 1Workforce IAM }{} \paragraph{} A nominative user account not linked to an active employee.  Note  1  incomplete  Document account removal / deactivation best practice  \end{DIC_Def} \begin{DIC_Def}{Definition 2Technical IAM }{} \paragraph{} A technical account without a clearly designated account owner.  Note  2  incomplete  Document technical account ownership best practice  \end{DIC_Def} \begin{DIC_Def}{Definition 3IAM, Systems Requiring Declaration of User Accounts in Multiple Sub-Systems }{} \paragraph{} An out of order user account because it is not declared in all the sub-systems where declaration is required by the parent system.  Example  \paragraph{} In Microsoft SQL Server, users are declared in the database as  \emph{ database users  } and in the Microsoft SQL Server instance as  \emph{ SQL logins  } . A  \emph{ database user  } without a corresponding  \emph{ SQL login  } is out of order, it is an  \emph{ orphaned user  } .  Note  \paragraph{} \emph{ Orphaned accounts  } constitute a security risk as they may potentially be used in unauthorized ways. In consequence the best practice consists in removing these users. See  (link) \href{OM-BP-0017: Remove orphans in systems requiring the declaration of user accounts in multiple sub-systems (Best Practice) }{ } .  \end{DIC_Def} \subsection*{Related Terms } \begin{enumerate} \item  (link) \href{Account (Dictionary Entry) }{ }   \item  Account Correlation  \item  Account Owner  \item  Dormant Account  \item  \href{None }{https://open-measure.atlassian.net/wiki/spaces/DIC/pages/123830932?search\_id=842b8b34-9586-4226-8b8b-f12824c7361b }   \item  (link) \href{Identity (Dictionary Entry) }{ }   \item  Leaver Process  \item  Mover Process  \item  Nonperson Account  \item  (link) \href{Orphan (Dictionary Entry) }{ }   \item  (link) \href{Orphan Role (Dictionary Entry) }{ }   \item  \href{None }{https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67699046?search\_id=d377746f-b274-4bc7-83fa-ef90d7476ae2 }   \item  Unused Account  \end{enumerate} \subsection*{Quotes } \begin{DIC_BlockQuote} IGA concerns the capabilities in IAM market that broadly deal with end-to-end identity life-cycle management, access entitlements, workflow and policy management, role management, access certification, SOD risk analysis, reporting and access intelligence. As IGA becomes an important security risk and management discipline directly impacting the security posture of any organization, a lack of basic IGA capabilities can leave organizations exposed to risks originating from inefficient administration of identifies and access entitlements, poor role management and lack of adequate auditing and reporting. These risks range from identity thefts to unapproved and unauthorized changes, access creeps, role bloating, delays in access fulfilment, orphan roles and accounts, SOD conflicts leading to occupational and other internal frauds. Several incidents in recent past have emphasized the need to have better IGA controls for organizations of all sizes, across all industry verticals.  \end{DIC_BlockQuote} (Kuppinger and Hill, 2020, p. 5-6)  \paragraph{} (  (link) \href{Kuppinger and Hill, 2020 }{ } , p. 5-6)  \begin{DIC_BlockQuote} Uncorrelated accountsAlso known as orphan accounts, uncorrelated accounts often occur when there's a change in an employee's status, typically when they leave the company. A good IAM system should be able to identify such accounts because they'll display an abnormal amount of inactivity. It's important to close them down because they pose a security risk. "They're ripe for attack if they're not controlled," warns <NAME>, CTO of BeyondTrust, a maker of privileged account management and vulnerability management solutions."Many IAM programs have achieved a high level of proficiency in provisioning access to resources," adds Stealthbits' Laub. "Few, in comparison, have achieved the same level of proficiency in removing access in a complete fashion or transferring access rights when job assignments change."  \end{DIC_BlockQuote} (Mello, 2020)  \paragraph{} (  (link) \href{Mello, 2020 }{ } )  \begin{DIC_BlockQuote} Correlation and Orphan AccountsAs discussed, the overall goal of an Identity Governance (IG) project is to understand and manage the relationships between people, access, and data. At the core of this goal is the logical connection between an account, token, or credential (the access) and a real human being. The ongoing process of connecting people to accounts and access is called correlation and is shown in Figure 7-1. In the ideal world, every account matches up perfectly with a human (identity), and you have 100\% correlation (for the record, that's something we never see out of the gate). Account access that does not correlate back to a known user is often referred to as an orphan account. Orphan accounts can be a significant security weakness. Post-breach forensic analysis shows that the adversary creates and uses new accounts throughout the cyber killing chain. It is therefore essential for ongoing governance and security to instrument, and, if at all possible, to automate, the detection and rapid resolution of orphan accounts.The presence of system, functional, privileged, and application accounts poses a significant challenge to this process. The accounts and privileges used for system-to-system access and the administration of the IT infrastructure are rarely if ever directly correlatable to a known user without a dedicated process. In large ecosystems, there can be hundreds and potentially thousands of accounts that will not correlate without a deliberate and specific process of managed correlation. An enterprise-grade IG solution will provide core product capabilities to help either manually or automatically resolve these issues. Manual correlation using graphical ``searching and connecting'' will greatly help the admin establish and maintain links between known owners and orphan accounts. Automated matching algorithms can also help suggest relationships and potential connections. This automated discovery technology can also provide important insights around the integration with Privileged Account Management (PAM) solutions. Finding privilege and directing the PAM solution to take control of the account can be a significant win. Chapter 13 provides more details on the best practices around the integration between PAM and IG solutions.  \end{DIC_BlockQuote} (Haber and Rolls, 2020, p. 58-59)  \paragraph{} (  (link) \href{Haber and Rolls, 2020 }{ } , p. 58-59)  \begin{DIC_BlockQuote} IGA(\ldots) • Identification of dormant/orphan accounts  \end{DIC_BlockQuote} (Diodati and Ruddy, 2017, p. 17-18)  \paragraph{} (  (link) \href{Diodati and Ruddy, 2017 }{ } , p. 17-18)  \begin{DIC_BlockQuote} Lack of Business AlignmentThis is commonly understood as a problem, but difficult to address. Most presentations that Gartner reviewed ignore the business impact beyond generally tying it to FUD. Those that do address it make poor connections between security problems and business impact, such as orphan accounts that negatively affect profitability. This leads to a lack of credibility and defensibility, and erodes board support, perpetuating the notion that this is not the board's issue (see "Five Tips for Security and Risk Leaders When Communicating With Business Stakeholders").  \end{DIC_BlockQuote} (Proctor et al., 2017, p. 7)  \paragraph{} (  (link) \href{Proctor et al., 2017 }{ } , p. 7)  \begin{DIC_BlockQuote} Another significant security concern is identity life cycle and de-provisioning. When people leave the organization, who removes their accounts and permissions on cloud services? This removal can be a considerable identity management challenge, and is a major business driver for enterprises deploying identity and access management capabilities. In the absence of automation, the enterprise will have to rely on manual procedures. With manual procedures, periodic audits should be performed to clean up orphan accounts and excessive permissions.  \end{DIC_BlockQuote} (Donaldson et al., 2015, p. 115)  \paragraph{} (  (link) \href{Donaldson et al., 2015 }{ } , p. 115)  \begin{DIC_BlockQuote} The business can also provide input on whether all accounts reviews are properly assigned. This is particularly important when managing orphan and nonperson accounts that require an owner for designation prior to review. An orphan account is an account belonging to a user who has since left the organization.To help support the cleanup of orphan accounts, coordination and support are typically leveraged from a combination of system teams, application teams, and business owners to identify and properly associate the correct individuals to maintain accountability for the account.  \end{DIC_BlockQuote} (Gazos and Osmanoglu, 2013, 454-455)  \paragraph{} (  (link) \href{Gazos and Osmanoglu, 2013 }{ } , 454-455)  \begin{DIC_BlockQuote} 6.6 Configuration vulnerabilities (Category VCF)(\ldots)Indicators associated with events belonging to this category measure the frequency of occurrence of these vulnerabilities, highlighting deviations in the application of the standard security policy by network or system administrators or shortcomings of these standard configurations. For that purpose, 9 special kinds of configuration vulnerabilities have been selected (representing 5 different families):(\ldots) • Family VCF\_UAC (Access rights not compliant with the security policy, access rights on logs in servers which are sensitive and/or subject to regulations not compliant with the security policy, generic and shared administrator accounts that are unnecessary or accounts that are necessary but without patronage accounts without owners -- dormant or orphan accounts -- that have not been erased, accounts inactive for at least 2 months that have not been disabled)  \end{DIC_BlockQuote} (ETSI GS ISI 002, 2013 ,p. 32-33)  \paragraph{} (  (link) \href{ETSI GS ISI 002, 2013 }{ } ,p. 32-33)  \begin{DIC_BlockQuote} Assess Identity RisksOrganizations that are able to identify and assess identity related risks are said to be in a better position to protect their intellectual property (IP). User access to applications should have a clear process for granting access with emphasis on associated business risks. . Some of the risks arising from orphan accounts, shared accounts, test accounts and accounts of temporary workers are often not handled effectively. One of the options to handle risk is to first assign scores to the risks associated with each of the applications and their entitlements. Once the risk scoring is in place, collecting this data and combining it with the identity data will help in identification of high risk profiles. Additionally, effective Joiner-Mover-Leaver (JML) processes and monitoring of policy violations across applications help in reducing risks and maintaining control.By utilizing the identity intelligence gathered as part of the IAG program, threats from insiders can be addressed by initiating proactive measures. For example, if an employee with high risk value is expected to be terminated from service, then steps can be taken to curtail his access before his actual termination date.  \end{DIC_BlockQuote} (Hurakadli and Sridhar, 2012, p. 5)  \paragraph{} (  (link) \href{Hurakadli and Sridhar, 2012 }{ } , p. 5)  \begin{DIC_BlockQuote} A database user for which the corresponding SQL Server login is undefined or is incorrectly defined on a server instance cannot log in to the instance. Such a user is said to be an orphaned user of the database on that server instance. A database user can become orphaned if the corresponding SQL Server login is dropped. Also, a database user can become orphaned after a database is restored or attached to a different instance of SQL Server. Orphaning can happen if the database user is mapped to a SID that is not present in the new server instance.  \end{DIC_BlockQuote} (Microsoft, 2010)  \paragraph{} (  (link) \href{Microsoft, 2010 }{ } )  \subsection*{Bibliography } \begin{enumerate} \item  (link) \href{Diodati and Ruddy, 2017 }{ } \item  (link) \href{Donaldson et al., 2015 }{ }   \item  (link) \href{ETSI GS ISI 002, 2013 }{ }   \item  (link) \href{Gazos and Osmanoglu, 2013 }{ }   \item  (link) \href{<NAME>, 2020 }{ } \item  (link) \href{Hurakadli and Sridhar, 2012 }{ } \item  (link) \href{<NAME>, 2020 }{ } \item  (link) \href{Mello, 2020 }{ }   \item  (link) \href{Microsoft, 2010 }{ } \item  (link) \href{Proctor et al., 2017 }{ } \end{enumerate} \subsection*{See Also } 