The phenomenal growth of the World Wide Web has simultaneously breathed new life into old databases and stirred up a host of new questions (pun intended). Questions like: How do I protect databases while serving up data to the Web? How can I prevent unauthorized changes to Web pages while making them available to the entire Internet-enabled world. Information security professionals who are grappling with these problems can offer some suggestions (see "Web Security Standards"), but as yet there are no guaranteed solutions. Surprised? Maybe you've been reading articles and product brochures touting the imminent arrival of secure transactions and bullet-proof network protection, or recent press releases about certifying the safety Web sites.

While some of these products and proposals are clearly a step in the right direction, nobody who is objective about security is actually going to certify any Web site or Internet product as risk-free or hacker-proof. The best we can hope for is meaningful reassurance and significant risk reduction. In this article I look at ways of reducing the risk to online data projects and consider what the various Web assurance programs can do to help. I begin with a look at what can go wrong if you ignore security issues when you dish up data on the Web.

A Whole New Dimension?

Let us suppose that a few years ago you developed an inventory database for a shop that sells and warehouses fur coats. Recently the store owner, we'll call him Mr. K, asked if you could together a Web site for him. Nothing fancy, just something to tell the world that K's Furs offers the finest garments and the best storage facilities in all of, let's say, New York City. Perhaps add a list of items currently in stock, for prospective customers to peruse.

Sounds pretty straightforward, right? You've already set up your own Web site and, let's face it, this HTML stuff is a snap compared to SQL, OBDC, and a few other acronyms you've had to master. To use an British expression, this Web project could be "a nice little earner." If that's what you think, try this expression, "Welcome to my nightmare." Why? Because www really does mean World Wide Web. Your work will be seen by everyone in the whole wide world who has an Internet connection, which is both a blessing and a curse.

If you hadn't noticed, not all of these people, and there may be over 40 million of them by now, share the same values. For example, some people think it is wrong to kill animals for fur. If you live in New York you might have noticed anti-fur posters on city buses. What if someone who agrees with that message decides to target Mr. K's Web pages. Defacing Web pages is a heck of a lot safer than spray-painting billboards or smashing shop windows--attract attention to your cause without ever leaving your keyboard. Which is exactly what somebody did last November to a New York-based fur company. The poster image from the bus was plastered all over the home page, along with numerous slogans and an altered version of the company logo.

In other words, developing for the Web encompasses issues that are quite different from projects that are internal, such as databases for the LAN and WAN environment. Security concerns become much broader than proper password hygiene and access control lists for authorized users. Web sites can become targets for everyone from competitors to disgruntled employees, from political activists to wired whackos. When the U.S. Department of Justice Web site was hit in August, followed by the CIA in September, some people thought political sites would be the main focus of Web vandalism. But I know of several commercial sites, besides the fur company, that have been "altered."

Possible Responses

So how do we respond? The first step is to evaluate the risks. Unfortunately, this is hard to do when there is a lack of well-documented historical data, which is exactly the case for computer security in general and Web security in particular. One approach, outlined by G. Lynch in a Gartner Group white paper, is to focus on the human aspect of the threat, what is typically referred to as the threat agent. By understanding the types of threat agents that might cause harm to your operation you can "prioritize the likelihood and prepare countermeasures." Lynch identifies three key criteria that must be analyzed when performing threat agent analysis:

1. An understanding of how strongly the threat agent is motivated.

2. An assessment of the opportunity a threat agent has available to execute a particular threat.

3. A determination of how available the tools and knowledge (i.e., means) are for carrying out the threat.

What we have here is a twist on the traditional crime fighter's quest for means, motive, and opportunity. Who would want to compromise your system? How strongly are they motivated and what technical capabilities do they posses? It is not hard to imagine a matrix that maps the answers, ranging from the recently fired network administrator (lots of motive and capability) to your latest competitor (a lot of motive perhaps, but may lack capability).

After risks have been weighed you can proceed to action on a technical level, beginning with a review of current security, if your site is already up and running, or secure design elements is your site is still in the planning phase. There are several design options that can reduce or displace the risks, such as having 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, you might want to arrange some sort of site monitoring and the issues of content, what you actually put on your site will still be up to you. For example, if you are engaged in an activity that is not universally appreciated, such as clear-felling old growth timber, you might want to get some outside input on how to tone down your site to make it less of a target.

If you are doing your own hosting, you might want to configure the web server machine as a "sacrificial lamb." This is a minimally connected, basically expendable, and quickly recoverable machine. You make regular backups, run some sort of tripwire to alert you to unauthorized changes, and hope to restore normal service as soon as possible after an attack. This 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 10x 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 Mr. K's database of current fur 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 (links to both exist at www.2cobbs.com/wwwsec).

A Certified Site?

Many security professionals are naturally paranoid. Faced with a choice between two different security mechanisms we tend to choose both. For example, it has been said that firewalls are no substitute for solid internal network security. It has also been said that solid internal network security can obviate the need for a firewall. I tend to recommend both, solid internal network security and a firewall. In other words, defense in depth or layered security. The comprehensive approach to protecting a Web site means following best practices in many different areas.

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 now 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, which brings us back to the comprehensive approach to protecting a Web site. A site that is NCSA-certified will confirm to best practices in many different areas (outlined in "Web Security Standards"). The plan is to certify sites that meet the published standards, as determined by a combination of physical site visits, audited site documentation, and remote testing. 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.

Other Web Security Initiatives

Several other programs are now emerging to offer different types of security and assurance on the Web. These include: Red Alert from Internet Resources Group, a site monitoring service; True Site from Application Programming and Development, Inc., a site verifying service; BBBOnline from the Better Business Bureau, a service to assure Web sites compliance with business standards; and eTRUST from the Electronic Frontier Foundation, launched to establish trust and confidence in electronic transactions.

Red Alert (www.redalert.com)
For a monthly fee, Red Alert detects a wide range of error conditions at your Web site, 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). 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.

True Site (www.truesite.net)
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 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 they could post it at www.bankhater.com, with my own subtle alterations, perhaps as a protest at a recent loan refusal. 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.

The purpose of TrueSite is to defeat this sort of thing by means of a list of verified sites. A TrueSite logo is issued which links to a list of verified sites. This list is searchable and only leads to "real" sites. However, at this point the problem of bogus sites does not seem to be the main security concern of Web managers and it is unclear to what extent TrueSite will catch on as a way to discourage bogus sites.

BBBOnline (www.bbbonline.org)
Billed as "the solution to consumer confidence and to business voluntary self-regulation in the electronic marketplace" BBBOnline, Inc. is a wholly-owned subsidiary of the Council of Better Business Bureaus, which describes itself as "the premier promoter of the highest ethical relationship between businesses and the public." BBBOnline is designed 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.

Companies that meet high 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. Linked to this site as well 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.

eTRUST (www.etrust.org)
The idea of eTRUST, created by the Electronic Frontier Foundation, 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.

Conclusion

Developing databases for the Web means that you have to consider a wide range of issues which previously had very little to do with database development. Issues of appearance, tone, and social implications. Issues of risk assessment and appropriate defensive measures. Several projects and products are emerging that may help, from alerting you to unauthorized changes, to helping you prevent such changes in the first place. Mechanisms for assuring visitors about privacy and commercial trust issues are also emerging. The importance of giving visitors a way of complaining other than trashing your site should not be under-estimated. And a lot of problems can be avoided at the outset by giving as much consideration to what our sites look and feel like, as we do to how they are configured.

Box: Web Security Standards

Here 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. They provide assurance to web users, and organizations represented by web sites, that certified sites meet minimum standards for a range of logical and physical security issues. Users who visit an NCSA Certified Web Site can expect that the site has taken the necessary security measures to prevent intrusion, tampering, data loss or theft, and hacking.

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 the above is an abbreviated outline of requirements for single server sites. There are additional requirements when one server is hosting multiple web sites.