Johannesburg, 06 Jun 2013
Around five years ago, identity management was the flavour of the month, which organisations were trying to implement.
As this industry has matured, so companies have begun implementing access governance technologies, ensuring that the process of management, fulfilment and revoking of access privileges is now thoroughly managed, at least as far as people goes.
However, by its nature, technology is largely silicon-based, and as such, there are numerous machine-to-machine interactions that are governed by privileged accounts, which enable these systems to function correctly.
Privileged accounts are a standard part of the installation process for operating systems, databases and applications. These accounts are utilised by system administrators to perform their jobs, by granting them special system privileges.
The problem lies in the fact that privileged accounts generally have very little accountability, since they do not belong to an individual user, instead being shared by a range of administrative employees. Moreover, since these accounts have elevated access rights, they enable those with access to bypass internal controls, which in turn could enable such users to breach confidential information, change transactions and destroy audited data.
Moreover, it is seldom only one administrator that requires access to a given system; since several different administrators tend to require the same access, it adds to the security complications, in that many people may need to know the same password. This, in turn, makes it difficult to co-ordinate changes to the password, as locking one or more of the administrators out of the system - albeit accidentally and temporarily - could nonetheless have disastrous consequences. For this reason, administrator passwords are often not subjected to the same rigorous security measures as normal user passwords, thereby making them effectively less secure than user passwords.
Furthermore, in addition to those privileged accounts used by IT system administrators, there are also privileged accounts used by applications when connecting to one another. Web applications, for example, generally make use of a login ID and password to connect to directories, databases and Web services. These accounts carry their own security risks in the form of embedded passwords that are often stored in unencrypted text files. In other words, if an intruder compromises the security of the operating system where the application is installed, they will also compromise the integrity of the network services, which the application connects to.
In much the same way as multiple administrators may need access to the same password, applications that are replicated across multiple servers may house their own copies of the same plaintext login IDs and passwords. This makes it particularly challenging to change passwords, as any alterations need to be co-ordinated between a back-end system and multiple instances of a front-end system.
Lastly, there are also numerous unattended processes on Windows systems that operate with a login ID and password. These would include scheduled tasks, service accounts and more. Since many applications only work when these services have elevated privileges, this creates additional business risk.
Any change made to a service password has to be carefully co-ordinated with every service which uses the account. For example, where a service program runs using Active Directory credentials, a change to a single password in Active Directory could cause a knock-on effect that triggers the need to notify many Windows components, on many computers that participate in the Active Directory domain, of the new password.
So the question then is how does an enterprise effectively manage the security and access issues around privileged accounts? Unlike identity management and access governance, which has matured to the point where these technologies enable businesses to effectively manage their people risk, privileged and service accounts are not linked to people.
The simple answer to the question, then, is to link these accounts to people. A privileged account management (PAM) solution can be used to change the password at regular intervals, to something no human would know, and to then store this centrally, checking the password out to a user only when it is required.
Obviously, if it needs to be configured in numerous locations, the PAM system can be used to push the new password out to these text files in a variety of ways. It could, for example, configure applications to query the password via an application programming interface (API), or it could push the new password into a configuration location like a text or XML file, or a registry setting on the server.
Ultimately, the real challenge in approaching PAM in this manner lies not in the technology, but in the process of identifying the administrator and service accounts, the policy that should be applied to these accounts, and the locations where these account credentials are being used or configured.
The overall approach to managing silicon-based (machine) accounts is very similar to that of managing carbon-based (people) accounts. The technology certainly exists to do this, but the key that brings all this together is having a strong methodology that allows the organisation to identify administrator and service accounts that are not linked to people. They must also develop an identity policy that can be linked to the management of these accounts.
Finally, the organisation needs to identify who can request access to these accounts, how they are granted access, how long the access should be granted for, and finally, if they need to configure the application, service or database with a new password, it is vital to define the configuration locations for the credentials.
From a technology perspective, PAM is a whole new solution. In reality, however, it is nothing more than the next step on the ever-evolving access governance roadmap. PAM takes the basic principles of access governance that allow organisations to effectively manage people well and applies the extensive knowledge and understanding around the management of carbon-based access to that of silicon-based access.
Share