Network Computingwww.networkcomputing.com

Building E-Commerce

December 15, 1998

Keeping this kind of server secure means following the usual guides for securing a Web server with the added measure of using encryption to protect any payment transactions. Many Web storefronts actually run these transactions off separate server machines that are more tightly protected than the server hosting the site. While securing your Web server is another article topic unto itself, a nutshell list might run as follows:

1. Pick a secure Web server: a platform that supports at least, SSL, S-HTTP and RSA encryption.
2. Manage access control and an up-to-date access control list, especially with regards to your payment server
3. Use authentication wherever possible
4. Employ some measure of protection against typical hacking attacks, such as outside traffic analysis (snooping), viruses and user masquerades (spoofing).

Relatively few operating systems contain enough internal security features to measure up to an e-commerce serverís needs. Unix and Linux offer superior security and connectivity options, but at a cost of added complexity and a more limited number of available third-party applications. Windows NT, on the other hand, also has good security, great ease of use and a huge third-party ISV base. Unfortunately, NT canít measure up to Unix or Linux in terms of scalability or reliability. Not only will you require more NT boxes to handle the same user load as a single Unix box, youíll also have to pay more attention to them.

Additionally, if youíre employing a credit-based payment method (see below), whether itís Unix- or NT-based, be sure it supports the SET (Secure Electronic Transaction) standard. The SET suite of applications was specifically designed to allow for secure credit-card transactions over the Internet and is considered the most popular standard to date, especially since itís supported by both MasterCard and Visa. SET protects merchants and customers alike by protecting payment information confidentiality, providing cardholder authentication, and ensuring the transmitted data integrity of payments. Whatís important about SET is that itís probably the most secure open standard and that commerce vendors are building their products with this standard in mind. Implementing it on your commerce server now means less headaches when adding or upgrading new third-party commerce modules in the future.

Extranet servers are far more complicated to protect than Web storefronts for two reasons. First, they usually allow much deeper access into sensitive company files, and second, their nature allows network managers more leeway in protecting them.

For instance, one of the hottest ways to protect such servers today is to employ a VPN (virtual private network) between you and your partners. Obviously, this only works if you have a very closed set of associates who will have access to your extranet. If thatís the case, VPNs are marvelous at keeping your data secure. A VPN uses the Internet to create a secure, private tunnel between your network and someone elseís. Not only does this protect against outside intrusions, it also lets you run network protocols other than TCP/IP.

The downside to VPNs in this case is organization. If your extranet is designed to allow new partners to register and then gain access in addition to existing partners, a VPN would be a difficult solution since it requires client software in addition to the Internet connection. In this case, youíre stuck using most of the Web server security measurements mentioned above, but with the added ability of using password or even directory authentication as well as secure protocols, digital signatures and industrial-strength encryption. You could run two separate servers, one thatís VPN-enabled for registered partners and another traditional Web server for the business community at large. Again, however, that means multiple servers and the added question of where each will reside-behind or outside the firewall?

You may as well face it now: The odds of your entire Web commerce segment running quietly outside the firewall is practically nil. The need to communicate with legacy systems alone dashes those hopes. But honestly, this wonít be nearly as ugly a migraine as buying WAN bandwidth, for instance. Once again, you just need to be sure to test. Figure out which applications will need to communicate through the firewall, then run simulations during low traffic hours.

Can the firewall handle the traffic or will it need additional muscle as well? Will all your protocols and file types be supported? Does this open any new security loopholes and how can you fill them? If you intend on running a VPN solution for part of this commerce project, be sure itís compatible with your present firewall architecture. Just take it one step at a time, and remember that paranoia is a positive character trait.