Despite widespread use of token-based authenticators and the rise of alternative technologies, such as image-based authenticators, the burden and pain of token authentication management is still not being adequately addressed. as we see it, this burden is not just in the provisioning and deployment of the hardware solution (a very real cost indeed), but is often discovered later, as a the administrative costs begin to show through increased support calls, token failures and losses, synchronization issues, and other “hidden costs”. It is often this “lifecycle” approach to the cost structure that is causing organizations to look into other forms of multi-factor authentication. Unfortunately, many of the same issues exist with all technologies that rely on the “something you have” portion of multi-factor authentication. This has spurred the emergence of lightweight alternatives that rely upon image catalogs. While not yet fully endorsed by the security and audit community, these solutions are gaining traction with organizations that have a large customer facing application base that needs to enforce stronger authentication requirements. Most notably, they are using this as a stopgap measure to satisfy FFIEC guidance for banking institutions.
While there is common understanding among security professionals regarding multi-factor authentication, there appears to be confusion when discussing these types of technologies with auditors and standards bodies. This creates ambiguity in the expectations and how they are managed to satisfy control requirements. Despite guidance last year by the FFIEC that clearly states their view on what constitutes multi-factor authentication:
"By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category at different points in the process may be part of a layered security or other compensating control approach, but it would not constitute multifactor authentication."
Perhaps because of this perceived ambiguity, or a drive to control costs, a recent report issued by Sestus Data Company and BearingPoint Financial Services Information Security Group that shows a 96% compliance failure rate on the multi-factor authentication requirement outlined by the FFIEC.
Adding to this ambiguity is the varying opinions between audit firms; and even within the same audit firm year over year. Some organizations are overcoming this issue by moving their data or sequestering it deeper in the enterprise to remove it from the scope of the audit.
Additionally, the promise of easier administration that has been promoted by image-based authentication has not yet been realized. Many organizations, particularly those in the financial sectors that service a large number of unsophisticated customers, have found significant resistance in these types of solutions. This was most notably felt by Bank of America in their implementation of PassMark’s (now part of RSA, a division of EMC) SiteKey solution.
A significant market driver toward using image-based authenticators is the elimination of the cost burdens of token management. It is important to note however, that the problem set is so fundamentally different from dealing with internal populations. The scale difference between internal users and customers is huge. One set of tools and processes is not necessarily transferrable between populations. Internal tools and products (not to mention processes) may not scale up to serve external authentication, while large call center problem resolution tactics may not be cost-effective for internal authentication management issues.
To combat this, many organizations are segmenting their populations into at least 2 categories. Nearly every organization we have spoken to on this topic has divided their enterprise population into “customer” and “employee”, with a few going so far as to add categories for “vendor/partner” and “contractor”. Each category is then assigned authentication methods that are commensurate with the perceived level of risk associated with the group and the methods and depth of access.
Of course, the pervasiveness of homegrown applications tend to be the really difficult portion of the enterprise to include in any sort of “universal” authentication scheme, regardless of population served. Standardizing on a primary suite of authentication and authorization mechanisms/technologies and pushing the development and integration into those seems to be the prevailing means of moving forward towards the Single Sign-On “Holy Grail”. Legacy applications are only integrated if the development costs are very low, or if the risks are exceptionally high (such as increased audit attention).
Most often, this is accomplished by developing new authentication and authorization strategies and standards within the organization and heavily socializing them. Once they gain widespread acceptance, an edict is handed down by an appropriate level of authority that states that all new technologies being integrated or deployed, will adhere to this new standard. This process, while effective overall, can take years to bear fruit.
Single Sign-On while still and often discussed and much sought after end state, is currently (at best) being bridged by password synchronization tactics. As far as we can tell, the move toward Single Sign-On appears to have stalled at the directory level. Most companies at the leading edge of the SSO movement seem to have integrated their back end directories into a synchronized group, or standardized on a single directory structure. Unfortunately, the ability to tie all applications and activities to a single set of credentials remains elusive. This gap in expectations is being addressed by focusing more and more on just the web-based applications by authenticating to a middleware layer and leaving the client/server applications alone or directly tying them to directory authentication.
This use of the directory services as a sort of enterprise “authentication glue” often falls short of the granularity necessary to satisfy audit reporting for application level access. This lack of fine-grained visibility is driving further exploration into application aware synchronization and reporting tools. This leads to increased audit attention, and the cycle continues.
No related articles.
