AIM

The benefit of multifactor authentication for privileged accounts

Let’s say you work at a larger company with the demands from ISO 27001/27002, and start looking at privileged accounts. The standard 27002 states under the heading “Privilege management Control” that “The allocation and use of privileges should be restricted and controlled”. There are of course several different approaches to this, and a series of actions that need to be taken into account in order to give users minimum requirement of privileges for their functional role only when needed.

But a good step on the way is to start using smart cards for the authentication of privileged accounts. Everybody agrees that passwords belong to the past, and many larger organizations have already (often several years ago) made the transition to smart card login. But often with a significant exclusion – administrative accounts still use password login. The reasons for this are many – requiring smart card login for a high privilege account is regarded as an availability risk, legacy equipment or/and administrative applications don’t support smart card authentication, sourcing partners delivers Infrastructure as a service in a private cloud to the organization often coupled with services requiring administrative logon to servers and so on. These reasons are often coupled with the misconception that IT-technicians and engineers continued use of passwords for authentication is a lesser risk since they have higher awareness about password length and complexity as well as how to store such passwords.

Apart from the obvious security gain of implementing an extra factor for authentication, I personally believe that the major benefit of implementing smart card login for privileged accounts is the homogenization of processes for attaining privileged access. While the process of attaining a regular account is controlled through order systems with attestation from the employee’s manager, domain administrative accounts and other high privilege accounts are attained through informal processes that bypass the rule set in place to comply with internal policies and regulatory demands. As for sourcing partners, these are often given delegated administrative rights for their part of the organizations servers, and the process for how the sourcing partner manages the lifecycle of privileged accounts is a black box to the customer.

Is this approach realistic? I firmly believe so. Sourcing partners are starting to see the benefits of working together with their customers in regards to security, creating a warmer climate for these type of projects, while regulatory bodies are placing increasing demands on the protection of high privilege accounts, resulting in less political obstacles both from outside and inside the organization. Legacy equipment requiring password can be isolated behind jump stations that require smart card login, and more and more solutions support smart card authentication. For example – ILO 2 supports an authentication scheme using a browser, where access to the OS on a remote server use smart card device support within Windows Remote Desktop Connection. ILO uses Terminal Services pass-thru to access Remote Desktop Connection. Another example is VMware vSphere 5.0 that support Smart card reader support for virtual machines.

As the climate for change is right, and the technical prerequisites for success are available, the time for leaving passwords altogether is ripe. Just remember that the interfaces you use for supporting the processes of lifecycle management of privileged accounts might need integration with a whole lot of systems, and might not be well suited for placement in the cloud – but that is another blog, I think.

 

Mårten Thomasson

Posted in Blog.