| Page Properties | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Question
Should Application Administrators be considered as Privileged Accounts?
Short Answer
Yes.
Full Answer
We may approach this question from two perspectiveperspectives:
An ontological viewperspective, i.e. is the Application Administrators concept a subset of the Privileged Accounts concept?
A pragmatic viewperspective, i.e. should Application Administrators be managed any differently than technical Privileged Accounts?
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 SDLClife-cycle. They obviously play a maintenance role during the Manage and Monitor phase active life of the application but Nagaratnam et al., 2005 shows reminds us that they also typically play a role during the Deploy deployment phase along with of the Security Administratorapplication. That is to say, they may need to intervene on the application with their privileged Application Administrator accounts before any single business user ever logged into itthe application.
In Royer, 2010, Royer explains 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 onboarding on-boarding stakeholders early on in the project. As part of this research, Royer interviewed integrators, vendors and users have been interviewed and established a high-level classification of IAM stakeholders has been established from these. Interestingly, the Actual Users stakeholder category expressly contains both the business users and application administrators distinctively Business Users and Application Administrators and is distinct from the IT departmentstakeholder.
This shows that Application Administators may or may not be Privileged Accounts but 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 as part of by the assessment. The table columns depict the People, Processes and Technology dimensions while the rows correspond to . The rows lists the organization units. In this classificationmatrix, 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 Business row along with the access management, joiner, mover, leaver and recertification processes.
In summary, Osmanoglu doesn't expressly state that distinguishes Application Administrators aren't from Privileged Accounts but . He 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 further states that Application Administrators are managed by PAM solutions.
Here, The model defines Application Administrators are defined as:
Accounts which have full administrative privileged capabilities within individual applications.
Along the In this model, account categories are ordered to respectively two dimensions: 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 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 but within the boundaries of an individual application (assuming .
An important assumption here is that no lateral movement is possible from therethe application, an hypothesis that may not be true with certain applications, e.g. through integration with access may spill out on the host or on other systems via integration features (e.g. reconfiguration of SQL queries where injection is possible). A prudent approach would thus implement 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. But typical e. PAM controls). But some of these controls, such as the on-boarding and maintenance of these accounts in a PAM solution with its accompanying processes 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 may be optimized for cost reduction by making them should be proportional to that level of risk and optimized in terms of cost. This leads us to conclude that yes, relaxing of PAM controls may be considered 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 possible often rather easy to implement strict network policies enforcing the usage of a bastion or PAM solution to access a technical component . For 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 the business users to the application will be legitimate but the is mixed with the network traffic of the Application Administrators would constitute . 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 often typically 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 accountstheir 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 account for 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 concluded from considered in the light of a risk analysis and must not be assumed a priori.