Security Scans

 
 
By Peter Coffee  |  Posted 2001-03-12 Email Print this article Print
 
 
 
 
 
 
 

Earning e-business confidence

In the early days of air travel, danger and glamour went hand in hand with the novelty of the experience. But as jet-set exclusivity turned to tourist-class ubiquity, passengers came to take safety for granted.

So, too, must the security of e-business transactions cease to be a high-profile customer concern; only then will the online marketplace reach its full potential. In the same way airlines can now boast that air travel is safer than driving, in terms of passenger miles, e-business operators must be able to affirm that doing business on the Internet is at least as safe as buying and selling in any other medium.

From that starting point, the distinctive strengths of electronic business—its convenience, its selection, its efficiency—will enjoy their full advantage.

There are retail establishments, such as high-end jewelry stores, that put their security up front and in plain sight. Many retail Web sites have much the same aura, with their user names and passwords, cookies and browser dialog boxes advising, ?You are about to view pages over a secure connection.?

However, a jewelry store with guards in front may have an unlocked service entrance in back. And a store may check the identification of every customer who wants to pay by check or credit card, while routinely admitting anyone wearing a UPS or FedEx uniform.

Likewise, a Web site may intimidate users with the outward inconvenience of conspicuous security while actually leaving itself and its customers at risk because of misconfigured servers or flawed storefront software that builds vulnerability directly into its design.

The site that relies on user names and passwords, but that tries to reduce the inconvenience of these access control tools by packaging them in browser cookies, is authenticating the device, not the user—a conceptual flaw thats also common to the security protocols of, for example, Bluetooth wireless technology.

Business-to-business situations are even more likely to involve shared access terminals, increasing the need to find ways of controlling transaction privileges (such as allowable order amounts and approvals) by person rather than by connection.

Costs of biometric scanners are already falling, especially as voice hardware becomes part of mainstream convergence-driven systems, and growing bandwidth enables more transparent processing of fingerprint maps, face scans and the like. Businesses will benefit from the nonrepudiation of transactions that comes with means of authentication that are so closely tied to the individual user.

Another authentication option is the physical token, associated with the user rather than with the information appliance.

Portable tokens, attached to key chains or jewelry, let users move among many different client devices in a setting such as a large retail store or factory floor. Unlike biometric methods, they enable convenient transfer of authority as readily as handing someone a conventional key.

Better than mechanical keys, though, are electronic means of revoking authority quickly and with precision in the event of changed assignments or a departure from an organization. B2B system planners must think in the same circumspect terms as an engaged couple drawing up a prenuptial agreement, envisioning the possible need for withdrawing privileges as well as making it convenient to grant them. Key-distribution and management mechanisms, such as those commonly called public-key infrastructure, must be part of the plan.

The enemy within

Three generations of eWeek?s unique international OpenHack challenge events (story archives are at www.eweek.com) have highlighted three targets of attack: the platform, the applications and the technical staff of the site.

OpenHack I fell to an attack that induced the target site to betray itself by using a known but unpatched vulnerability of the cron daemon (which automates routine task scheduling) to give the attacker privileged access to the machine.

System administrators may be vexed by the frequency of software patches and by the distressing likelihood that a patch will create new problems while solving old ones. However, there is really no choice: Widely circulated patches, and their documentation, constitute a textbook of known attacks that all too often remain useful for years after their disclosure. Tracking and applying system patches can be daunting, but reputable sites such as CERT (www.cert.org) and the SANS Institute (www.sans.org) provide valuable assistance.

OpenHack II went down when a storefront application served as an entry point, accepting arbitrary commands through a pathway that was meant only to process file names. Both OpenHack I and OpenHack II showed the complexity of e-business systems and the high degree of mutual trust thats assumed among various components by PC-trained application developers.

When a storefront application was cracked in OpenHack II, for example, it became the stalking horse for an attack on the database of which that application was a trusted user. B2B application development managers may need to guide programming staff on the need to assume an arms-length relationship among system modules that might, at some future date, be operated by outsourced service providers or business alliance members.

OpenHack III began with a "trusted systems" foundation (perhaps better termed a "distrustful system") using Argus Systems Group Inc.s PitBull, with internal partitions that strictly limited system components privileges. Despite attackers success in finding loopholes such as those that brought down the previous OpenHack sites, the internal controls of the PitBull platform prevented attackers from linking those holes to tunnel through site security.

Failing to defeat site protection by technical means, at least one enterprising contender for the OpenHack cash prizes turned to social engineering, offering a simple bribe: Assist the attack, share the prize. Every e-business operator should bear in mind the growing likelihood of "purchased key" attacks as technical attacks become more difficult to carry out.

A Russian proverb, adopted by former President Ronald Reagan, says, "Trust, but verify." For e-customer confidence and B2B success, the dictum might better be: "Design, and you wont need trust."

 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel