Forwarded From: phreak moi <hackerelitet_private> http://www.infosecuritymag.com/sept/feature.htm Secure SSO: Dream On? BY FRED L. TRICKEY A maturing technology, single sign-on (SSO) may signal the demise of the "PC sunflower." But first the kinks have to be worked out. As the corporate enterprise moves from a mainframe to a multiplatform, distributed computing environment, sysadmins and end-users alike must grapple with a host of access and authentication challenges…and problems. Solving these problems is what most enterprises hope to gain from an SSO solution. However, so far the challenges have proved more durable than the solutions. A Complicated Picture With the deployment of LANs and shared servers in separate parts of the enterprise, and with the shift from massive mainframe applications to more flexible client/server technology, today’s business user works in an increasingly complex environment. Very few users today can access all of the applications and data they need on a single corporate mainframe or central computer. In a typical workday, an individual may require access to applications and/or data residing on many platforms: Windows NT servers, various UNIX systems, midranges and local or central NetWare or AppleTalk servers, to name a few. And in spite of many early obituaries, IBM S/390 mainframes and other "big iron" has not rolled out the door of most data centers. Legacy systems still make up a significant portion of the portfolio, many now "front-ended" with C/S applications to provide additional desktop functionality. Complicating the picture is the growing use of Internet/intranet technology. As recently as five years ago, most commercial enterprises were not connected to the Internet, except in a very limited manner. But rare is the company today that is not connected to the Internet and the Web. The increasing deployment of intranet technology means that the client-side point-of-entry to some applications is an Internet browser, and extranet applications extend the need for secure authentication and authorization services beyond the perimeter of the enterprise network. Authentication Breakdown What does SSO really mean? A quick look at some of the problems of distributed computing will help reveal a working definition. Few IT managers, network administrators and security practitioners today would debate the need for single sign-on, and the end-user community isn’t debating it—they’re demanding it. The typical user needs access to many applications, which may reside in whole or in part on several computers, including the desktop workstation itself. The guiding principle of distributed computing is that all of this should be transparent to the user. Where this goal often breaks down is at the point of authentication. Ironically, the need for SSO stems from the fact that information security practitioners have done their jobs too well over the years. We have hammered into developers’ heads that we need identification, authentication and authorization functions, and they’ve responded by building them into every platform and application. The result is a wide variety of logon protocols, ID structures and password-control mechanisms. To change from one information system to another, the end-user is forced to reauthenticate multiple times with different IDs and passwords. Average business users view this process not as security, but as interference—as an unnecessary barrier between them and the information they need to do their jobs. If forced to remember multiple IDs and passwords, users will write them down on a list or sticky notes posted near (or on) the PC monitor. The knowledgeable user may script different logons behind function keys, but the passwords are usually in cleartext. Users will inevitably use the ID/Password combination for one platform or application to try to get into another, resulting in lockouts and the need for Help Desk intervention. For system and security administrators, this profusion of authentication points is nothing short of a nightmare. Enrolling a new user means creating IDs or accounts, with appropriate passwords, in multiple systems and access control lists—with audit trails of approval and authorization at each of them. Changing an individual’s access profile to reflect an internal transfer or change of job function may require new administration, de-administration or re-administration by different administrators in different systems. Producing a list of all employees with access to a specific system may still be straightforward, but showing all of the accesses for a given user requires querying multiple databases and concatenating the results—an almost impossible task given different administration standards. The related needs of end-users and system and network administrators give us one definition for SSO: An enterprise-wide method of identification and authorization that (a) can be administered across the enterprise in a consistent manner, and (b) permits the user to access in a single, transparent manner all information systems to which he or she is authorized. Infosec practitioners, of course, know that this is only part of the solution. For a definition of SSO as one ID and password—maintained in one enterprise authentication database—presents its own set of security problems. The Cornerstones of SSO While new techniques and tools make SSO an ever-more attainable goal, the real challenges involve implementation and security. There are four components of a complete SSO solution, two of them basic to the above definition, one essential from a security perspective, and one desirable for security but not yet easily achieved (see box). The primary function of most SSO systems is identification and authentication (I&A)—that is, verification that the user is who he says he is, and verification that he is approved to access a particular network or application. A few products now incorporate business-rule authorization (which specifies what the user can do once he gets access). However, in most SSO systems the authorization function remains at the application itself. Early Solutions The earliest forms of SSO were Kerberos and PC-scripting solutions that grew out of security products for the workstation. Kerberos, the first of the token- or credential-based authentication methods, was developed at MIT as part of Project Athena. The core of DCE security services, Kerberos replaced dumb terminals with intelligent workstations, enabled client/server application development and customized what is presented to the individual. While fully implemented Kerberos provides a means of secure logon to a central authentication server, its application to SSO is problematic. The advantage of Kerberos is that it is password-based. Since the passwords never actually traverse the network, it provides excellent protection against capture-and-replay and man-in-the-middle attacks. However, in today’s distributed computing environment, implementation of a ticket- or credentials-based system can be problematic. For Kerberos to be effective today, all desktop clients (including browsers for intranet/extranet applications) have to be "Kerberized"—that is, given a link to a Kerberos authentication request ("kinit"). Moreover, all target systems and applications must be able to accept the ticket instead of a traditional ID/password logon. Other early SSO solutions were implemented entirely at the workstation. A local security system prompted the user for ID and password, then displayed a custom menu or GUI that listed the applications the user was allowed to access. When the user selected one, the client used a stored script to send the ID/password logon to the target system in the format it expected. The advantage to these systems is that they required minimal retrofitting of existing applications; logons at the server or mainframe end looked the same as they always had. However, early SSO solutions also had a number of disadvantages: users were tied to one desktop; security was placed at the PC, arguably the weakest point in the network; the scripts were vulnerable to modification by users wanting to grant additional accesses; and back-door logons to applications were possible by bypassing desktop security. In addition, any change to the logon protocol for an existing application required maintenance of scripts at every affected workstation. Networked-Based SSO Most of today’s SSO products rely on a network-based single authentication service. At the beginning of the session, the user authenticates to that service, then requests access to individual systems or applications. The authentication server enables the logon, either by a scripted shadow logon or by presentation of Kerberos-type credentials (or tokens). Depending on the underlying methodology, existing applications may or may not need retrofitting. Also, client software must be distributed to all workstations. Unlike earlier solutions, changes to an individual’s access profiles or system-wide changes to services can be centrally administered. Note, however, that these improvements only solve the user’s problem. He or she can now log on once to the authentication client, with the expectation that the authentication server will complete the connection to the application. However, sysadmins must still administer multiple authentication/authorization tables and databases at the target systems and the central authentication server. To reduce administration time, SSO products are increasingly offered as part of enterprise-wide system and security administration products to facilitate changes across all applications and platforms. Threats to Information Security SSO poses at least three immediate security concerns: 1. The ID and password become a "key to the kingdom." If the means of authentication is still an individual ID and reusable password, compromise now means access to everything to which the user is authorized. In today’s world of increasingly networked and cross-boundary access, integration of enhanced authentication methodology will become more and more necessary. At a very minimum, the SSO solution should ensure encryption of logon sessions and passwords whenever they are transmitted on the network. In addition, robust password format and change requirements should be implemented along with SSO. 2. A central data repository of IDs, passwords and accesses offers attackers a single, consolidated target. Administrators dream about one access security database in which all additions, changes and deletions can be made—and from which all access information can be logged, reviewed and reported. The problem is, intruders dream about the same thing. If they can crack that one database, they can do anything anyone in the system can do, or they can add and remove accesses at will. Any central repository of authentication data must be robustly encrypted and firewall protected. Administrative access to it must be limited to essential, authorized individuals. 3. A single authentication server/service equals a single point of failure. If an intruder wants to completely bring down your network, he doesn’t even have to crack the system; he merely has to crash it. If it does crash, whether by malicious attack or system failure, no one can log on at all, including the very administrators who are expected to fix the problem. Any central authentication service must be mirrored or replicated to provide continuous availability. Critical system administrators and support personnel should retain back-door logon capability to key systems even in the absence of the central authentication service. Other security concerns must also be considered before you can place all authentication trust in an SSO solution: Does your security policy include strong password controls and enforced change at regular intervals? Do you require re-authentication for some secure functions or transactions exceeding, say, a certain dollar amount? Do you have time-out controls in place requiring re-login after a defined period of inactivity? What about logs, alarms and lockouts? How are invalid login attempts detected, reported and handled? Are sessions or IDs merely suspended for some period of time, or are they locked out so that Help Desk intervention is required? Are these policies and controls consistent across platforms and applications? Other Potholes on the Road to SSO >From four or five vendors in the early 1990s, the SSO field has grown rapidly, to the point where as many as 30 or more vendors offer what they represent as SSO products (see sidebar). Despite this growth, successful implementations of true SSO in large environments are extremely rare. Until recently, the two key impediments to success have been scalability and the mix of platforms supported. If you are looking for a solution for a few hundred users and a limited number of applications in a Windows, WinNT and UNIX environment on an IPX or TCP/IP network, there are plenty of solutions available today. Support for other platforms and operating systems—such as OS/2, VMS, AS/400 and MVS/VM or other mainframe systems—has been slower in coming. Many of the vendors have announced plans for agents on other platforms, but exactly which of those interfaces will get written and deployed will depend on market demand. One solution to the cross-platform issue would be an industry-standard API, such as GSSAPI (the Generic Security Services API), which would enable local or third-party interfaces to less-common platforms not supported by major SSO products. Some of the vendors are starting to provide API "hooks," but many of these have been proprietary. As in other aspects of distributed computing, many SSO vendors are not eagerly supporting open-standard interoperability. Since many of the solutions on the market today run on server platforms or require complex cross-platform administration and synchronization, scalability is often a limiting factor. How many platforms, applications and users are you planning to bring into the SSO tent? An encouraging trend is increasing vendor support for X.500 standards and LDAP to extend the number of users that can be maintained without unacceptable increases in administration resources. TCO and ROI Perhaps the biggest concerns for IT and corporate management are total cost of ownership (TCO) and return on investment (ROI). An SSO implementation in any large installation is an enterprise-level project, and a big one at that, equivalent to other enterprise projects such as SAP or PeopleSoft conversions. While SSO products from the major vendors are enterprise solutions, they are far from cheap in and of themselves. Published prices (where available) are in the $50-$150 per seat range, with additional costs in the thousands for central server applications. Some solutions come bundled with other products, which can drive the initial investment even higher. It must be said, however, that at this point in the development of the SSO product sector, almost all of the vendors will negotiate steep discounts for specific contracts. But the cost of the product is only part of the TCO. Depending on the platform for the server itself, some capital investment may be required. Older individual desktop workstations may need to be upgraded or replaced to support client-side requirements. And don’t forget about training costs—not only for administrators and Help Desk staff, but for end-users who need to learn new logon procedures. Retrofitting of front-ending legacy applications to accommodate new logon protocols can turn into a major expense. The cost of remediating Year 2000 problems in older applications is a good example of the expense involved in massive code maintenance across the portfolio in a compressed time frame. Most organizations already have a sizable investment in existing security and authentication software and databases. Unless the SSO solution can leverage that investment, corporate management will see abandoning it as another cost of implementation. Can the product use existing databases, or is it feasible to convert them? If not, factor in the cost of re-administering all existing principals. ROI may be harder to quantify than implementation costs and TCO. If an SSO implementation is successfully made across the board, it follows that ongoing user administration costs should decrease. Studies have shown that 60 to 70 percent of Help Desk calls are password-related, and it’s logical to assume that a large percentage of those arise from problems with multiple IDs and passwords. Other expected benefits of SSO are even harder to quantify. Easier access to all information should increase user productivity while decreasing frustration. Ease of administration should do the same for sysadmins. If planned carefully, SSO implementation can help administrators standardize ID and password policies throughout the enterprise and apply authentication security policies consistently. Can We Get There From Here? To date there is no "magic bullet" SSO solution on the market, and there is not likely to be one soon. The good news is that the questions about SSO have changed from "Do we need to do this?" and "Can we do this?" to "How are we going to do this, and when?" Moreover, the development of mature support technologies—such as directory services, practical encryption and a PKI to support digital certificates—improves the chances of simultaneously achieving true SSO and improving security. Deciding how and where these technologies fit into your enterprise requires careful planning and a thoughtful implementation strategy (see sidebar). In the past decade, dozens of products have emerged. Many of those, however, proved too limited or unworkable, and quickly disappeared. Today, there are 10 to 15 major players in the game, including Schuman, PassGo Technologies (formerly CKS), HP, Sun, Memco, Security Dynamics, Computer Associates and IBM, among others. The GartnerGroup and other industry analysts believe that SSO is one sector of the security product market that will continue to mature into the first decade of the 21st century. SSO is not and may never be a one-size-fits-all solution. Every organization’s platform and application mix is different, and the complexity of this mix will continue to increase as new technologies arise and make their way into the market. The need for SSO is no longer in question. Achieving it will require the continued cooperation of vendors and their customers. Can we get there? I think so, and so do a lot of vendors, or they wouldn’t be playing. Fred Trickey is information security officer for Administrative Information Services at Columbia University in New York City. He is a frequent author and speaker on SSO. -o- Subscribe: mail majordomot_private with "subscribe isn". Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:07:44 PDT