The rise of the Internet has made everyone aware of the need for system security. How do I restrict access to HTML pages? How do I protect transactions over the Internet? How do I prevent hacker attacks? Even with the exposure of the Internet, however, most banks will tell you that their biggest risk continues to be internal. It doesn't require malicious intent to cause significant damage; simple mistakes can do substantial harm. An erased database file is just as much of a problem whether done accidentally or maliciously. A system that authenticates users and authorizes actions can do more than protect against malicious actions, it can help prevent accidental damage. It is important, therefore, that any security solution addresses both internal and external risks.
Up until now, most commercial organizations have relied heavily on physical security with well-protected data centers to secure their systems. In a world of distributed systems, more is needed; many parts of the systems are not just outside a protected data center but often completely outside the business's premises. For example, in manufacturing, suppliers' computer systems are frequently linked directly to a manufacturer's systems. When systems are accessible via the Internet, end users could be anywhere in the world.
The good news is that most of the technical elements required to secure distributed systems already exist. The bad news is that security cannot easily be addressed incrementally. If there is a hole in the fence anywhere, an organization is vulnerable. Also, no simple combination of products can provide a complete security umbrella in a commercial, distributed, open systems environment. It is relatively easy to provide point solutions for encryption and even authorization. On the other hand, providing a point solution for user authentication rapidly becomes unmanageable in a distributed environment where users need to identify themselves to many systems to perform even simple transactions. This is where the idea of single sign-on ý that is, the ability for users to authenticate themselves once to access many systems, including databases ý becomes important. Single sign-on is not just a matter of convenience. Reducing the number of passwords used can significantly improve security by minimizing the likelihood of a password being reused, written down, or revealed in some other way. Even though many of the elements necessary to provide security for distributed systems exist, there is very little in the way of standards, open architectures, and interoperating products that allow complete security solutions to be provided.
Different people mean different things when they talk about security, so it is probably good to start by setting some basic definitions. Some people talk about security in terms of computer viruses or hackers making a denial-of-service attack over the Internet. Others refer to privacy and encryption or authentication and authorization. Securing systems requires addressing all these areas. The elements of security fall under four headings:
Authentication
Authorization
System Protection
This heading groups all protection against system damage. This includes virus protection, firewalls and proxies, protection against denial-of-service attacks, and steps taken to minimize accidental system failures. This protection can be partially addressed by applying authentication, authorization, and encryption techniques. A number of other facilities, such as virus-detection and removal software and virus-resistant systems environments (like Java) help with this. In this article I will concentrate on authorization, authentication, and encryption in a distributed environment, including the problem of single sign-on.
Today, there are point solutions that cover all these areas, but there are few provisions for building a complete security architecture. For example, current Secure Socket Layer (SSL) implementations provide Internet server authentication and encryption but not user authentication, although the latest SSL standards (now in version 3.0) address this. Various Kerberos-based private key mechanisms provide all three capabilities, but they are only viable when up to a few thousand user keys need to be administered.
There are some de facto security standards today, such as the Generic Security Service Application Program Interface (GSS-API), for interfacing programs to security services. Other standards include numerous encryption algorithms such as DES and RSA for message encryption and MD5 and SHA hashing algorithms for the creation of digital "fingerprints."
When discussing security, many people get excited over encryption key lengths and other technical encryption matters. Though these may be important, they are not where the real danger lies. There are two basic rules of security. One is that there is no such thing as perfect security. Security is always a trade-off between cost and difficulty of use on one side and risk on the other. Technology can increase or decrease the risks for a given cost, but compromises always have to be made. It is a crucial element of security management to be able to evaluate the risks and balance them against the cost and difficulty of use. I will discuss this more later.
The second basic rule is that the biggest security exposures will always be in people's behavior. No amount of technology can make a system secure if people do not behave securely. Therefore a successful technical solution must encourage secure behavior and be able to detect insecure behavior.
One of the biggest problems in security is caused by the proliferation of secure systems. I personally access probably hundreds of sites both internally and on the Internet, many of which require passwords to access. This presents a dilemma. Do I use a different password for each site and risk forgetting them or writing them down? Or do I reuse a small number of passwords and risk giving away a password for one Web site I use to another?
If passwords are reused, they become highly vulnerable. For example, one way to collect such passwords would be to open a valuable but free Web site and make it password-protected. Then the site could be made to require frequently changed passwords and it could conveniently "forget" your password from time to time to encourage you to try out other passwords. Such a site could probably collect many passwords that could be used elsewhere. This is why physical token- and biometric-based authentication and single sign-on are important; they help reduce the security exposure from people's behavior.
In the world of distributed systems, there are a number of specific areas where there is a clear need for more secure facilities than are generally used today. These include:
I will discuss the big picture of architectures for distributed systems in the context of these specific problem areas.
Many organizations are moving to a three/four-tier Web-based distributed architecture. The architecture uses a thin HTML- or Java-based client (tier 1) accessing a Web server via HTTP (tier 2), which accesses a business object layer, or tier 3 (also called an application server) via CORBA or message-oriented middleware. This in turn accesses tier 4, which is either an RDBMS accessed via SQL-based middleware or mainframe legacy systems accessed via message-oriented middleware such as IBM's MQ Series or via distributed TP monitors such as BEA Systems Inc. Tuxedo. (See Figure 1.) In the three-tier version, transactions are served directly from the business object layer via IIOP, for example. The third tier would then be either legacy systems or a database, as in the four-tier example.
Today, most of the parts of such an architecture can be secured, but it requires several different products. For simple client-to-Web server encryption, SSL is generally used. User authentication generally just uses simple password-checking software running on the Web server. The security of the business-rules layer is usually vendor-specific. For example, Tuxedo version 6.3 has built-in public key encryption for link-level security. For DCE-based distributed systems, the security mechanism is based on Kerberos. Currently, there are few options for securing CORBA/IIOP traffic between the client and the transaction server, although for those versions of CORBA that use DCE as a transport layer, DCE security can generally be used. OMG has a proposed standard for secure IIOP, which, I believe, has been accepted but not yet (at press time) fully implemented anywhere.
There is a new generation of Web security facilities becoming available that goes beyond simple password protection of Web pages. These security facilities fall into two classes. One approach works somewhat like a firewall; a security server sits in front of the Web server (NetAccess Inc. takes this approach); others use the security exits from the major Web servers to authenticate and authorize users. For example Netscape Communications Corp. has introduced its Netscape Security API, based on Intel Corp.'s Common Data Security Architecture (CDSA 1.2). CDSA is an attempt by Intel to establish a standard security architecture. It consists primarily of a Common Security Services Manager, which sits between the applications and a set of add-in modules that provide cryptographic services, certificates, trust policies, and so on. CDSA may prove to be a significant security architecture for all parts of a distributed system, but it's early yet. (CDSA version 1.2 was released on March 17, 1997.) It is not entirely clear that there is a need for a common security interface layer as opposed to a standard security API, such as GSS-API, with the applications interfacing directly to the security services.
Securing a distributed environment will always require a combination of physical security and logical security (authentication, authorization, and encryption). Providing adequate security also goes beyond technical matters to security protocols and human behavior. All the physical and logical security in the world won't help you if some authorized person gives the information away. Technical security must always be part of a complete security system that incorporates proven protocols and manual procedures.
It is often forgotten that logical security only works if certain parts of the system are physically secured. For example, biometric authentication (such as fingerprints) can easily be spoofed if the sensor is not physically secured or if its output is not encrypted. Similarly, even though messages do not need to be physically secured, the private keys must be. Right now there are only three generally available ways to do this. One is to secure the hardware containing the keys in a physically secure environment, such as a data center or even just a locked room. Another option is to secure individual computers physically by hardening them. For example, in some high-security environments, computers are built inside safes. A much more cost-effective method is to secure physically just the keys and the encryption engine. Today, solutions are available that use tamper-resistant PCMCIA Cards or SmartCards to secure the keys and the encryption engine. The European cellular phone industry uses SmartCards for security with its Global System for Mobile Communications (GSM) system.
It is important to note that it is not enough to secure the keys physically. The encryption engine also must be secured along with the keys; otherwise the keys can be intercepted between the "key safe" and the encryption engine.
There are a vast number of security protocols to protect against various scenarios, including eavesdropping, man-in-the-middle attacks, repudiation, and message alteration. Here I will concentrate on mechanisms for authentication, authorization, and encryption.
Private key encryption requires much less computing power than public key techniques and is usually faster, but it requires a shared secret that must be distributed in some other manner (out of band). For a small number of users, keys can be physically distributed using, for example, secure printing techniques. Often private keys are distributed using a public key technique.
Kerberos is a private key encryption approach developed at the Massachusetts Institute of Technology. It is based upon a central (possibly replicated) security server that is trusted by everyone. Commercial implementations are available from such companies as CyberSafe Corp. Every user has his or her own private key that is shared only with the security server. This setup keeps you from having private keys for each user/server pair. The Kerberos protocol involves the issuing of tickets that grant a user access to a machine. To avoid interception of the tickets, Kerberos uses encrypted time stamps and an expiry time on each ticket. The default for Kerberos is to reject time stamps more than five minutes off. This gives up to five minutes for a ticket to arrive at the server after leaving the client machine. Unfortunately this requires that the clocks on all the client and server machines be accurately synchronized, which can be difficult when there are many users or when the users are in different time zones, which requires special techniques. Kerberos is quite a useful approach for securing server-to-server communications within a business, and you can use it to provide single sign-on at the expense of complex key management.
Public key techniques are currently fashionable. The most popular of these use the RSA algorithm, although other algorithms, such as elliptic curve algorithms, are promising. Public key algorithms are very compute-intensive compared to private key algorithms, so they are often used only for key exchange, after which private key techniques are used for message encryption. SSL key exchange is based upon the RSA algorithm. Key management is simplified with public keys. The most common approach is to have a small number of trusted key distribution centers, which hold the public part of the public/private keys for all the parties that wish to communicate. Then each party only needs to retrieve the public keys for the other party to communicate securely. The private keys never leave their owners.
Other techniques and algorithms include Diffie-Hellman, which uses a public key technique to negotiate a generated private key, rather than having one party generate the private key and send it to the other. The standard Diffie-Hellman protocol is vulnerable to man in the middle attacks, but this can be addressed by signing the messages digitally. Another technique is to use hash functions such as MD5 and SHA to ensure that messages are not altered in transit.
Most attention in the commercial world has been directed to securing messages. This is understandable in a distributed environment, especially given the open nature of the Internet. One area that has had very limited attention is securing databases. Most commercial implementations use simple password protection for access with no encryption and no single sign-on. Also, most database security routines with commercial DBMS are stand-alone and cannot integrate easily with other security mechanisms. This is somewhat surprising because the vulnerability of information is a factor of how long an intruder has to work with it. Messages are short-lived, but data in databases can be around for many years. Today, assuming that steps have been taken to secure the transaction messages, the easiest way to do damage or act fraudulently would be to access the relatively unprotected databases and alter the data. DBMS vendors do have secure-database capabilities, usually directed to military use, but it is rare for commercial databases to be encrypted or protected using public key techniques. I think this will become an area of increasing interest as the problem is recognized. Some companies, such as Protegrity Inc., are beginning to appear in this space. These vendors' products generally encrypt and decrypt data externally to the DBMS on a selective basis.
Probably the biggest problem in securing distributed systems is the integration of disparate security systems. Your Web site may use SSL, your mainframe may use ACF2 password protection, and your internal servers may use Kerberos. There is no general solution to this problem today, although there are some proprietary solutions from vendors such as IBM (under the company's SecureWay security product umbrella) that cover a wide range of environments. Standards such as GSSAPI and CDSA are starting to address this problem. In the meantime most commercial shops are having to buy several point solutions and integrate them for themselves. There are companies such as Concept 5 that are taking primarily a services approach to addressing this space.
The Internet is perceived as a hostile place, and as such it is a great proving ground for intranet and extranet security. If secrity technology works on the Internet, it will work anywhere. Right now, the emphasis on the Internet is providing secure financial transactions. The state of the art requires very careful coding of applications, firewalls, and Secure Sockets Layer- (SSL) capable servers and browsers. SSL is a flexible protocol that supports various encryption algorithms, including RSA and DES. Unfortunately, it only addresses the securing of HTTP traffic today, namely regular Web pages. This is not currently a problem because most Internet transactions are forms-based and as such, use HTML/HTTP. With the introduction of CORBA/IIOP as an Internet transaction protocol, there is another channel to secure. At this time IIOP is in the clear (unencrypted), but secure IIOP is planned. This will be critical to the use of IIOP for transactions over the Internet.
SSL, as used in the standard versions of the popular browsers, only provides server authentication based on public key technology and not public key-based user authentication. Although the software to have password protection for certain Web pages is available on many Web servers, the software uses passwords stored on the server, making them vulnerable to interception if someone uses the same password on many sites.
SSL-- though effective in the United States where RSA using more than 512 bits and 128-bit DES algorithms can be used-- only secures the connection between the Web browser and the Web server. This is sufficient if the Web pages are stored on the server and the server is secure. Increasingly, in a distributed environment, Web servers are not the source of data but provide access to legacy systems and databases located on other machines. With firewalls, this communication between the Web server and the source systems is isolated from the Internet and is less vulnerable to outside interference. On the other hand, employees behind the firewall with inside knowledge are a major source of fraud, so protection needs to be end-to-end. The key is to secure the middleware, especially in server-to-server communications.
Beyond physical security and the provision of dedicated connections between machines, the simplest ý but probably least flexible and most expensive ý way to secure middleware communications is to use hardware. Assuming the servers are in a secure environment, encryption boxes, such as the SunScreen products from Sun Microsystems Inc., can be used to communicate securely over public connections. This could be an intranet or even the Internet. This approach provides solid point-to-point security. The more flexible approach is to secure the middleware communications at a software level. This is potentially more vulnerable than the hardware approach, but it is cheaper and more flexible when new connections are needed. The potential extra vulnerability is a result of the software running on relatively insecure operating systems environments such as commercial Unix implementations or Windows NT. These environments can be made secure, but it requires significant skill to do so. Most middleware products, such as MQSeries from IBM, provide security exits onto which private or public key encryption can be built. Some, such as Tuxedo 6.3 and DCE, have built-in security facilities. Most shops choose their middleware products with little consideration of their security capabilities, so it is often a matter of retrofitting security.
Public key mechanisms (such as RSA) are good for authenticating software and hardware elements of a distributed system. So long as the private key of the private/public key pair is physically secure, the identity of the hardware or application can be assured. To be truly secure, the private key has to be physically secured and packaged with the encryption engine so that it never leaves the physically secure environment. Today there are PCMCIA- and SmartCard-based hardware encryption devices that provide such capabilities, available from companies such as Information Resource Engineering Inc. (IRE), Maz Technologies, Chrysalis-ITS Inc., and the partnership of Hewlett-Packard Inc., Informix Software Inc., and Gemplus. It is likely that in the future, there will CPU chips with published public keys and built-in private keys and encryption engines. Short of someone hacking into the chip with an electron microscope, they will be secure. Authentication is a little less certain when the private key is held in software. In this case the keys can potentially be revealed to a hacker. Security becomes dependent on operating system security.
The problem of authenticating people is much more difficult. Passwords, which are just secrets shared between the authenticator and authenticated, can become a big management dilemma. Earlier, I demonstrated the basic problem of having many passwords that need to be kept secret. The use of public/private key pairs can greatly simplify the key maintenance problem by reducing many private key pairs to a single private/public key pair. This approach has two problems. First, people do not have a cryptographic engine in their heads. This means that the private key has to be entered into a cryptographic engine for it to be used for authentication. The key becomes vulnerable to interception at this point. The second problem with this approach is that private keys are long and meaningless, making them very difficult to remember. The answer is to use tokens or biometrics or both.
Tokens, such as the SmartCards mentioned earlier, make authentication a matter of possessing of something physical and unique. One great advantage of token-based security is that it becomes relatively easy to know if you are vulnerable. The card must be missing because it can't be copied without great difficulty. Pure token-based security does leave open a window of opportunity if the token is lost or stolen. Supplementing the token with a password can address this shortcoming. Ideally, the password should be entered directly into the token (some have keypads) for maximum security, but in most cases entering the password into the card-reading device is adequate if you are sure of the integrity of the card reader. There are, however, tales of passwords being intercepted using dummy card readers.
Biometric techniques are even better, so long as the biometric sensor is secure and encrypts its output. My favorite is the iris scan technique, although this technology is only just becoming commercially viable. Unlike retinal scan, iris scan is nonintrusive. The front of the eyes are scanned from a distance of a foot or so using a high-definition camera. Current research indicates that the iris is a significantly better biometric than fingerprints, thus offering a substantially lower number of false accepts and rejects. With biometrics, there is no need for a user to remember or enter a password that can potentially be intercepted. The cost of biometrics is starting to come down to an acceptable level for normal commercial applications.
As mentioned earlier, technical security alone cannot provide appropriate security at an acceptable cost. Before implementing technical solutions, you must resolve two areas of security management. One involves managing the risk during the design and implementation stage, and the other involves managing the risk during operations.
Risk assessment for a security architecture is technically complicated, especially in a distributed environment where many products and protocols may be used. Two questions need to be asked. One is: What is the worst-case scenario, and is that acceptable to the business? The second is: Is the security approach cost-effective? It is almost certain that except for very large organizations, the skills to ask these questions will not be available within an organization. Even if they are, the danger of making a mistake is such that I would recommend the use of an external security consultancy, at least to verify any internal findings.
Technical security does not work unless it is supported by appropriate processes, the right control structure, and educated attitudes toward security. Operational security addresses these issues. As many organizations have well-established security operations departments, I will not discuss this topic in great detail.
One observation I would like to make concerns the way most organizations require users to change passwords frequently, say every 30 days, and not reuse passwords for a long time. This is an example of a procedure that, theoretically improves security but actually reduces security. The theory is that the vulnerability of a password to discovery is proportional to the length of time available to discover it. Although this is technically true, in practice it doesn't work that way. If token-based security is not used and someone wants your password, this person would probably have it in less than a day by "shoulder surfing" or by intercepting keystrokes. Even if the password has to be broken by brute force, this can usually be achieved in most cases in a matter of hours by variations on a dictionary attack. (A dictionary attack is a brute force attack in which all valid words in a language are tried out for validity. Attackers may also try common variations on the words, such as adding numbers.) This is especially true when the passwords are changed often because people tend to make them easy to remember, following themes such as children's names, favorite hobbies, or computer terms, and tend to reuse passwords from other systems. If a password can be broken in a day, how much value is added by changing it every 30 days? If the passwords are forced to be effectively random, then they will end up being written down and be much more open to discovery.
My preference is token-based security for situations in which security is critical. If not, I prefer truly random keys changed infrequently, maybe yearly, or when it is thought that the password may have been compromised. This approach gives a little more exposure to "shoulder surfing," but with care, it shcould improve overall security and usability. This example illustrates the importance of operational security procedures.
Today, securing distributed systems requires a combination of several different types of products. SSL provides link encryption for the Internet and some authentication. Products based on Kerberos or RSA technology can be used to secure the middleware environment, albeit with some integration effort. Some middleware products, such as Tuxedo, provide built-in security facilities, and some Net-based applications, such as Lotus Notes, also provide security facilities. Standards are beginning to emerge for at least securing the messaging part of distributed systems, with secure IIOP being one of the more important areas.
Authentication capabilities, especially single sign-on, are limited today. It may be some time before there is widespread availability of single sign-on authentication implemented on the server side to cover many environments. In the short term, the most promising approach is the use of SmartCard or PCCard technology to give the appearance of single sign-on by holding many keys.
Distributed systems security is an exciting and important area. Providing rock-solid security for the Inter/intra/extranet is essential for it to reach its enormous potential. Hopefully, we can look forward to a brave new secure world on the Net.
|
CyberSafe Corp. www.cybersafe.com Gateway to Information Security www.securityserver.com Gemplus www.genplus.com GSS-API several sites have this informaion, including www.ansi.org and www.ccs.org IBM www.ibm.corp/security Intel Corp. developer.intel.com/ial/security/cdsa/index.shtml (forCDSA) IriScan Inc. www.iriscan.com JavaSoft a division of Sun Microsystems Inc. Frequently Asked Questions: Applet Security, www.javasoft.com/sfaq/index.shtml Massachusetts Institute of Technology home of the original Kerberos, web.mit.eu/kerberos/www/index.shtml NeTegrity Inc. www.netegrity.com or www.security.com Netscape Communications Corp lists the SSL spec and supporting information in several locations on its Web site, www.netscape.com Object Management Group www.omg.org Open Systems Foundation home of DCE, www.opengroup.org/tech/dce/security Protegrity Inc. www.protegrity.com Rainbow Technologies Inc www.rainbow.com RSA Data Security Inc www.rsa.com Sun Microsystems Inc (SunScreen product), www.sun.com/security/overview.html |