Saturday, October 30, 2010

Choosing the right authentication method

There’s lots of talk about whether smartcards are better than one-time passwords (OTP), or is OTP easier than smartcards to implement, or is a soft-token as secure as a hard-token? I came across this article
“Proof Of Identity: How To Choose Multifactor Authentication” which had a pretty good run down on the various options, how secure each option was and how easy or hard it was to maintain those authentication methods. The article is below but there’s also a link to a white paper on the topic (requires registration) which you might find useful to read. As you can imagine, the answer to the question of which authentication method is best is “it depends”. Let me tell you how I would choose:

Ask yourself this question: Do you trust your employees? Do you run new hires through employment verification? If the answer is a basic yes then in my opinion you don’t need fancy (e.g., iris scans) or real heavy-duty strong authentication. You can get by with SMS tokens or OTP-based soft-tokens that run on your smartphone. If the answer is no, then you are more likely a government department or your firm is somehow working in a sensitive area (defense, government-related, power plant, etc.) and you are not allowed to trust your employees. In that case, go for the gusto, use a smartcard or fancy biometrics.
To control access to your Web-based applications, you need to identify and authenticate anyone wishing to use them -- that is, verify they are who they say they are. But how do you choose the right method of authentication? There's the rub.
Why do you need to implement strong or two-factor authentication for your Web applications? First, lawmakers have pushed security to the top of the agenda, and strong authentication is part of that agenda. Laws such as Sarbanes-Oxley and requirements such as PCI DSS mean single-factor authentication is no longer adequate for protecting access to high-value or personally identifiable information and providing reliable audit trails.
Second, any organization that sees customer trust as a business priority needs to provide secure authentication, and the password approach doesn't do that. Many organizations, though, are wary of implementing strong authentication due to its perceived cost. However, managing passwords can be expensive, too. They provide too low a level of trust to be considered a viable option where assets of any value are involved.
And the situation's getting worse. The growing use of number-crunching power of modern graphics cards to carry out brute-force attacks will soon make it trivial for hackers to crack strong passwords. Adding a second-factor credential to the authentication process provides additional security as well as a higher level of trust between a user and an application. Let's look at some of the options for authenticating users to Web applications.
The technologies for implementing strong Web authentication are:
  • Soft or hard digital certificates
  • One-time passwords (OTP)
  • Challenge-response
  • Authentication-as-a-service (AaaS)
Management is going to want a solution that's effective, flexible, and scalable, and can be implemented with minimum disruption and cost. Your customers, on the other hand, will want a solution that not only offers increased security but is easy to use.
There are three key factors to consider when choosing the right solution: time, risk and cost. If you know what your users will bear in terms of time to log on, and if you can weigh the risks associated with each method against its costs, you will find the solution that fits best for your applications.
For a detailed discussion of how to evaluate these factors and how they stack up against the various alternatives in Web authentication, download the full report.

Saturday, October 23, 2010

Integrating Unix and Linux Systems with Quest’s IAM Platform - Voelcker ActiveEntry

It’s been nearly a month since my last blog post. Things have been very busy and hectic to say the least, but I figured it was time to get back to posting so here goes...

One of the things that many people on the IAM team here at Quest have been working on is integrating various aspects of the current Quest IAM portfolio with our latest acquisition – Voelcker ActiveEntry. In my last post I talked about the integration of Microsoft’s Forefront Identity Manager (FIM) product with ActiveEntry.

In the screen shot below you can see that we have made more progress and have integrated Unix/Linux systems and identities into ActiveEntry. Fortunately, the design of ActiveEntry and our Unix/Linux identity products allows us to easily integrate these capabilities together into the ActiveEntry platform. A very valid question that anyone might ask is if this is simply showing the features of one product in another? The answer is definitely “no”, in fact it is much more.

By leveraging ActiveEntry’s capabilities and the web services interfaces in our Unix/Linux products it’s fairly easy for us to enable the integration but more importantly to provide some real value-add. Let me give you just a few examples of that value add:
  • Independent but integrated: Based on your role use the interface you prefer. An Unix/Linux administrator may prefer the straight-forward web interface that’s built into Quest Identity Manager for Unix (a free download by the way) while an end-user or business manager might prefer the more business/task oriented interface of ActiveEntry (below).
  • Enable end-user self-service: The integration with ActiveEntry enables Unix/Linux servers to be made available in the “Shop” interface so an end-user can request access to a particular Unix/Linux server by their individual server names or perhaps by the business application that is being hosted on that machine.
  • Approvals through integrated workflow: Once someone has shopped for a Unix/Linux server or business application a workflow request can be sent to the appropriate approval manager or administrator. Or, perhaps you’d like all request to be automatically approved? Depending on your compliance requirements you have the power to make that choice.
  • Enhanced compliance: By tying the approval process into ActiveEntry’s compliance capabilities you can do things like run reports to determine who requested access to a Unix/Linux server, who approved the access, etc.
  • Separation of Duties: Integrating Quest’s Unix/Linux identity products into ActiveEntry enables the system to have an all-up view of the many identities across your enterprise including other systems like HR, your Active Directory account information, group memberships, etc. All of this information can be used by ActiveEntry to perform separation of duties (SoD)checks when someone requests access to a Unix/Linux server. You can prevent the administrator of a Unix/Linux server from being the same person who approves access, for example. Or, you could check to ensure that members of a particular group in Active Directory (e.g., contractors) could not request a Unix/Linux account without additional approvals.
This example of how we are integrating Quest Identity Manager for Unix with ActiveEntry is just one of many product integrations that are underway right now. I will definitely showcase more of these examples so you can get the feel of how we’re leveraging the capabilities of ActiveEntry.