The lies we tell others are bad, but it's the lies we tell ourselves that really get us into trouble. The reality is that security is hopelessly lacking on internal segments behind the firewall, which could cause our project manager's figures to grow by half, or even double, by the time the project is completed.

Introducing e-commerce to an organization exposes quite a few of these little lies. You've heard them: "Our firewall protects us from the Internet." "Since the Web server is in the DMZ (demilitarized zone), we don't have to worry about it." "Our internal systems are secure." "We don't have anything worth hacking." "Security is a network problem." And my favorite, "Our production systems are flexible because they're based on standards." What a panic! It actually would be funny if not for the time and money involved.

These lies contribute to the security rationalization concerning network deployment behind the firewall. The architecture of internal segments is driven by several factors: historical accident (we needed it, we added it), performance (based on user complaints, we moved the servers to their own segment) and/or reliability (someone will get fired if there's a problem with this application, so we'll buy two of everything). Rarely has security been the driving factor in the tactics of network architecture and, consequently, the firewall is often the only secure part of your network. E-commerce just happens to be the first application to demand the same degree of security behind the firewall as is traditionally applied to the DMZ.

Making Myths Web server host security is enough for e-commerce, right? Wrong. Although Web application folks and project managers often believe this myth, the truth is that no matter what security scheme you've employed to protect your Web content, it won't be good enough for e-commerce. However, those of us in the networking space must also shoulder some blame. See, the project manager remembered what you said in passing last year, "Our Web server is secure." And, of course, the project manager then assumed that your statement applied to any Internet application. You then supported that implication by not explicitly stating, "But our internal systems A through Z are not secured."

Essentially, the problem is that the e-commerce initiative everyone in IT is so jazzed about will touch practically every application and database in your shop. Gone is the luxury of defending only a single segment. That innocent Web server will start opening sessions to servers on all of your production segments. Take heed: Do not respond to this challenge by questioning, "Well, can't we just duplicate all that data onto servers on the DMZ?"

Until now, your firewall has served as "a hard crunchy shell around a soft chewy center." (Thank you Bill Cheswick, Bell Labs, Lucent Technologies, for the imagery.) I know, I know--administrators look after all the servers, and you've distributed a security policy to all your personnel. However, if the thought of a server on your DMZ opening a session with a server on an interior segment fills you with dread (because once hackers have access to the production segment they can traverse all segments at will), how do you define usable, flexible security? E-commerce is more than just selling online; it gives your customers and partners access to some of your core data and applications.