Search our
entire site
Enter your search
terms below, or visit
our search page

Search case
studies only
Enter your search
terms below:

For the table
of contents and
hyperlinks to
general topics
proceed to toc

Ten Commandments For Converting Your Intranet Into A Secure Extranet

MARCH 1999

Just as the corporate intranet has transformed the way in which information is disseminated within an organization, inter-company extranets are revolutionizing the way in which enterprises interact with one another. For the first time in computing history, a set of unified technologies have emerged that bridge the gap between heterogeneous computing environments. These include a standard for data transfer (the http protocol), a consistent user interface (the browsers), and universal connectivity (the Internet). These technologies have changed the way companies sell products, provide customer support, manage their supply chain, and perform collaborative research.

As with any business relationship, the tighter the link between your organization and your partners, the more valuable the relationship is. This link can be made only through the sharing of information in a secure environment. To do this, the critical issue of security needs to be addressed. As recent statistics show, security is the main issue preventing organizations from establishing extranets. Zona Research discovered that 70 percent of MIS professionals see security as the most important electronic-commerce issue. A similar survey by Ernst & Young and Information Week showed that only a quarter of those using the Internet for business purposes were satisfied with security, and two-thirds of those not using the Internet cited security as the reason.

The major difference between an intranet and an extranet is security. Follow these Ten Commandments of extranet security and your migration will be more safe and sane.

I. Thou shalt recognize the key components of an extranet security program. Effective extranet security requires authenticating users, controlling access to information and resources based on an authenticated identity, encrypting data as it travels over the Internet, and administering security that spans multiple organizations. As we see later, the solutions used in each of these categories differ between the intranet and extranet environments. The reason for these differences lies in an extranet's use of an untrusted network for communications, the need to strongly identify users and tightly control the resources they can access, and the difficulties in developing and implementing security solutions across different entities where control is difficult to maintain.

II. Thou shalt understand the goals of extranet security. The goals of extranet security are threefold. First, ensure that establishment of an extranet does not weaken your existing network security by introducing additional ways for outsiders to gain access to systems behind the firewall. Second, ensure that extranet users can access only the information they are entitled to and that others cannot access that information. Third, recognize that eliminating all risk is impossible, and evaluate solutions that limit risk to an acceptable level while balancing usability and manageability. Every organization needs to understand its own risk tolerance and evaluate security products accordingly.

III. Thou shalt use layered security products. Dedicated products will always provide better security than the "built-in" security features of your off-the-shelf servers and applications. Rather than relying only on the encryption, authentication, and authorization methods in your existing applications, consider horizontal solutions with a consistent set of these services across multiple applications. Layered security also provides better usability and manageability than server and application-level services. Examples of these products include VPN (Virtual Private Network) products that transparently encrypt all network traffic regardless of application, and Single Sign-On (SSO) and Kerberos-based authentication layers that include multiple authentication methods and eliminate the need to remember multiple passwords.

IV. Thy data shalt not travel unencrypted. Within your intranet, encryption may not be an important concern. But extranets are used to share information with outside partners, suppliers, and customers using the Internet, requiring that data be encrypted as it travels across the untrusted network.

Encryption can be performed at the network level using VPN products such as encrypting routers or firewalls, or at the application level through Web browsers and servers supporting Secure Sockets Layer (SSL). The advantage of VPN products is their layer of application-independent encryption for all network traffic between the connected LANs. Unfortunately, they require specialized hardware or software installed at each end of the secure tunnel. Additionally, VPN standards have not taken complete hold in the marketplace yet, forcing users to use the products from the same manufacturer for complete assurance of interoperability. Expect this situation to improve considerably over the next year as more IPsec-compliant products become available.

SSL has the advantage of already being available in popular Web browsers such as Netscape Navigator and Microsoft's Internet Explorer, which eliminates the need for extranet participants to install additional components into their network. A major drawback of SSL is that it is commonly used only for the http protocol, requiring additional encryption solutions to be employed for other network protocols. If SSL is used for encryption with the "Basic Authentication" protocol for authentication, it is important that your servers support SSL for encrypting both the data and the login information sent during password-based authentication. Failure to do so means that the username and password will travel over the Internet in plain text, vulnerable to the proverbial hacker with a packet sniffer.

V. Thou shalt not rely on basic authentication. Except in certain security-aware industries such as health care, banking, and finance, intranet users typically authenticate themselves by entering username and password combinations. Because the user is behind a firewall, many organizations feel this is sufficient assurance of the user's identity. Recognizing the deficiencies of this rudimentary authentication method, many organizations are now using digital certificates stored in the user's browser or on their desktop system.

Basic authentication doesn't work for extranets. Stronger forms of authentication than just user/password combinations are needed. There are two main reasons for this: most extranet users originate from an untrusted network, and most servers and applications lack support for an encrypted exchange of login information. Organizations need to consider more secure methods of authentication such as Kerberos, digital certificates, smart cards, hardware tokens, or even biometric devices.

VI. Thou shalt augment access controls. A necessary component of security is controlling access to information and services after you have authenticated the user's identity. Your extranet will require more fine-grained access control than your intranet as you are providing your outside partners selective access to corporate information based on their relationship to your organization. For example, if a back-end database is accessed through a Web interface, your extranet partner should be able to access only the records related to themselves and no one else.

You could accomplish this fine-grained access control through use of the built-in functions that the various Web servers and applications have for authenticating users and controlling their access to static Web pages and dynamically generated content. Unfortunately, Web servers and applications were originally chosen based on the business needs they serve, not the security they provide. Trust that at least one of the extranet applications will lack strong authentication or object-level access controls. Solve this by introducing a centralized authentication and authorization layer into your security architecture.

VII. Thou shalt understand the balance of power. This one is easy. What can you demand from your users? The relationship between the extranet owner and users will determine viable security solutions. For example, when a large national retail chain sets up an extranet for its suppliers, the chain can force its users to adopt and use the security solutions it chooses. Suppliers may be required to use smart cards for authentication or purchase encrypting routers or firewalls to create a secure VPN between the organizations.

When selecting security solutions, there is always a trade-off between security and usability of the information systems being protected. In an extranet, user-friendliness is as important as security in ensuring that the extranet is used and the organizations gain maximum value from their collaboration. Security, though, cannot be ignored. It is crucial that partners trust network security, as they will not share their information in an insecure environment.

VIII. Thou shalt consider the user population. The demographics of your user base helps dictate the applicable security solutions. In the area of encryption, an extranet consisting of a few companies working closely together can adopt hardware-based VPN solutions to create a private network over the public Internet. This will not work if your users come from dozens of companies.

Your user population also determines the selection and procedures for implementing user authentication. Authentication requires your user to have some form of identification (a password, digital certificate, smart card, or hardware token). The key issue in extranets is managing the distribution of this form of identification to the user. The number of user organizations, the relationship between the extranet owner and these organizations, and the number of users from each partner determine whether the organization will handle distribution itself or delegate it to partners.

For example, digital certificates require a trusted certificate authority, a means of distributing these certificates to users, and a way of determining whether or not the certificates are still valid (certificate-revocation lists). If the number of users of the extranet is small and limited to a few partners, the organization may decide to issue certificates itself, working with the partner organization to ensure that users remain valid members of the partner organization. An alternative would be for an organization to establish a trust relationship with its partner's certificate authority. In this case, it would accept any certificate issued by that partner. It would still need to check the partner's certificate revocation list to confirm the ongoing validity of the certificate. A third option would be to use a trusted third party for issuing certificates. Unfortunately this involves additional time and expense, and as these organizations only verify identity, the need to confirm organizational status still exists.

IX. Thou shalt know thy applications. Unlike intranets dominated by basic publishing applications, extranets are used for business processes of a transactional nature (purchasing and selling), often called business-to-business electronic commerce. Not only do these transactions contain more sensitive information, they usually are performed by applications that lack robust security models. You must take a hard look at your applications to determine potential security holes, and evaluate how your extranet's security can be hardened.

X. Thou shalt determine the degree of integration with the intranet. To create the Alcatraz of secure extranets, corporate information must be copied onto servers that are outside the corporate firewall, an area often called the demilitarized zone. Then external users are limited to these exiled systems, presenting little risk to the systems that sit behind the firewall. Unfortunately, this configuration can be used only in limited situations. To gain the most value from extranets, partners need access to information from a diverse variety of sources within the secure corporate intranet. This requires strong authentication for external users and the ability to apply object-level access controls to information and services based on user and group identities.