Distributed and Secure

When you distribute information and processing, you also delegate security responsibility. Good access controls, eyes-open administration, and communications encryption can make all the difference.

Russell Kay

It's ten o'clock. Do you know who is logged on to your network? Really? The fact is, as organizations of all sizes now employ networked computers and distributed systems to handle the bulk of their information-processing needs, security becomes increasingly important.

Just look at how dramatically the workplace has changed in recent years. Computers are everywhere, being used for a multitude of applications distributed throughout an organization's logical and physical structure. Electronic document interchange is replacing paper documents, E-mail is now being used in place of phone calls an d memos, voice mail is taking the place of secretaries and operators, complex design and control tasks are increasingly performed using computer systems and software, and sensitive and proprietary data is routinely transmitted from network to network--indeed, from country to country--over phone lines and satellite links.

And what about the nuts and bolts? Were your distributed systems designed from the beginning as integrated wholes? Of course not. They grew via the patching together of existing workgroups, LANs of all descriptions, departmental minicomputers, corporate mainframes, and connections to outside networks. The resulting "systems" may include components using 31 flavors of Unix, plus MS-DOS, Windows (NT and Workgroup versions, too), Macintosh System 7, NetWare, TCP/IP, VMS, and MVS.

Now they're all part of the same giant network, and everyone in the company wants to get at everyone else's resources. And there's no good way of telling what kind of workstations are on your users' desks or what operating systems they are running.

At Martin Marietta Aerospace's technical computing center in Orlando, Florida, systems integrity manager Padgett Peterson watches over the security of 5000 networked PCs. He believes in active management: seeking out problem areas before they occur. "One of the biggest problems I've found is that companies don't even know how many PCs they have," Peterson says. "Some don't even have an approximate idea of how many. So they don't know who can connect to their networks."

This complexity creates many opportunities for abuse, particularly unauthorized access to confidential information. To protect the integrity of your enterprise's information, you cannot afford to take security for granted. This means controlling access and encrypting telecommunications traffic.

Security is an issue because the majority of today's operating systems--both stand-alone and networked--were developed without any consideration for security. Either they offer no security capability whatsoever, or security and control features were tacked on as an afterthought. Software systems designed from the ground up with security as an important consideration are only now beginning to appear.

Know Thy User

When you hear the term security, the first thing that comes to mind is the password. And for too many organizations, a network's simple password mechanism is as far as security ever goes. Unfortunately, simple passwords offer little protection against unauthorized access; this is particularly true in a distributed environment.

When a connection comes in over a dial-up line, a customer link, or an internetwork channel, there may be no direct way of knowing who's on the other end of the line. Thus, there is a pressing need to identify and authenticate the user at log-in time--to verify that he or she has been authorized to access your network, and to determine specifically what access rights and privileges this individual will be given.

There are three different m ethods by which you can check on users at log-in time: by making use of something they know, something they have, or something they are. These methods are described in detail below.

The "something they know" method is typified by the user ID (i.e., the account name) and password, or by those systems that sometimes ask for other personal information, such as a person's mother's maiden name. The idea is that this is knowledge that isn't written down and is unlikely to be available to an intruder. Unfortunately, user IDs are usually easy to obtain, and people sometimes write down their passwords or even tape them to their monitor.

With the "something they have" method, which adds a second level of confidence to the authentication process, you can require that the user possess some physical object in order to gain access--the electronic equivalent of a front-door key. While this object may be as simple as a magnetic-stripe plastic card, the most common solution today takes the form of a random passw ord generator or a challenge-response device.

One type of token, as these devices are called, provides a pseudo-random alphanumeric word or number that changes every minute or so and is time-synched to a stored database. This results in a one-time password that's good only at that particular point in time and for only one log-in. The first token that came to market in 1987--the SecurID from Security Dynamics in Cambridge, Massachusetts--used this system.

Another type of token is a calculator-like device into which the user types a number presented as an on-screen challenge by the host; the token generates a response that the user types into his or her workstation. Again, the result is a one-time, nonreusable password. Unless the user has the token with him or her, no log-in is possible. In addition, most of these devices can also be configured to require that the user input a personal identification number into the token prior to the authentication process.

Obviously, the use of tokens cr eates certain administrative problems, such as what should happen when an employee mistakenly leaves a token at home. These problems can be handled by stocking (and carefully controlling) temporary spares, but it also requires attention by a security administrator.

In addition to the tokens described above, a number of so-called smartcard security implementations are coming to market; these use a credit-card-size device that contains a microprocessor and writable memory. Also, NIST (National Institute of Standards and Technology) has developed a card for generating digital signatures using its proposed standard. This standard calls for the use of a NIST-patented encryption algorithm to allow the unforgeable "signing" of electronic documents to serve as proof that a message actually was sent by the claimed sender.

In addition, there is some future potential for the use in authentication applications of active-badge technology, in which users carry a badge that transmits a weak radio signal that i s picked up by special receivers when they come within a designated range (generally several feet). The advantage to this approach is that the authentication takes place automatically, with no action on the part of the user and with no need for physical contact between the badge and the sensor.

Currently there are some 15 to 20 suppliers of smartcard- or token-based authentication systems, but one company dominates the market. In the words of industry analyst and security gadfly Winn Schwartau, publisher of the Security Insider Report, "There's SecurID, and then there's everyone else."

Systems that require additional hardware--such as a smartcard or a magnetic-stripe reader--have not been very successful thus far, primarily due to the inconvenience and cost of the needed hardware. Adding an extra piece of gear to a laptop system, for example, is often either wildly impractical or out of the question. One product that attempts to address these problems is Smart Cat from V One of Potomac, Maryland . This smartcard reader is about the size of a mouse and is thus stowable in a laptop's carrying case. It's price-competitive with less-capable magnetic-stripe readers, costing under $200 in quantity.

Price is likely to be a critical factor in most organizations' choice of security technologies. In the largest companies, which are more likely to have dedicated security professionals on staff and are also more likely to use token authentication, the numbers mount up quickly. You simply can't hide from the cost problem.

For example, Martin Marietta uses tokens at a cost of around $50 each. "The problem is," Peterson complains, "they are good for authentication, but they don't do anything else. I'd like to see them used to provide seeds for encryption." Peterson acknowledges that, in principle, smartcards and other, more capable, systems are a good idea. "But the cost of buying a reader is the stumbling block," he notes. "I don't have any problem doing this for 150 computers, but I sure can't justi fy it for 5000."

One recent product that addresses this objection is SmartDisk from SmartDisk Security in Naples, Florida. On the market for about a year, this $150 product packages a smartcard into a floppy disklike unit that can be read by any standard 3 1/2-inch floppy drive.

The final--and most secure--level of authentication, the "something they are" method, involves some unique and unforgeable aspect of an individual's body. In the past, biometric authentication, as it's called, has been based on comparisons of fingerprints, palm prints, or retinal patterns of the eye, or on signature verification or voice recognition. More recently, a system that recognizes keyboard-typing patterns has appeared from Los Angelesbased Phoenix Software International. Another new technology can reportedly read infrared facial patterns from passersby using only a simple video camera for image capture; it's being developed by Neurometric Vision Systems of Deerfield Beach, Florida.

Biometric systems offer the greatest degree of confidence that the user actual-ly is who he or she claims to be, but they are also generally the most expensive to implement: At a cost of several hundred to several thousand dollars per reader station, they may be better suited for controlling a doorway or other physical access--where one biometric unit can serve for many employees--than for one-to-one workstation access. Another problem is that many biometric devices carry a high price in terms of inconvenience; for example, some systems can take 10 to 30 seconds to verify an access request. Moreover, resistance is high for many systems that users see as unduly intrusive; people are reluctant to stick a finger or a hand into a slot, or sign their name, or sit still while an optical system scans their eyeball.

Hiding Authentication Information

One of the principal advantages of tokens is their ability to transmit over a network an access code that cannot be sniffed and contains no reusable information. These are crucial fea tures, but they are not limited to hardware; software systems can do the same thing. In fact, the NSA (National Security Agency) recently placed a large order for what it calls "sniffless password generators" with Secure Computing in Roseville, Minnesota.

With the company's Lockout system, instead of sending a password over the wire "in clear," you send a cryptographic representation of it, using a one-time encryption key. Each time you log in, the password is encrypted with a different key. The NSA will use Lockout in conjunction with its Tessera Crypto Card, a PCMCIA device. Intended for secure messaging within the Department of Defense and for protecting "sensitive but unclassified" data, Tessera is available from several makers. It uses both NIST's Digital Signature Algorithm and the NSA's Mosaic encryption algorithms.

Kerberos

Kerberos is an encryption-based system designed to authenticate users and network connections (see the text box "How the Kerberos Protocol Works" on page 172). It was developed at MIT's Project Athena in the 1980s and is named after the three-headed dog of Greek mythology that guards the entrance to Hades. Like its namesake, Kerberos is charged with preventing unauthorized access. It does this so well that it is now almost a de facto standard for effecting secure, authenticated communications across a network. Kerberos assumes it's in a distributed environment of unsecured workstations, moderately secure servers, and highly secure key-distribution machines.

Perhaps most significant is the fact that the Open Software Foundation's DCE (Distributed Computing Environment) standard uses a variant of Kerberos V5 as the mechanism for user authentication. Hundreds of vendors have licensed DCE technology, and many are adding additional security features (see "DCE: Building the Distributed Future" on page 125).

Another organization that's supporting Kerberos is the OCSG (Open Computing Security Group), a specialized systems integrator located in Redmond, Washington . OCSG is providing comprehensive Kerberos packages that support a number of different computing platforms, including MS-DOS, the Macintosh, SunOS, Hewlett-Packard's HP-UX, NextStep, and IBM's AIX for the RS/6000.

The OCSG integrates Kerberos with RSA (Rivest-Shamir-Adleman) public-key encryption and other security technology, including Security Dynamics' SecurID token. Other vendors offer Kerberos implementations for DEC's Ultrix and VMS platforms, and IBM says that it is committed to offering Kerberos on its MVS mainframes and OS/2 desktop systems. And, of course, you can get source code from MIT.

For all its popularity, however, Kerberos is not a complete security solution. "Too many people think that Kerberos is the answer," says Brian Redler, director of security and operations for NSCC (National Securities Clearing Corp.) in New York City. He observes that while Kerberos provides user authentication, it does not handle authorization for applications or for transactions within applications. Any determination of access authorizations and rights must be handled by other systems on the network.

Also, adapting applications systems to take advantage of Kerberos authentication--what's being called Kerberization--is neither simple nor straightforward; many organizations may find it well-nigh impossible and turn to other solutions. For large corporations, rolling out Kerberos across their enterprise-wide networks may not be finished in this century. Fortunately, it appears that the major networking-related vendors--including suppliers of network management software, operating systems, bridges, routers, multiplexers, and terminal servers, as well as the major computer manufacturers, including DEC, HP, IBM, and Sun Microsystems--are all hard at work Kerberizing their products. A few of these are already up and running.

With its Unicenter multivendor network security and management product, CA (Computer Associates International), one of the world's largest software companies, wants to become a major player in DCE security technology based on Kerberos. Unicenter uses DCE security mechanisms to implement basic authentication, password management, message encryption, and access-control lists. CA's stated goal is to allow customers to administer Kerberos from their current CA products while also providing security features and functions that Kerberos does not. CA plans to provide Kerberos authentication information to its existing security products, including CA-ACF2 and CA-Top Secret. The first such product scheduled is CA/Unicenter for Unix.

Knowledgeable users seem to agree that Kerberos is not quite here -- yet. "To date, I am not aware of any applications that have been Kerberized," says Brian Redler. He adds, "Kerberos is potentially half the answer. It's a good system, but it's not enough."

Martin Marietta's Peterson agrees with Redler. "Kerberos is a good technology, but it's not really available to be used at this point," he says. He adds that Kerberos provides an authenticati on envelope, but it still requires the prior exchange of keys. "I would hope that we could have automatic, secure authentication of transmissions," says Peterson.

"Kerberos is out there for real; it's a workable solution," says John O'Leary, director of education for CSI (Computer Security Institute) in San Francisco. "Once the environment becomes large, though, the added traffic of getting Kerberos tickets can be a real issue. If you have plenty of bandwidth and high-speed links, then you'll be OK," he concludes.

Single Sign-On

Back when you were hooked up to just one system, you needed only one password. But in today's environment, a user may well need access to several mainframes, a corporatewide network, one or more LANs, special development systems--you name it. Thus, a single user can end up with seven or eight passwords or more. But that's where the password system breaks down completely. No one can remember 15 passwords, all different, none in the dictionary, all unguessable.

W ouldn't it be ideal if you could log on to a system once, and, for the rest of that session, any other systems or networks you connected to would check with a security database to determine your rights, with no need for any further log-ins, interruptions, or passwords? Single sign-on, as this idea is called, is the holy grail of access control. And, as with the Holy Grail, people are still searching for it. The main problem comes back to the multiplatform, multiple-operating-system, multiprotocol environment, where single sign-on is extremely difficult to implement.

"If you're on an MS-DOS workstation connected to a Novell network, and you want to access a database running under MVS on an IBM mainframe," says CSI's O'Leary, "something has to sign you on to that mainframe and pass its security checks." But the problem gets worse. "If you want something on a still-different platform, say a VAXcluster, now you've also got to sign on to the VAX. Each of these systems has a different security architecture, different security mechanisms. And something has to do that sign-on and maintain a database indicating what ID on platform A equates to a different ID on platform B," continues O'Leary. And there's more: "The single sign-on mechanism has to update this information at appropriate frequencies--whatever is called for by the mainframe security systems, for example," he adds.

Keeping Secrets

Even when access controls are tight and well maintained, you need one further control mechanism to ensure that your organization's information remains confidential while it is moving around the loose confines of your distributed system, or to or through other networks. As long as your system sends data between users and servers "in clear," it is vulnerable to wiretaps and network sniffers. The use of cellular and microwave links makes it even easier for a technically sophisticated outsider to listen in on your communications and your calculations.

The solution to this problem is well known: encryption. You jus t transform the signal so that anyone who intercepts it, no matter how they do so, simply can't read it. A variety of commercially available systems use the federal DES, public-key cryptography with the RSA method, and numerous proprietary algorithms. Encryption is relatively inexpensive to buy and can be quite easy to use.

But if encryption's so good, why isn't everybody using it? The problems with encryption lie in the secure exchange and management of encryption keys. This is such a headache that one of the reasons the public-key approach was invented was to overcome the problem of key management by using one key for encryption and another for decryption. This lets the sender encrypt a message using the recipient's public key, which need not be kept secret and is, in fact, usually easily available. The message can be decoded only with the recipient's secret, or private, key.

Public-key cryptography also allows relatively simple implementations of digital signatures, nonrepudiation, and messag e authentication. These can be achieved with other cryptographic methods, but the public-key approach seems to be the simplest overall.

One major obstacle to acceptance of public-key cryptography is the fact that RSA, the best-known and strongest algorithm, has been patented in the U.S. and thus cannot be used in the U.S. without permission from RSA Data Security of Redwood City, California. Consider PGP (Pretty Good Privacy), a highly regarded public domain cryptographic system that was created by "cipherpunk" programmer Philip Zimmermann and popularized on the Internet. It's used around the world but is currently illegal in the U.S. because it uses the RSA algorithm without a license.

A new stage in encrypted communications may soon begin with the advent of the NSA-sponsored Clipper encryption chip for voice telephones. Clipper's inclusion of an escrowed "law-enforcement" back-door key has generated considerable controversy in the political, libertar-ian, and academic communities. Less well pu blicized, but following close behind, is Capstone, an extension of Clipper that includes data transmission.

As an aerospace contractor, Martin Marietta's computing activities make extensive use of communications encryption. The company's Padgett Peterson uses ViaCrypt, a $100 RSA-based (and licensed) package from ViaCrypt of Phoenix, Arizona. He also has some strong views about the Clipper controversy. "The thing with Clipper is, people react as if Clipper will give them less privacy than they have now. But they have none whatsoever at the moment, so it isn't really taking anything away at all," he says. He also notes that now, if you want any kind of secure phone transmission, your only option is AT&T STU-IIIs (secure telephone units), which cost $2000 per telephone.

Public law mandates that government information be protected in its processing and storage. DES has been used for this purpose for 15 years, and it has just been renewed for another five years. "People say that, well, it's theoreti cally possible to break DES if you have a known plaintext," Peterson comments. "But the fact is, no one has yet broken DES, and it's available for free. It's good enough for government work, just as Clipper is good enough for government work."

Administration: The Hidden Costs

Whatever type of security you have installed on your distributed systems, you still have to administer it--adding new people, taking off those who leave, modifying rights and permissions as job requirements change. And for many security administrators, the move to distributed systems has created a major administrative headache.

"What's happened as systems have become distributed and information has become distributed [is that] different departments are responsible for different platforms," notes NSCC's Brian Redler. "Mainframe administration is handled by a different group than handles the LANs--in fact, a different person may administer each LAN. And in most cases, security isn't handled by the security department but i s out in the user departments, where the LAN administrator is also the security administrator."

Responsibility for communications security is similarly distributed, Redler continues. "Once, all communications came into a central location, where a well-trained network staff monitored it. Now, it comes into the corporation all over, without any central administration," he says.

All this decentralized responsibility can create a security nightmare. Redler, along with most computer-security professionals, believes that security is largely a management issue, not a technical problem. "The first thing we had to get was management's buy-in to a security program, to an overall corporate policy and set of standards. If someone develops or installs a new application," he explains, "we don't want different administrators, each with their own ideas about what security is needed."

Obviously, different systems need different levels of security. A LAN with only routine word processing and spreadsheet ap plications may not need as much security as a production system with sensitive corporate data. Redler has established a set of security baselines for NSCC to determine how much security is needed for what information and for which systems.

Operating Systems and Consistent Security

Another factor that influences security is the choice of operating systems--in particular, network operating systems. Some have more security than others, but the primary problem, from a network perspective, is the need to accommodate multiple operating systems. This raises problems of compatibility and consistency.

"Better, more secure operating systems could have a sizable impact" on distributed-system security, according to Redler. "But it's not that straightforward, either; there are pros and cons to having your primary security in the operating system." He notes that while it would be great to buy a Unix version with a set of security features that you could pick and choose from, it could create inconsistencies that would make overall administration of security difficult.

"If you have one department that uses secure version X of Unix and another that uses secure version Y," he continues, "then each department has its own security system that works differently from the others." Instead, he tends to favor the use of an add-on, third-party security package. "Yes, it'll cost you a little more money, but now you have consistency," he adds.

File Systems

Sharing files over distributed systems requires a specially designed file system. Some are better than others, and one of the most popular has gaping security holes. Many Unix-based systems use NFS (Network File System), a file-sharing protocol for TCP/IP networks that was created by Sun Microsystems and is now available from DEC, IBM, Novell, and others.

Using a peer-to-peer networking scheme for low overhead and simplicity, NFS processes every file access request as presented, with no knowledge of prior requests. As a result, it has no built-in r ecord or file locking. NFS sites usually use a "lock manager" program to track file and record locks, but many client programs can simply ignore the lock manager. NFS also has no built-in security, which has led to the saying that NFS really stands for "No File Security." Because of its widespread use, NFS poses some serious security challenges.

The best solution to these limitations seems to be AFS (Andrew File System), developed at Carnegie Mellon University and currently available from Transarc of Pittsburgh, Pennsylvania. The designers of AFS tackled NFS's problems head-on, and the result is better security and increased reliability. Also, AFS is easier for administrators to maintain, and its greatly improved directory services simplify user access to WANs (wide-area networks).

User Awareness

It would be misleading at best to discuss distributed security in purely technical terms without at least mentioning the far larger--and perhaps ultimately more important--issue of user awareness. A certain degree of security can be imposed from above, with technical controls and administrative procedures.

But without user awareness of the risks and vulnerabilities, user cooperation, and user acknowledgment that protecting information is a part of their jobs, then security for distributed systems is a losing battle. CSI's John O'Leary puts it this way: "All the people using our systems aren't being told--or aren't listening to those doing the telling--that, in addition to the productivity enhancements their new systems and connections provide, there come some potential security downsides. People do not realize what the exposures are, and therefore they're not taking steps to mitigate them." O'Leary adds that the special problem for securing the distributed world is the lack of a single point of control. "In the mainframe world, we could rigorously and strictly limit what people had access to," he says.

What O'Leary sees as a disadvantage, however, analyst Winn Schwartau considers a plus. "W ith a single point of control--in single sign-on as it's usually thought of--you have reduced your security to a single point of failure," he says. He asks what happens if that point fails, and then answers: "I call that 'cyber-stupid'! Your entire system is open."

He recommends caution. "If you're going to go to this, then strengthen that point of failure. Require two forms of authentication at least--something that you know and something you own."

---

Security Tips for Distributed Networks

Awareness
-- Establish an organizational policy regarding computer access,
   information ownership, and user responsibilities.
-- Make users aware of their personal accountability for protecting
   the organization's information.


Access
-- Take extra precautions if you allow dial-in (e.g., use callback
   modems and permit external access only through a "fire-wall" system).


Authentication
-- Passwords should expire at regular intervals.
-- Use tokens or smartcards as r
andom password generators.


Confidentiality
-- Encrypt data transmitted over the network.
-- Encrypt stored files for especially sensitive and/or critical data.


Administration
-- You must be able to administer security (e.g., add, drop, or
   revise access authorizations or access-control lists) from
   a workstation anywhere on the network.


Availability
-- Prepare for power outages or brownouts with uninterruptible
   power supplies for servers.
-- Ensure that data can be backed up and is recoverable on-line
   (e.g., via RAID or hot swapping).
-- Maintain backup files at remote, off-site locations.
-- Make sure that the rest of your systems keep going if a disk
   or server crashes.

---

Photograph: A standard 3 1/2 -inch drive can read SmartDisk's internal circuits.

---

Photograph: Watchword II from Racal-Guardata is a challenge-response token.

---

Russell Kay is a BYTE technical editor who has worked in the area of compute r and information security since 1981. Before joining BYTE, he was editor of Infosecurity News and Computer Security Journal. He can be contacted on the Internet or BIX at russellk@bix.com .