83-10-33 DATA SECURITY MANAGEMENT STRONG USER AUTHENTICATION Daniel Mouly INSIDE Risk Analysis; Remote Access; High Data Value; Highly Differentiated User Profiles; Billed Services; PKI; Requirements; User Friendliness; Help-Desk Friendliness; Low Cost of Ownership; System Friendliness; Keys to Success; Choose User Communities; Create User s Strong Ownership Feeling; Find Added Value to SUA; Leverage with Single Sign-On; Leverage with Enterprise Access Management; Leverage with New Services WHY IS STRONG USER AUTHENTICATION (SUA) SO IMPORTANT? In the author s years of experience in the security industry, he has come across one recurring and universal principle: people make security much more complicated than it really is. Yes, systems are complex; and yes, securing and managing those systems can present real challenges. Yet it is by simplifying security, by getting to its underlying principles, and by applying these to the systems one is trying to protect, that one can really begin to build effective security. The security definition that the author relies on can be distilled to one phrase: Who can be granted access to what? Any security system, whether for a small business or for a large multinational organization, must solve that equation. This article focuses on the who an overview and analysis of the methods for ensuring the authentic identity of users of a system s resources. Because the what is usually determined by the organization itself, and thus by the security system in place, those resources can be anything from a sales and marketing database to the ability to issue billion-dollar wire transfers over the Internet, in real-time, from a company account. First, some definitions. Authentication means verifying that people are who they say they are before one can trust them with one s sensitive data and before they can do harm to that data. Strong means preventing people from simulating other users PAYOFF IDEA By simplifying security, by getting to its underlying principles, and by applying these to the systems one is trying to protect, one can really begin to build effective security. Strong user authentication is the cornerstone of any well-elaborated security plan. It is the element that creates what is in everybody s mind when talking about security: trust.
EXHIBIT 1 Comparison of Common SUA Methods Criteria Tokens Smart Cards Biometrics Portability High Medium Low Cost of ownership Low to high High High Management burden Low to medium Medium to high High Scalability Medium Low Low Ease-of-use and deployment High Medium Low identities. In a face-to-face conversation, speaking partners can see and verify who they are. If they want to strongly identify someone, they will ask for a passport or any other positive ID. In our computing world, strong authentication translates to any technology used to get the best proof possible that someone sitting behind any form of terminal (desktop, laptop, PDA, mobile phone, etc.) in order to enter an information system is really what the label user ID mentions. There are many technologies out there to accomplish this, the most popular being what are called two-factor authentication devices or tokens the two factors being what-you-know and what-you-have. Those more James Bond-oriented are using the what-you-are factor biometrics such as fingerprint, retina scan, voice verification, imaging. Some years ago, these were considered sci-fi, but many of them become more affordable as the horsepower of our PCs increase and silicon-based components are cheaper. But being relatively affordable does not necessarily mean they are ready to be implemented. (See Exhibit 1 for a comparison of SUA technologies available today.) Tokens are the most portable solution for strong user authentication. They work unconnected and can be used across any media. Smart cards have quite good portability for the smart card itself, but they are limited by the need for a smart card reader and client software residing on a PC. PKI offers poor portability for pure software implementations. It is improved when the certificate is hosted in a removable device such as a smart card, but then one gets the other limitations associated with smart cards. PKI also requires the use of applications that have been programmed for PKI, while the other two can be used as a replacement of static passwords. The cost of ownership for tokens primarily depends on hardware reliability, purchase options, and PIN management features. These factors vary dramatically from one manufacturer to another. Smart cards suffer from the cost of smart card readers and their relative fragility when used intensively for log-in. PKI costs vary, depending on the type of certificates used; using a company s own CA (certificate authority) to build certificates has no comparison to buying certificates from a public CA.
The author s experience as a security consultant taught him that the simplest solutions have the best chances of success if one considers addressing large user populations. Only some high-tech addicts will really accept seeing their log-in procedure be dependent on this kind of technology, just for the pleasure of using it. The vast majority of the others, those whose VCRs have been blinking 12:00 for five years, will be reluctant to quit their good old user ID/password combination to get logged on. Moreover, they will complain that the new technology does not offer the same level of backup as the old one, with its Post-it notes hidden behind the mouse pad. So, let us try to further analyze how a strong user authentication (SUA) project can become a success story. WHEN DOES SUA ENTER INTO THE PICTURE? Good timing is often very important to the success of a project, as it is for SUA. First, analyze the typical drivers for implementing SUA in an IT environment, or in any application. Risk Analysis Always start with this step because one must know the enemy, and risks are present within all elements of a security solution. However, it is impossible to assess risks if the resulting business exposures are not understood first. The most common of these are: Information may be used for personal gain. Information may be used for malicious purposes. Information may be lost or modified. Systems may not be accessible when required. False information may be used for deception. Denial of information transmitted may occur. The risk analysis should start with a question: What would happen if any of the situations listed were to occur? Examples of the type of impact are a new product launch strategy could be obtained and sold to a competitor; or funds diverted from the intended recipient to another account. Unfortunately, many security breaches are perpetrated by people with some type of grudge. These may be people who have been laid off from a company or overlooked for promotion (it is estimated that more than 70 percent of attacks are internal). Even if there are no specific causes, some people feel they have to get their own back on the world or show how clever they are. This constitutes a lot of the motivation behind virus authors and hackers. Having determined the impact of an exposure occurring, a cost can be estimated not just in financial terms, but in loss of reputation and im-
age that gives an idea of the level of security required and the contingency measures to be considered. Remote Access When the process does not start as it theoretically should by a risk analysis, the most typical driver to consider implementing SUA is when companies decide to open access to their corporate network to remote workers or business partners using dial-up connections or through an extranet. High Data Value Conscious decisions can only be made about protecting data once the sensitivity of information contained within the systems is established. Data segmentation is analogous to the layers of an onion, in which the inner core represents the high data value of the core systems containing sensitive information (e.g., personnel and finance). Outer layers may contain information derived from the core data that requires protection but is not critical, and the skin may be seen as public domain information that everyone on the outside can view. If data integrity is also a concern, then SUA can be coupled with electronic signature, which in fact authenticates both the data and the user at the same time. Highly Differentiated User Profiles If one continues to represent the various security levels as layers of the onion, the access rights of each user determine the layer of the onion that they may reach. Protection of the inner core, the most sensitive information, therefore requires protection of the user s identity that can access the inner core. Highly differentiated user profiles allow different access levels dependent on user ID. The need to ensure that the user matches the user ID therefore increases as one penetrates through the layers. High-profile user IDs that can access the sensitive information therefore need to be protected by SUA where there can be no doubt regarding the true identity of the user. Billed Services Another very good reason to implement SUA appears when any kind of service provider (ISP, ASP, etc.) sends invoices to its users based on their connection frequency or duration. From the xsp standpoint, knowing who is really consuming resources may not be very important as long as the invoices get paid; but in case of any dispute, being able to prove that only the legitimate user could log on may help in closing the litigation. To some extent, it is a kind of nonrepudiation based on SUA.
PKI It is this author s opinion that PKI is not a strong user authentication technology per se if one refers to the above definitions. If one considers the authentication act as a real-time proof of identity, then from the server standpoint, the only proof one can get is that the user one is dealing with has access to a certificate (and its associated private key) that one can trust because a trusted certificate authority (CA) has generated it. So, one relies on that one-time authentication performed by the CA when delivering the certificate, but what about how the user got access to the certificate now? Was it by entering a static password (maybe permanently stored on his laptop) or by presenting a PIN to an attached smart card or USB token? Even worse, because of the painful deployment of PKI certificates into the client workstation or just because many new devices, such as PDAs or smart phones, cannot store them, many vendors now revert to serverside certificate and private key storage. This just moves the problem of SUA to the relationship between the user and the certificate server, and technologies such as tokens are a perfect fit to provide this service. Other technologies such as virtual smart cards fall into the same schema, and one will see more and more of this combination of a good old SKI system enabling access to PKI-based applications. This makes perfect sense because PKI can be considered a very powerful identification technique compared to a simple user ID. It allows people to present themselves on a new system on behalf of a trusted third party, thus enabling relationships such as those involved in B2C situations. But this trusted chain has a weak link, and this link is the authentication technique used to give a user access to his or her PKI-based identity. REQUIREMENTS Whatever the requirement that drives the choice to implement strong user authentication, one will need to seriously consider the following factors when selecting an SUA solution, each of them being of a special interest for the involved parties. User Friendliness The most important factor for future users is Rule 1: know your users and the way they work with your system. Strong user authentication needs to be as seamless as possible in order to gain the maximum acceptance from the majority of users. User friendliness is supported by strong authentication systems incorporating a number of standard features designed to assist with this process. The most common of these are:
Automatic registration of users Automatic assignment of devices Grace period for implementation Automatic registration of users enables a strong authentication solution to fit over an existing system and gradually learn the user s identity based on an existing security profile. This is normally the case where a system has been built that relies on user name/password authentication. The user access rights have been established within the system; however, because strong user authentication is not used, one cannot be confident of the user s identity when he logs in. Automatic registration allows the strong authentication system to automatically register all the users. Following the automatic registration of the user, he or she needs to be assigned a strong authentication device. This can also happen automatically by the system assigning the next available device and notifying an administrator that this has taken place. The administrator then only needs to deliver the device to the correct user. That another user does not use the device can be ensured by the use of initial PINs, etc. Finally, the use of a grace period allows the user to receive his or her authentication device within a certain period of time before strong authentication is enforced. During this period, a user can continue to use his or her previous form of identification, but a clever system will terminate the grace period immediately when the user tries his device for the first time. This means that as soon as the user can use his device correctly to authenticate himself correctly, strong authentication is enforced from that point forward. The combination of these features allows rapid deployment of strong authentication in the user-friendliest manner. Help-Desk Friendliness This is the most important factor for network and security administrators. It is very important to take care of this factor before any massive deployment of new technology, but this is particularly true when it comes to a new authentication method. User authentication is a process that takes place at the same time for the vast majority of users, so one can expect peaks of help requests in the morning and after lunchtime. Because SUA often means implementing a new technology, this technology must offer help-desk-friendly features, such authentication backup or recovery, device unlocking, diagnostics, etc. The SUA implementation must not become a nightmare for help-desk personnel, and should remove the usual pain of password reset procedures. As described, the SUA solution may come with useful features such as auto-assign, auto-register, or auto-unlock that will greatly improve user acceptance and help-desk efficiency.
Low Cost of Ownership This is the most important factor for the enterprise. It is tightly coupled with the two previous factors. Whatever the initial investment for the SUA solution in both devices and servers, the real cost of ownership will be driven by the ease of deployment, the battery lifetime, the ease of PIN reset or unlock, every operation that may involve personnel or would generate loss of working hours. System Friendliness This is the most important factor for the IT department. System friendliness concerns the ability of the SUA technology to be seamlessly integrated to replace the currently available technology usually the password. Because SUA support is very rarely a native feature of an existing system, one must take care of how intrusive the installation of the new technology is to the current architecture. System administrators do not like changes because changes usually generate trouble. Hopefully, many modern operating systems or environments offer some kind of plug-in capability to make room for SUA hostside software infrastructure. For example, modern UNIX systems offer a mechanism called PAM (pluggable authentication modules) that provides great flexibility to implement SUA support for UNIX log-in, FTP, Telnet, etc. PAM is also available for Apache Web servers but, unfortunately, not for NT/IIS environments. A general rule to evaluate the system friendliness of an SUA solution is its ability to use existing user databases to offer native or natural extensions to existing user management. A good example of that is how Novell has integrated its NMAS (Novell Modular Authentication Services) component with existing ConsoleOne NDS management. SUA management is just another tab dynamically added to the existing user management GUI. And NMAS takes control as part of the usual Novell Client component, reusing already installed components. KEYS TO SUCCESS IN IMPLEMENTING SUA In addition to the above factors that must be considered when selecting the most appropriate SUA solution, once one has decided on a specific system or technology, one must take care of the following concerns at implementation time. Why? Because SUA itself is not an attractive new application. People usually do not buy security unless they are forced to do so. One will need to offer side orders to SUA users to make the implementation a success. Choose User Communities This may be obvious but SUA may not be necessary for all users. One will certainly be more successful if one limits the implementation to users
who need SUA according to the risk analysis or because they fall into one of the requirements described above. These users will be more likely to accept change in their log-in procedure if they are involved for some reason in what motivated this implementation. Another concern that must be addressed is how fitted to the user profile is the technology that has been chosen. Engineers and administrative people will not have the same perception of what is being offered, and one can select different solutions based on different user populations. This is one of the reasons why the author s company, VASCO, offers the same technology under many different form factors, so that the human interface to the technology is the most adapted. Create User s Strong Ownership Feeling Security is not something that can be bolted on to an organization. It is imperative that a security culture is implemented throughout the organization to prevent trust being compromised through lack of user awareness. The more users consider the strong authentication device to be their own property, the better the penetration of strong user authentication. Users must understand that their user ID is personal. In the same way that individuals automatically lock all windows and doors before leaving their houses, protecting the organization s business, including its reputation, must become a habit with every employee and partner. This will only happen if there is strong, active support from the CEO/managing director and a continuous education process. A security policy, endorsed by the head of the organization, and acceptance of it (in writing) in everyone s personnel file is a starting point. Constant reminders, through newsletters and promotional materials, especially during the logging-on process, reinforce the need to maintain vigilance. This feeling is also enforced when offering any form of electronic signature capability. The security policy must embrace all parties. The importance of legally binding contracts between business partners and between employees and employers cannot be overstressed. These contracts should extend to standards of business conduct for employees and cover the use of any electronic equipment, such as a laptop computer or hardware token, for company business. Find Added Value to SUA Users do not like security, or do not buy security. SUA must be introduced as a way to get access to a higher level of service. Most of VASCO s bank customers understand that very well, and they combine the requirement to use a token with the access to an extended set of online services that are not offered when using a simple password. Making an SUA user feel like a privileged user will transform him into a fervent sponsor.
Leverage with Single Sign-On Once SUA is implemented, or even in parallel to this process, introducing the concept of single sign-on (SSO) may be a good leverage of the SUA effort. SSO does not necessarily need SUA, but if one considers making a single authentication, it should be a good one, one that can be trusted. And an important aspect of SSO that users always appreciate is the reduction in the number of log-ins they are required to perform to access their various applications. Combining SUA and SSO creates a secure single sign-on solution that satisfies both the end user and the security officer requirements. Leverage with Enterprise Access Management Enterprise access management (EAM) is usually the most popular security project when presented to the end-user community because it merely reproduces in the virtual world of information technology what they have always been used to using in the real world: privileges, authorizations, delegated rights, etc. The argument for SUA in this case is that it is not worth defining finegrained authorization and spending a lot of time and money to build an authorization infrastructure if the key element to deliver access rights cannot be sufficiently trusted. A typical situation that occurs with weak authentication is that all members of a department will know each other s passwords after a short period of time, and this obsoletes the effort made to differentiate their security profile through authorizations. If a user does not obtain access to a resource or a function, he or she will switch to another user ID known to have this level of privilege. This shows the importance of what was previously mentioned about the strong ownership feeling brought by SUA. SUA brings a level of trust to the entire security infrastructure that password authentication cannot guarantee. Leverage with New Services Because of this same trust level, new services can now be accessed from remote locations (dial-up, Internet, wireless) to users of SUA, thus encouraging the use of this technology. Again, selling SUA to users by providing something new in the form of privileges or flexibility has a good chance of success. CONCLUSION Strong user authentication is the cornerstone of any well-elaborated security plan. It is the element that creates what is in everybody s mind when talking about security: trust.
Daniel Mouly is the Chief Technology Officer for VASCO Data Security International (www.vasco.com). A software engineer and manager with more than 20 years of experience in the security industry, including as founder of a security software development and consulting company, Mouly has directed security systems development for financial institutions, corporations, and government agencies. He also currently heads VASCO s worldwide security R&D activities. Mouly can be reached at dmy@vasco.com.