Your Network's Not Ready for E-Commerce

 Article by Brian Walsh the founder of bwalsh.com, a Portland, Ore., consulting firm specializing in Internet and client/server product strategies, development and testing. 
Unlike generic brochure sites, e-commerce is not indeterminate concerning security. The inability to route application requests securely--because of the lack of internal firewalls or the existence of VPNs (virtual private networks)--is the big problem and it's not going away quickly. Unfortunately, the network security group feels that the application need doesn't exist or is, at worst, transient. Moreover, the development group is totally oblivious to security. But together, these groups must solve the security infrastructure problem simply because no company will take its sensitive business information and systems and put them all online.

Back to the Future If you scan the technical employment ads, it may seem that client/server is no longer in the spotlight, but e-commerce may well revive the term. At heart, e-commerce is a Web-based transaction system. Hopefully, we can also make it a secure, scalable transaction system. We must use the now-traditional view of client/server--with presentation processing on the front end in the browser, some business processing in the middle and some legacy, large-volume or package (Baan, Oracle, PeopleSoft, SAP) back-end data access in the last tier--to analyze the flows that comprise e-commerce and extranet connections. These are the requirements the security architecture can implement, check and enforce. Once in place, they form the guidelines for changes, auditing and certification.

For example, you can reduce e-commerce to simple parts: There's a browser on the front end. A Web server takes a request and throws it over the firewall to an enterprise object server, which in turn encapsulates the logic and access to your back-end systems. But reality is not so simple. First, there is no standard application server. Furthermore, once you open that Pandora's box of application data flows you'll find that the data is scattered all over your organization.

Too many Web applications are developed in isolation, appear without an architecture and then are dumped onto the network/security group screaming, "Support me now!" Securing the broad range of applications that make up e-commerce is like securing a house that has paper walls--unless the implementers conform to an architecture and the security team implements a solution to that architecture. The alternative is to argue about, fund and secure each and every application independently. The n-tier client/server architecture is especially useful when thinking about e-commerce security and data access.

Security management is a balancing act between risk and reward, access and return. The better the balance, the greater the benefit for the entire organization. However, e-commerce is probably the first application that really puts pressure on your internal security. In terms of internal financing, let's just say it's unfair if the first passenger pays for the whole bus while everyone else rides for free. If you're serious about e-commerce, you must lay the groundwork for examining security from behind the firewall.

By looking at security this way, you elevate all the network segments to a series of DMZs. As I have suggested, security doesn't end with firewalls; it includes architecture, encryption, authentication, firewall access control (firewall filters), content security (malicious applets, fraudulent URLs and garden-variety viruses), traffic grooming, fraud protection (it's not the same as security) and application security.

Back to Reality Given the e-commerce project described at the start of this column, it's smarter for the project manager to ask, "What needs to be done before we can start e-commerce?" rather than wait for security to protest that the door has been opened and we've thrown away the key. Experience has shown that evaluating security behind the firewall and implementing required solutions is a project in its own right, and is of the same order of magnitude as the e-commerce implementation itself.

This may sound as if revamping security infrastructure is a job for high-priced consultants. Indeed, many hackers now have suits representing them (or the suits have found ways to profit from security concerns). You can expect to pay upwards of $200 per hour for a project that will take one person and a month to complete--at a minimum. But it will be money well-spent. A consultant should detail the extent of your exposure and recommend steps for resolving network and host security.

However, though you will walk away from this type of engagement with marching orders for network and host security, you won't procure specifics on fraud and application security. While there is a huge archive of material and experience dedicated to the intellectual game of intrusion, detection and response, intrusion in and of itself never costs money; the fact is, money changes hands only after you've been defrauded.

The literature and skill on how to recognize and adapt application-level deficiencies that expose you to fraud are few and far between. Likewise, as your enterprise applications are incorporated into e-commerce, your developers must acquire the skills necessary to create secure applications. Unfortunately, most advice in this area is trivial, such as, "credit cards are like passwords, don't store them in the clear."

Successful organizations will not limit their efforts to network and host security. Rather, they will pursue parallel tracks of networkwide security and deter fraud by changing the development practices that create application-level vulnerabilities.

Brian Walsh is the founder of bwalsh.com, a Portland, Ore., consulting firm specializing in Internet and client/server product strategies, development and testing. Send your comments on this column to him at brian@bwalsh.com.  

Note from CTI --- This is a great article in our opinion.  Further comments to follow...