E-Commerce Access Module

E-commerce security is a bit of an oxymoron. The primary objective of e-commerce is to allow customers to access your online facilities to do business. At the same time, one of the primary objectives of network security is to keep people out of the network and systems. Building an e-commerce module requires that you strike a balance between access and security. While this section focuses on how to build an infrastructure to support a secure e-commerce implementation, you cannot overlook the requirement of having the application developers design the applications to support such an infrastructure. If they do not, you simply cannot use this design.

The e-commerce access module is built on a three-tier model. At the first tier are the web servers that function as the front end for the e-commerce applications and are accessible to the end users over the Internet. The middle tier represents the middleware applications that process the requests from the first tier and request data from the third tier. The third tier represents the data itself, typically housed in database servers. Figure 11-11 illustrates the e-commerce access module design.

Figure 11-11: E-commerce access module

In this system, three DMZs are designed primarily to control and regulate what data can pass from one tier to the next .

Web Services DMZ Segment

The web services DMZ segment is the only segment that is accessible from the Internet. The firewall on the external perimeter should be configured with ingress filtering that allows traffic from the Internet to the web services DMZ segment only. The DMZ services segment interface should be configured with egress filtering that allows no traffic to the Internet and ingress filtering that allows only the required traffic to the application services DMZ segment that is required by the e-commerce application. The interface on the application services DMZ segment should be configured with egress filtering that blocks all traffic in the direction of the Internet or, if required, permits traffic only from the servers in the application services DMZ segment to servers in the web services DMZ segment.

NIDS/NIPS and HIDS/HIPS should be deployed on this segment and on the servers themselves to monitor and analyze the traffic traversing this segment and to detect operating system “level tampering.

Application Services DMZ Segment

The application services DMZ segment is designed to allow traffic in two directions. First, traffic from the web services is allowed to access the servers on the application services DMZ segment only as previously detailed. Second, the firewall on the interior perimeter is configured with ingress filtering that allows only e-commerce “ related traffic from the application servers to the database servers on the databases services DMZ segment.

NIDS/NIPS and HIDS/HIPS should be deployed on this segment and on the servers themselves to monitor and analyze the traffic traversing this segment and to detect operating system “level tampering.

Database Services DMZ Segment

The database services DMZ segment is the final tier in the e-commerce access module and is the most protected of all the segments, because this is where the actual data resides. The firewall interface on this segment should be configured with egress filtering that blocks all traffic in the direction of the Internet or, if required, permits traffic only from the servers in the database services DMZ segment to the servers in the application services DMZ segment. The firewall interface should also be configured with ingress filtering that blocks all traffic to the internal network, with the exception of any traffic required for the e-commerce application.

NIDS/NIPS and HIDS/HIPS should be deployed on this segment and on the servers themselves to monitor and analyze the traffic traversing this segment and to detect operating system “level tampering.

If implemented properly, your e-commerce access module creates the traffic flow shown in Figure 11-12.

Figure 11-12: E-commerce traffic flow

Traffic can flow from the Internet to the web servers, and only to the web servers. The firewall blocks all other inbound traffic from the Internet. Traffic can flow from the web servers to the application servers, but the first firewall blocks it from flowing anywhere else. In this sense, the web servers are functioning as proxies on behalf of the user . Traffic from the application servers can flow to the database servers, but the second firewall blocks it from flowing anywhere else. In this sense, the application servers are functioning as proxies on behalf of the web servers. Finally, traffic from the database servers can flow nowhere. The database servers are either responding to requests from the application servers (dynamically permitted due to stateful packet inspection) or they don t communicate. This ensures that external users must breach at least two levels of security before gaining access to any data, and with luck your IDS/IPS deployment will have triggered an alarm on the suspicious activity long before that happens.