Introduction

While it is possible to argue that "Internet statistic" is an oxymoron, it is hard to deny that the volume of commercial transactions conducted via the Internet is growing rapidly.[1] The World Wide Web has dramatically lowered the cost of entry into electronic commerce. At the same time it has raised a lot of new questions, such as: Is it safe to exchange confidential information on a public data network? How risky are credit card purchases at Web sites? How can you be sure a Web site is genuine?

This article addresses these questions with a review of the risks involved in Web commerce and a look at some of the efforts being made to reassure Web users (clients) and Web site owners (servers).

The Current Model

Despite much talk about paradigm-shifts, the shape of computing today remains the familiar one diagrammed in Figure 1, consisting of three parts: client-link-server.[2] This is certainly the model followed by Web commerce, where the person with the Web browser is the client, the Internet is the link, and the Web site is the server. From a security perspective, there are problems with all three sections of this model.

Client Risks. Many people browsing the Web are nervous about engaging in commercial transactions. Is the site genuine? Can they trust the company that operates the site? Companies considering dispensing sensitive data to Web clients are also concerned. Will they be held liable for unauthorized disclosure of confidential residing on desktop or notebook systems? As is the case with many other aspects of information technology, the legal system has yet to pass judgment on many of the issues involved.[3]

Link Risks. Data must be protected from "sniffing" or disclosure as it traverses the client-server link. The link must be secured against bogus or "spoofed" messages. This is a non-trivial problem when the link is the Internet, which no single authority owns, controls, manages, maintains, or secures. The Internet link is not a single connection, but a series of connections between numerous machines. The link may include modem lines to local ISPs or public data networks, routing systems and DNS servers at ISPs, and a variety of machines along the national and international backbones traversed by the data. The link may also include one or most local area network systems within company offices and on college campuses. Clearly, data traveling along such diverse and open routes is subject to interception, eavesdropping, even alteration. The link can be cut or service restricted, either by error or intent.

Server Risks. Companies want to serve up data via the Web, either to a select group of users, or the entire Web-enabled world, without fear of unauthorized changes to that data. One sub-set of this problem, unauthorized changes to public Web pages, has received a lot of media attention, owing to high profile hacks of Web sites belonging to the US Department of Justice and the CIA.[4] It is clear that, because the Web is truly world wide, some sites, which seem probably harmless to their creators, may offend other inhabitants of the online world, some of whom could feel obliged to respond aggressively.[5] We have seen such responses range from defacing pages and altering links, to denial of service, preventing people from accessing a site by deluging it with phony messages.[6]

Reassuring Clients
Several projects are under way to reassure users of the Web. The first, TrueSite, deals with an issue that many people woke up to last November, after Bob Dole made the historic first mention of a campaign Web address (www.dolekemp96.org) during a U.S. Presidential Campaign Debate. The following day there were many reports that the site had been hacked, when in fact people were visiting several spoof sites with plausible names like dole-kemp96.org and dole96.org. Although some companies have gone to great lengths to "bracket" their domain name registrations with likely variations, it is not always possible or practical to cover all the possibilities. Because it is so easy to copy an entire Web site, graphics and all, then post the same site at a different address, there is a always risk that someone will do just that, for malicious or political purposes.

For example, I might copy www.megabank.com (a fictitious entity that I just dreamed up and for which, as yet, no URL exists). Then I could serve it up on the Web at www.bankhater.com, with my own subtle alterations, perhaps as a protest against a recent loan refusal. Some search engines would dish it up to people looking for the real MegaBank site. I might even create www.megabank.org and try to get customer information from people who arrived there by mistake.

Several months before the Presidential Debates a Maryland-based company called Application Programming and Development, Inc., launched a service called Truesite, which assures users of a site that it is genuine. When a site is properly registered, a TrueSite logo is issued. When users of a certified site click on the logo it links them directly to a list of verified sites. It is also possible to access all of the certified sites directly from a master list that is searchable and only leads to "real" sites.[7] At this point it is unclear to what extent TrueSite will catch on as a way to discourage bogus sites, particularly since it is operated by a company that is relatively unknown in this field.

One very well-known organization, the Council of Better Business Bureaus, has launched a wholly-owned subsidiary called BBBOnline, to address the problem of consumer confidence in Web commerce and encourage voluntary self-regulation by businesses operating in the electronic marketplace. BBBOnline is intended to "identify, for consumers, those online marketers who meet high standards, make significant commitments to their customers, and agree to resolve complaints quickly and fairly." [8]

Companies that meet BBBOnline Standards will exhibit a BBBOnline CARE seal on their pages. The seal will show that they "care" about their customers. Consumers will be able to click on the logo and instantly get a BBB company report on the company. Web consumers will also have the option of searching the comprehensive Better Business Bureau database of BBB company reports. Also linked to this site will be the extensive library of Better Business Bureau consumer and business advisory publications, useful links for related information and other advisory products. All of which seems like a worthwhile effort to provide assurance in terms of business practices. However, it does not dictate any specific security standards, for example, in the protection of private information supplied by the consumer to the site.

Assurances about privacy are main thrust of eTRUST, created by the Electronic Frontier Foundation.[9] The goal is to "promote the mass adoption of electronic commerce by creating an infrastructure to establish and evolve guidelines on issues such as privacy, security and authentication." Tackling privacy first, eTRUST has developed, and is about to license, symbols of privacy and security, called trustmarks, to on-line merchants. There are three different trustmarks that will be used to indicate the privacy status of Web pages.

The "No Exchange Trustmark" implies anonymous usage, anonymous transactions, anonymous chat and anonymous tracking. The "1 to 1 Exchange Trustmark" implies no disclosure of individual or transactional data to third parties. The "3rd Party Exchange Trustmark" informs the user that the site will be disclosing information with third parties. Given the level of paranoia about privacy in some circles, efforts like this may well be required to reassure Web users who don't like the idea of sites tracking where they have come from and where they are going, and possibly turning such data into market research data. As with BBBOnline this program is more of an ethical commitment than a mandated security standard for Web sites.

Web Site Security Standards
Unfortunately, attempts to develop standards for information security tend to move much slower than the technology they seek to defend. One organization that does have a decent track record in this area happens to be the one I work for, the National Computer Security Association. A private company based in Carlisle, Pennsylvania, NCSA started to set standards for anti-virus software several years ago. A set of tests was devised. Products which passed were deemed NCSA-certified. At first, the process faced sharp criticism: "Not strict enough" and "Just a marketing ploy."

Over time, as test criteria evolved, these criticisms were laid to rest. Today, an anti-virus program cannot be NCSA-certified unless it detects 100% of all currently active viruses (these are the "in the wild" viruses, numbered in the hundreds, as opposed to the "in the zoo" viruses which, although numbered in the thousands, aren't actually infecting any computers). The benefits and effectiveness of the program are now reflected in the fact that anti-virus vendors often make improvements to their products just to meet the NCSA certification standards. End-users can now avoid running their own tests, which are inherently difficult to organize and control (first catch your live viruses, then release and see if your defensive measures can detect them, be prepared to devise and initiate disinfection procedures if they don't).

This process of setting baseline security standards and then progressively raising the bar has since been applied to firewalls, technology developed to protect connections between trusted and untrusted networks. As with anti-virus certification, there has been some initial criticism, but NCSA certification will probably emerge as a meaningful standard that firewall users will expect products to meet. Of course, NCSA recognizes that firewalls are considerably more complex than anti-virus products. For example, they should only be used as part of a comprehensive security policy and, because each installation is unique, firewalls are one defense that should also be tested after installation (you can read more about firewall policy at www.ncsa.com/fpfs/fwpg_p1.html and there's more on testing, plus detailed descriptions of 20 firewalls, in the NCSA Firewall Buyer's Guide, which can be ordered from www.ncsa.com).

NCSA is now planning a certification process for Web sites. The intention is to provide several types of reassurance to users of the Web. First of all, they will know that, if a site conforms to the standards specified for NCSA Web site certification, the site is as safe from hacking as it is practically possible to be. Second, if the site bears the NCSA Certified logo, users will know that it has passed a site inspection by NCSA-approved inspectors. Certified sites will also be tested, over the wire, with a suite of tools developed by NCSA.

The goal is get to a point where an NCSA Certified Web site is impervious to all real world attacks. Clearly, the definition and enumeration of "real world attacks" will require a lot of debate and research, which is currently under way. The initial standards themselves were derived from extensive discussions with a large group of experts, including Scott Ramsey, director of Ernst & Young's information security division, Larry Hughes Jr., Internet security author and lecturer, Dr. Myron Cramer and Jay Harrell from Georgia Tech Research Institute.

The term "real world attacks" is used to distinguish between theoretical or "actual yet highly unlikely attacks" and those which are actively being exploited to compromise Web sites. Since security budgets are never unlimited, it is important to focus protection on those attacks most likely to occur. Through ongoing research efforts and a constant dialogue with vendors, users, and experts, NCSA is well-placed to determine what exactly these threats are.

The following are some of the main guidelines from the NCSA's Web Site Certification process. Intended to ensure a base level of security rather than guarantee that a site is hacker-proof, they nevertheless represent a worthwhile starting point. Current standards and all future improvements will be published on the NCSA's web site so that anyone hosting a Web may use them as a guideline for security standards, even if they decide not to participate in the commercial certification process.[10]

1. The web site must withstand network-based attacks by means of a firewall, filtering router, or other appropriate security mechanism.

2. The Domain Naming Service (DNS) entries for all URL referenced systems must be resolvable.

3. The NIC contact information must be accurate and contain at least two contacts.

4. The site must maintain logging. Access to logs must be limited to authorized personnel. Logs must be retained in a secure but retrievable format.

5. A standard encryption mechanism must be used for sensitive data transmission.

6. A person must be designated as the site's "CGI Evaluator." This person is responsible for examining and evaluating all cgi scripts and programs. No interpreters should be accessible via HTTP.

7. A person must be designated as the site's "CxE Evaluator." All client executables must be examined and evaluated as "harmless" to the user.

8. Pages which contain or accept sensitive data must be made non-cacheable. Users must be informed if any pages containing sensitive data will be cached to local storage.

9. The site must meet physical security requirements such as: access controlled area, roster of authorized personnel, suitable equipment, and emergency contact information.

10. The site must meet logical security requirements such as: secure password policies, webmaster contact, HTTPD server configured for least privilege, and separate development and production systems.

11. If a transaction mechanism is in place, it must be documented and the server's private key protected by a strong passphrase. Sensitive information must be periodically removed from server. The OS/Platform must be documented and integrity assured. Backups and Restore capabilities must be in place.

Note that this an abbreviated outline of requirements for single server sites. There are additional requirements when one server is hosting multiple web sites.[11]

Practical Steps
The above guidelines should be self-explanatory to an experienced Web site administrator. In this section I will discuss some options for those who have just started to consider setting up a Web site. One popular option is to have your site virtually hosted by a specialist company or Internet Service Provider (ISP). This shifts the burden of protection to them and they have a clear financial incentive to deliver. However, issues of content will still be your responsibility. For example, if you are engaged in an activity that is not universally appreciated, such as selling fur coats, you might want to get some outside input on how to tone down your site to make it less of a target. You might also want to arrange some sort of site monitoring, which I will discuss in a moment.

If you are doing your own hosting, you might want to configure the Web server as a "sacrificial lamb." This is a minimally connected, basically expendable, and quickly recoverable machine. You make regular backups, run some sort of tripwire or monitoring to alert you to unauthorized changes, and hope to restore normal service as soon as possible after an attack. For a monthly fee, a service called Red Alert will monitor your site and detects a wide range of error conditions, such as: crash or loss of Internet connectivity to your Web server machine; failure of your server software to open connections; failure of your server software to return data in response to an HTTP request; incorrect data returned by your server or cgi software; and HTTP errors returned by your server software (server busy, file not found, and so on).[12]

Red Alert can notify you of errors via: Email; numeric paging, with coded messages for each URL and error type; or alphanumeric paging, with written error descriptions. This seems to be a very practical service, valuable for organizations that don't have 7x24 staffing to watch over a site. Detection is a valuable security tool and Red Alert gives you instant access to a log of errors for the last 60 days. I also think the presence of the Red Alert logo might discourage the kind of vandal who is hoping that his or her handiwork will be visible for a meaningful period of time.

The sacrificial lamb approach is particularly suited to an "information only" site, where a connection to send or receive user-specific information is not required. In fact, it is possible to go one step further and make such a site read-only at the hardware level. For example, on a standalone site development machine you use a CDR drive to burn a $7 CD-ROM copy of the site. You then walk that over to the Web server, slip it in the CD-ROM drive and serve up pages that cannot possibly be altered. When changes to Web pages are required, you burn another CD.

Current CD-ROM drive performance falls short of the requirements for Web hosting, but with the latest 12X SCSI devices the gap is narrowing, and clever use of RAM caching, or even a RAM drive, could close that gap. An alternative might be optical drive cartridges, which can match hard drive performance and have physical write protection switches. Of course, sacrificial lambs and read-only servers run into problems if you want to connect to the server in any extended fashion, for example to serve up a database of current inventory.

While some databases queried by Web pages can be extracted from production servers and mirrored on a secure machine, some people want their Web sites to serve up "live" data. In either scenario, the connection and processes used to transmit queries and responses are a potential path into your systems and must be protected. A firewall of some type is the usual solution, strictly controlling access between the Web server on the outside and the database systems on the inside.

If your Web site is already up and running, two items to check right away are cgi scripts and NFS, vulnerabilities allegedly exploited in the DoJ and CIA hacks, respectively (the DoJ server had an unused by insecure cgi script left over from installation and the CIA site was being maintained remotely by a sub-contractor using NFS, allegedly). For more details, you should check out Lincoln Stein's excellent World Wide Web Security FAQ and you might want to subscribe to the www-security mailing list.[13]

Conclusions
Web commerce will not succeed unless a significant percentage of potential users, the millions of people currently surfing the Web, become actual customers. Genuine efforts are now under way to reassure users that sites are properly secured and responsibly operated, by ethical businesses which are committed to the preservation of privacy and

Notes:

[1] One of the best sources on the Web is www.cyberatlas.com. For a thorough treatment of Web and Internet statistics see Hoffman, Kalsbeek and Novak in Communications of the ACM, Volume 39, Number 12, December 1996, pp. 36-46.

[2] Thanks to my colleague, Michael Miora, of Miora Systems Consulting, for his succinct delineation of this model.

[3] Here is an example of what I call the "leaky client" problem: an HMO lets patients have Web access to their medical information; a man who is HIV-positive accesses his record; he then takes his PC in for an upgrade; the technician learns of the man's condition from data cached on the hard drive. It is unclear how much a party disclosing personal information over the Web must do to inform people of all the ways in which such information could be leaked, accidentally or maliciously, from their PC.

[4] www.usdoj.gov was hit in August, 1996 and www.odci.gov/cia was vandalized the month after. Less widely reported hacks in 1996 include several cable television network Web sites and the Florida Supreme Court site.

[5] In November a Web site operated by a fur retailer in New York was heavily vandalised, apparently by animal rights protesters. Examples of what might be called "culturally-motivated hacking" have been seen at Jewish and right wing Web sites.

[6] PANIX, the New York ISP, was apparently targeted by someone whose account there had been closed. He used the "SYN flood attack," described in several hacking publications, which exploits the basic design of IP to open multiple bogus connections until the server is overloaded. In this case it prevented PANIX customers from getting their email and stopped Web users from visiting sites hosted by PANIX.

[7] The Truesite Web site is www.truesite.com.

[8] The BBBOnline site is www.bbbonline.org.

[9] eTRUST is online at www.etrust.org.

[10] The NCSA's Web site is www.ncsa.com (NCSA is a registered trademark of the National Computer Security Association).

[11] If you have suggestions for additions or improvements, or would like to comment on these guidelines, please do so by emailing sglesner@ncsa.com.

[12] Red Alert is one the Web at www.redalert.com.

[13] Links to both of these, and Marcus Ranum's excellent Firewalls FAQ, can be found at www.2cobbs.com/wwwsec.

Figure 1: Sample Internet/Web Statistics

Figure 2: The Shape of Computing Today