Question
Should Application Administrators be considered as Privileged Accounts?
Short Answer
Yes.
Full Answer
We may approach this question from two perspective:
An ontological view, i.e. is the Application Administrators concept a subset of the Privileged Accounts concept?
A pragmatic view, i.e. should Application Administrators be managed any differently than technical Privileged Accounts?
Literature Review
An interesting aspect of Application Administrators that should be considered is the role they play at different phases of the application SDLC. They play a role during the Manage and Monitor phase butNagaratnam et al., 2005 shows that they also play a role during the Deploy phase along with the Security Administrator. That is to say, they may need to intervene on the application before any single business user logged into it.
In Royer, 2010, Royer explains 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 onboarding stakeholders early on in the project. As part of this research, integrators, vendors and users have been interviewed and a high-level classification of IAM stakeholders has been established from these. Interestingly, the Actual Users category expressly contains both the business users and application administrators distinctively from the IT department.
This shows that Application Administators may or may not be Privileged Accounts but 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 as part of the assessment. The table columns depict the People, Processes and Technology dimensions while the rows correspond to organization units. In this classification, 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 with access management, joiner, mover, leaver and recertification processes.
In summary, Osmanoglu doesn't expressly state that Application Administrators aren't Privileged Accounts but shows at least that Application Administrators are of a particular nature whose domain is limited to Business Applications and are owned by the business rather than that of 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 expressly states that Application Administrators are managed by PAM solutions.
Here, Application Administrators are defined as:
Accounts which have full administrative privileged capabilities within individual applications.
Along the risk and # of users dimensions, Application Administrators is placed right in the middle.
Interestingly, this model proposes an intermediary class between standard application users and privileged accounts: Powerful Accounts where we find application super users, database users and platform remote access users.
Conclusion
Application Administrator accounts, by definition, are privileged accounts but within the boundaries of an individual application (assuming no lateral movement is possible from there, an hypothesis that may not be true with certain applications, e.g. through integration with the host or other systems).
A prudent approach would thus implement the same controls on Application Administrator accounts than the ones implemented on Technical Administrator accounts. But typical controls, such as the on-boarding and maintenance of these accounts in a PAM solution with its accompanying processes may be expensive.
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 may be optimized for cost reduction by making them proportional to that level of risk. This leads us to conclude that yes, relaxing of PAM controls may be considered on Application Administrator accounts in the light of a risk analysis.
Another interesting aspect of Application Administrator accounts is that in certain circumstances they may be more difficult to control than Technical Administrator. For instance, it is possible to implement strict network policies enforcing the usage of a bastion or PAM solution to access a technical component. For business applications, especially when the application administration console is mixed into the business UI, the network traffic of the business users to the application will be legitimate but the network traffic of the Application Administrators would constitute a bypass of the bastion or PAM solution. This must be analyzed application by application and compensatory controls need to be considered.
Being often owned by business functions, Application Administrators are often used by populations that may be less acquainted with or cognizant of the risks and security controls required to prevent the unauthorized use of these accounts. The secure management of these accounts throughout their life cycle may thus require a distinct approach from the one used for technical privileged accounts to account for 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 concluded from a risk analysis and must not be assumed a priori.
