...
Question
...
Title
Should Application Administrators be considered as Privileged Accounts?
Short Answer
Yes.
Full Answer
We may approach this question from two perspectives:
An ontological perspective, i.e. is the Application Administrators concept a subset of the Privileged Accounts concept?
A pragmatic perspective, i.e. should Application Administrators be managed any differently than technical Privileged Accounts?
...
Version
...
1.0
...
Summary
...
See also
Title
...
Both perspectives will be discussed here.
Literature Review
An interesting aspect of Application Administrators that should be considered is the role they play at different phases of the application life-cycle. They obviously play a maintenance role during the active life of the application but Nagaratnam et al., 2005 reminds us that they typically play a role during the deployment phase of the application. That is to say, they may need to intervene on the application with their privileged Application Administrator accounts before any business user ever logged into the application.
Royer, 2010 reports how the introduction of Enterprise Identity Management Systems (EIdMS) in organizations is expensive and challenging for organizations beyond technological matters. He explains that EIdMS investments are of a hybrid nature situated between security and productive IT and stresses the importance of identifying and on-boarding stakeholders early on in the project. As part of this research, Royer interviewed integrators, vendors and users and established a high-level classification of IAM stakeholders. Interestingly, the Actual Users stakeholder category contains both Business Users and Application Administrators and is distinct from the IT stakeholder.
This shows that Application Administrators are commonly owned by the business rather than IT.
In Osmanoglu, 2013, Osmanoglu proposes an approach to assess the current IAM state in an organization against a proposed IAM capability model.
He stresses the importance of the assessment inclusiveness or comprehensiveness. To help in this process, he proposes a systematic table of topics that should be covered by the assessment. The table columns depict the People, Processes and Technology dimensions. The rows lists the organization units. In this matrix, Privileged Users (People) and Management of privileged accesses (Process) are placed in the IT and System Owners row along with all technical systems. In contrast, Application Administrators (People) and Business Applications (Technology) are placed in the Lines of Business row along with the access management, joiner, mover, leaver and recertification processes.
In summary, Osmanoglu distinguishes Application Administrators from Privileged Accounts. He shows that Application Administrators are of a particular nature whose domain is limited to Business Applications and are owned by the business rather than IT.
In KPMG, 2018, KPMG proposes a classification of digital accounts. In this classification, the set of privileged accounts expressly comprises Application Administrators. The model further states that Application Administrators are managed by PAM solutions.
The model defines Application Administrators as:
Accounts which have full administrative privileged capabilities within individual applications.
In this model, account categories are ordered to respectively two dimensions: risk and # of users. Application Administrators is placed right in the middle.
Interestingly, this model proposes an intermediary class between Standard Application Users and Privileged Accounts (which comprises Application Administrators): Powerful Accounts where we find application super users, database users and platform remote access users.
Conclusion
Coming back to our ontological perspective, Application Administrator accounts are privileged accounts by definition. But they are privileged accounts within the boundaries of an individual application.
An important assumption here is that no lateral movement is possible from the application, an hypothesis that may not be true with certain applications, e.g. access may spill out on the host or on other systems via integration features (e.g. reconfiguration of SQL queries where injection is possible). It should be noted that determining with an adequate level of assurance that lateral movements are not possible from an application is not trivial.
Looking at it from a pragmatic perspective, a prudent approach consists in implementing the same controls on Application Administrator accounts than the ones implemented on Technical Administrator accounts (i.e. PAM controls). But some of these controls, such as the on-boarding and maintenance of these accounts in a PAM solution with session recording may be expensive to implement.
Maintaining our assumption of no possible lateral movement, the inherent risk represented by Application Administrator accounts is upper bounded by the inherent risk represented by the application itself, which may widely vary from application to application. The controls implemented to secure these accounts should be proportional to that level of risk and optimized in terms of cost. This leads us to conclude that yes, starting from the high level of control imposed on Technical Administrator accounts, it is possible to relax controls on Application Administrator accounts in the light of a risk analysis that balances control costs and residual risk.
Another interesting aspect of Application Administrator accounts is that in certain circumstances they may be more difficult to control than Technical Administrator accounts. For instance, it is often rather easy to implement strict network policies enforcing the usage of a bastion or PAM solution to access a technical component that should only be accessed by engineers. But for business applications, especially when the application administration console is mixed into the business UI, the legitimate network traffic of business users is mixed with the network traffic of Application Administrators. Preventing a bypass a bypass of the bastion or PAM solution may not be easily accomplished and may need to be compensated with a detective control. This must be analyzed application by application and compensatory controls need to be considered in the light of a risk analysis.
Being often owned by business functions, Application Administrators are typically used by populations that may be less acquainted with or cognizant of the risks and security controls required to prevent their unauthorized usage. The secure management of these accounts throughout their life cycle may thus require a distinct approach and communication / training plan from the one used for technical privileged accounts to manage these distinct stakeholders.
In conclusion, Application Administrator accounts are privileged accounts, but they have distinct characteristics from Technical Administrator accounts. A key characteristic is that they may represent lower risks which may justify relaxing control requirements, but this must be considered in the light of a risk analysis and must not be assumed a priori.