Secure Space

Security in the world of distributed networks

In a heterogeneous distributed network environment, it has become more and more difficult to both utilise and manage security required for large-scale mission-critical applications. Rahaju Pal tells us how to tackle security concerns of single sign-on applications

As networks grow larger and larger, finding ways to effectively navigate and manage their security will become essential to the effective use of distributed systems.

Single Sign-On (SSO) allows users access to all resources in a distributed environment regardless of where they reside on the network. Contrast this to the more typical environment in which the user must explicitly log into each new system he wants to access.

For the user community, the benefits are readily apparent. Users only need to remember a single password and can always be assured instant access to the resources they need. For management, SSO provides a simple means of de-authenticating users, security auditing, and user ID management.

There are, however, some barriers to implementation, especially with regard to access control management.

Security problems

It can be argued that from a security perspective SSO provides no real benefit. In fact, by this way of thinking, SSO probably does more harm than good. The reason is obvious: with a single authentication procedure and a single point of entry, the number of resources endangered by a single compromised account grows tremendously. Given the well-known and documented problems with password security today, placing a single password on what might amount to the entirety of an organisation’s information resources seems a step backward, not forward. This article will help identify some of the problems and some of the solutions associated with an SSO implementation.

Authentication

Because SSO relies on a single point of authentication, that point must be robust enough to guarantee security for the entire network. Therefore, simple IDs and passwords may not be sufficient. Rather, many organisations might wish to use some combination of token-based, smart card, or biometric authentication systems.

Central management functions

The advantages of SSO can be roughly grouped into two categories: Time savings for users, and administrative savings for the organisation. Robust central management functionality is critical in achieving the latter objective. Indeed, if central management functionality of an SSO implementation is weak, many of the inherent advantages of SSO (easy de-authentication, usage tracking, etc.) disappear.

Specifically, the system security administrator should be able to obtain a logical view of system-wide rights and privileges. As with any system, there must be some account privileged to ‘manage’ the network. In this case, there must be some user empowered to create and remove accounts, each with their own respective security profiles. Therefore, this account should be protected with even greater care than others. It is recommended that some form of non-password-only authentication be used, if only for this account (or group of accounts).

Audit logs

Audit logs have become commonplace on platforms that range from the mainframe right down to the PC. Because such logs are inevitably tied to platform-specific security subsystems, the data within them remains at the platform where the logging occurs. Thus, with today’s heterogeneous environment, we wind up with audit logs spread across the network.

A better solution would be to provide central logging capabilities. Until a more complete generic security API set is provided, this is unlikely to occur. In the short term, however, an SSO implementation might be able to provide limited central logging of such items as accesses granted or denied for multiple systems. It should be able to indicate the type of access granted or the reason for denial. In addition, it should be possible to integrate this type of functionality with the network-wide management systems noted above.

Audit logs are designed to serve two general functions. First, they serve to deter potential system intruders by helping to make them accountable for their actions. Second, they serve as after-the-fact indications of a security problem. In the traditional sense, they serve as a record of attack, perhaps providing information, which might be used to find and remove security vulnerabilities for the future.

Encryption

As noted previously, the advent of SSO means that individual login information becomes more valuable, and hence, needs greater protection. One of the most effective ways to prevent the capture of login information is to use one-time passwords. Another is to use encryption for protecting passwords and login information both as they traverse the network and as they reside on the client workstation.

Network cabling is also vulnerable to network ‘snooping’, in which an attacker uses a network protocol analyser or similar tool in order to ‘spy’ on the traffic passing through the network cable. Though some cabling systems are difficult to tap covertly (eg. fibre), most are vulnerable. If passwords and other login information is passed over these cables in cleartext, they will be vulnerable to network snooping. Therefore, they should be protected with some form of encryption.

Methodologies

Currently, vendors are offering SSO solutions that fit roughly into one of three categories. These are local scripting, central scripting, and ticket-granting.

Local scripting

The local scripting system is decidedly low-tech. Most local scripting systems work via a daemon, which runs on the workstation. Once the user has been initially authenticated, the daemon becomes active and watches for familiar login screens or prompts. When it identifies such screens or prompts (or when activated by the user), the daemon activates a script file containing all necessary login information. The script information is entered into the network as though it has come from the user; there is no indication to other network devices that the process is automated.

There are currently local scripting systems available for nearly any host or network system that can be accessed from a PC workstation. Not all of them, however, provide the security framework to do so in a secure manner. In order to be secure, the local scripts should remain encrypted while on the local disk. In addition, there should be some robust access-control shell around the scripting system such that the user who owns the scripts can be positively identified.

Central scripting

Central scripting systems are only marginally more advanced than local scripting systems. In the central scripting model, the functionality behind the delivery of login information to network elements remains the same as that of the local model. In the central model, however, the scripts reside permanently on either the LAN file server or on a dedicated SSO script server. They may be copied down to the workstation briefly at execution time, or they may be passed directly from the central repository to the network element that requires authentication.

The point of greatest vulnerability comes when and if the scripts are copied down to the workstation. While they are on the workstation, they may be vulnerable to capture if they are not protected by some form of encryption. In addition, if scripts are not encrypted during their travels over the network cable, they may be vulnerable to an attacker who has tapped the network cable.

Also, if the network-wide SSO system is based upon scripts stored in a central location, that location must be secured both logically and physically. This should include some form of redundancy in case of a malfunction in the script server.

Ticket-granting

The final SSO solution is actually a group of solutions clustered under the generic title of ‘ticket-granting.’ The most common of these systems is Kerberos, which was developed as part of the MIT Athena project in order to provide some measure of distributed security. Over time, it has become something of a de-facto standard in the world of distributed security.

In practice, the ticket-granting server works by issuing a series of time-dependent tickets or ‘certificates’ to specific users in order to use specific services. In its most basic form, the user requests access to a network service, and is either granted or denied access by a central security server. If access is to be granted, the security server will issue a ticket to the user for that service. The ticket will allow access to the service until it expires. Fortunately for the user, all of this occurs in the background and is never seen in the foreground.

We should note that ticket-granting servers represent a single point of vulnerability with respect to enterprise-wide availability. If the security server goes down, users may not be able to access any portion of the network. Therefore, there must be strong redundancy in the network infrastructure, which supports the security or ticket-granting server.

The author is assistant manager, Global Risk Management Services at PriceWaterhouse-Coopers. He can be contacted at rahaju.pal@in.pwc.com