A Quick Breakdown

That doesn't mean we can't try to break things down a little bit. For example, let's split the subject into some primary areas: anonymous users, authenticated users, external users, and internal users.

Anonymous Users

Anonymous users are those who access your corporate Web site or send you email. These people should have no access to anything other than the most public of information, and even that should be read-only. However, many e-commerce Web sites allow anonymous users to create and store information (via shopping carts, for example), asking for payment information via a secure transaction.

Typically, these users access a Web server with a public IP address that lives in your demilitarized zone (DMZ). While this can be your primary production server, more companies are moving their static Web presence to a DMZ machine as the price of a good, solid *nix or Wintel machine drops to $500 or so, thus removing the threat of denial of service (DOS) attacks on their production boxes. A DOS attack is pretty much the only attack that an anonymous user can make on any reasonably secured machine; they're crude but effective, so having your primary production machine out of the line of fire is always a plus. Other possible attack vectors for anonymous users include URL hacking and SQL injection. However, both of those techniques can be guarded against in application code; I'll address them later in this article.

Authenticated Users

Authenticated users are those who have a user ID and password that allow them to log in to and access one or more of your Web servers. This access can range from simply being able to see more static content to being able to run applications. While they can run applications, they have access only to that part of your network that is served by a Web server. This allows you to store pertinent information about the user on the server. For example, in many e-commerce applications, these users have "favorites" information (such as shipping addresses, credit card information, recent purchases) that can make the transaction quicker and easier for the user. While in the past authentication was often delegated to the HTTP server itself, companies are increasingly doing their own authentication in the application. This gives them more flexibility to allow users to register, log in, switch between authenticated and non-authenticated modes, share authentication among multiple machines, and so on.

External Users

External users are users who have access to all or part of your internal network through some sort of access protocol such as a VPN. This access can be through remote dial-in or, as is more and more prevalent, through the Internet. These users are in effect "on" your network and as such typically have a lot more access than a Web user as well as a lot more potential to cause damage.

These are the folks who are really challenging our current infrastructures. As companies increasingly find themselves having to integrate business processes with their partners in order to keep the workflow manageable and to stay profitable, this sort of access is becoming more pervasive. The use of VPNs is steadily increasing for everything from support to inter-company integration to outsourcing, although a couple of other technological trends may be reversing that somewhat. As more companies adopt service-oriented architecture (SOA) to expose their business processes, there may be less need for VPNs, because many SOA implementations provide access directly over the Internet without the need for the more-invasive VPN access.

Internal Users

Internal users are the folks working within your corporate walls who have physical access to the devices on your network. This category of user actually provides less of a challenge to standard security procedures than the external user because the IT department has better control over their devices. You can decide which software and hardware they can use and can even enforce the use of network-bootable devices or other threat-reduction techniques. As long as you have standard physical security for your servers, an internal user is simply an external user that you have more control over.

On a side note, while there is a complete industry centered on the use of biometrics and other similar security measures, I'm not focusing a lot of my attention on it for a couple of reasons. First, since biometrics can be accomplished only through physical access, you really only have control over your internal users; it's nearly impossible to force biometrics on business partners, and of course it's completely impractical today for anonymous or even authenticated users. Second, I'm still uncomfortable with the general concept of biometrics because any single biometric measure necessarily discriminates against some users. Fingerprint swipes can't be used by amputees, and similar problems exist for just about any other technique.

Some Primary Areas

I can't address all the areas of e-commerce security within the confines of an article. However, I can highlight a few issues and let you take a look at how each of them potentially affects your company.

Secured Web Application Access: HTTPS

This type of access is probably the most pervasive, and it's easiest area to implement. Web application servers either have an HTTP server built in or integrate with one, and nearly every HTTP server worth using today has support for secure HTTP protocol (HTTPS). The only requirement for HTTPS is a digital certificate, and digital certificates are easy to get. In fact, HTTPS is so standard that any business application today should implement it.

However, there is a bit of a hitch. You can choose from two basic varieties of HTTPS, depending on the type of digital certificate you use. One is a self-signed certificate that, while it provides a certain level of protection, has a number of security problems (not to mention that it looks rather unprofessional, since it causes most browsers to pop up a warning message). The other is a certificate assigned by a "trusted authority." The three major players are VeriSign, Thawte, and GeoTrust. There's a bit of monopolization; GeoTrust purchased Equifax's certification business and thus removed the $45 competition from its own $125 product. Still, it's better than VeriSign's $399 price tag, which is the result of being the biggest fish in the pond. For an added bit of power grabbing, VeriSign also owns Thawte. There's also CAcert, a volunteer organization that provides certificates for free.

Email Security

Junk email, or spam, is one of the most annoying aspects of today's Internet environment. And unless you plan to not have any email access whatsoever, you're going to have to deal with spam. The problem is that spam control can be a very costly proposition, potentially in terms of not only money but also lost productivity and even lost business.

But spam isn't the only problem; email is also a potential vector for virus infection. As virus engineers get more sophisticated, so too must the techniques to combat them. Some of these techniques are little more than common sense, although they can be truly annoying; for example, it is suggested that you do not use the preview pane feature in Microsoft Outlook, because simply opening certain emails can trigger a virus attack.

Email filtering can range from open-source solutions like SpamAssassin to powerful standalone email filtering appliances like those from Barracuda. Prices range accordingly from zero (plus your time) to $10,000 or more. But more than just the issue of the price is the concept of "false positives." As long as email does not require authentication (an issue we won't go into here), there will be the problem of trying to identify spam. Since any technique short of IP verification will require somehow scanning the content and "guessing" whether it is spam (usually by applying some set of rules), then there exists the chance of getting a false positive, which means that a benign email gets quarantined mistakenly, causing you to miss a real email from a coworker (or worse yet, a potential customer!).

Web Application Design

Having secured Web access doesn't guarantee you a secure site. Application design plays a key role in how secure your site is. For example, it's very easy to throw together a simple site that uses SQL to access your database. However, without proper safeguards, such sites are almost laughably easy to penetrate. There are known (you could almost call them "standard") techniques that can be used to cause a perfectly ordinary application to execute code it was never intended to execute. Such "SQL injection" techniques can easily be guarded against, but you have to know about them ahead of time and design your application accordingly.

Another commonly used door is the technique of URL hacking. It's easy to design applications that use the HTTP GET method to access applications; in such methods, the URL contains data that identifies the user and where they are in the application. If this data is not somehow obfuscated, it is child's play for an unscrupulous user to change the URL and access data they shouldn't otherwise. For example, take the following URL:

http://www.mycompany.com/SalesInquiry?salesman=100

It's not too hard to imagine that someone might simply change the salesman number in order to see someone else's sales information. It's crucial that you design your applications defensively in order to avoid this sort of exploitation. An even easier URL hacking technique is to simply remove parts of the URL and see what lies underneath. For example, what would http://www.mycompany.com/admin give me access to? If the HTTP server isn't set up with the proper authority scheme, this might let someone into vulnerable parts of the system.

While designing Web application security typically doesn't have a direct measurable cost, I guarantee you that the costs of not having such safeguards in place can definitely be measured.

VPN Appliances

At one of the farthest ends of the spectrum is the VPN appliance, which is a hardware solution to allow outside users to connect to your network. Vendors like SonicWALL provide solutions that range in price from hundreds to thousands of dollars.

There are many options. You can configure access appliances and send them to your external users, or you can set up pure SSL connectivity servers that require no client-side software or hardware. However you configure the connection, your external users end up looking like they are part of your network.

Note that hardware is not necessarily required for VPN access. Microsoft provides VPN software with Windows (although I have never gotten it to work correctly), and there are even open-source solutions such as iPIG that can be installed on your network to allow you to connect in remotely over the Internet.

The ASP Alternative

This ever-growing complexity of security may be one of the driving forces behind the recent focus on application service providers (ASPs). An ASP owns the hardware, maintains the software, and houses the corporate data for its client, who accesses the applications through an external interface (typically a browser in these Internet days). Those of us with a little time under our belts recognize this as the old service bureau model, which was perhaps one of the most important and lucrative markets for the IBM midrange, dating back to the System/3.

The ASP is typically able to provide superior security and response time—especially to the small-to-medium business (SMB) customer—by being able to leverage those overhead costs I outlined earlier over a large number of smaller customers. By consolidating multiple customers into a single VPN appliance, the ASP provides industrial-strength quality for open-source prices.

Of course, there's still the question of whether or not you want to allow any company to hold your secure corporate data. Whether it is an issue of potential downtime or one of security, you need to have great faith in your ASP to entrust it with an asset that valuable. And a bigger company isn't necessarily better, either; bigger companies have more employees and more customers and more hardware and more software and thus more places where things can go wrong. SAP is trying to get into the ASP game, as is Microsoft. Are you really willing to entrust your livelihood to a company with a long history of security breaches? This is a difficult question.

No Easy Answer

No matter how you plan to approach security, whether it's in-house with your own IT staff and your own network or through an ASP, you need to carefully consider the ramifications of your decisions. Open-source solutions abound, but the initial savings can easily be offset by the amount of time spent supporting the solution. Make your security too restrictive and you risk losing business or productivity; too lax and you risk infection and theft. There is no single solution best for every company. The only thing that is certain is that security issues will continue to grow more complex, not less.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. He speaks at local user groups and technical conferences around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..