Despite the existence of hackers and crackers, e-Commerce remains a safe and secure activity. The resources available to large companies involved in e-Commerce are enormous. These companies will pursue every legal route to protect their customers. Figure 6 shows a high-level illustration of defenses available against attacks.
Figure 6. Attacks and their defenses
At the end of the day, your system is only as secure as the people who use it. Education is the best way to ensure that your customers take appropriate precautions:
- Install personal firewalls for the client machines.
- Store confidential information in encrypted form.
- Encrypt the stream using the Secure Socket Layer (SSL) protocol to protect information flowing between the client and the e-Commerce Web site.
- Use appropriate password policies, firewalls, and routine external security audits.
- Use threat model analysis, strict development policies, and external security audits to protect ISV software running the Web site.
Your system is only as secure as the people who use it. If a shopper chooses a weak password, or does not keep their password confidential, then an attacker can pose as that user. This is significant if the compromised password belongs to an administrator of the system. In this case, there is likely physical security involved because the administrator client may not be exposed outside the firewall. Users need to use good judgement when giving out information, and be educated about possible phishing schemes and other social engineering attacks.
When connecting your computer to a network, it becomes vulnerable to attack. A personal firewall helps protect your computer by limiting the types of traffic initiated by and directed to your computer. The intruder can also scan the hard drive to detect any stored passwords.
Secure Socket Layer (SSL) is a protocol that encrypts data between the shopper's computer and the site's server. When an SSL-protected page is requested, the browser identifies the server as a trusted entity and initiates a handshake to pass encryption key information back and forth. Now, on subsequent requests to the server, the information flowing back and forth is encrypted so that a hacker sniffing the network cannot read the contents.
The SSL certificate is issued to the server by a certificate authority authorized by the government. When a request is made from the shopper's browser to the site's server using https://..., the shopper's browser checks if this site has a certificate it can recognize. If the site is not recognized by a trusted certificate authority, then the browser issues a warning as shown in Figure 7.
Figure 7. Warning to user
As an end-user, you can determine if you are in SSL by checking your browser. For example, in Mozilla® Firefox, the secure icon is at the top in the URL entry field as shown in Figure 8.
Figure 8. Secure icon in Mozilla Firefox
In Microsoft® Internet Explorer, the secure icon is at the bottom right of the browser as shown in Figure 9.
Figure 9. Secure icon in Microsoft Internet
A firewall is like the moat surrounding a castle. It ensures that requests can only enter the system from specified ports, and in some cases, ensures that all accesses are only from certain physical machines.
A common technique is to setup a demilitarized zone (DMZ) using two firewalls. The outer firewall has ports open that allow ingoing and outgoing HTTP requests. This allows the client browser to communicate with the server. A second firewall sits behind the e-Commerce servers. This firewall is heavily fortified, and only requests from trusted servers on specific ports are allowed through. Both firewalls use intrusion detection software to detect any unauthorized access attempts.
Another common technique used in conjunction with a DMZ is a honey pot server. A honey pot is a resource (for example, a fake payment server) placed in the DMZ to fool the hacker into thinking he has penetrated the inner wall. These servers are closely monitored, and any access by an attacker is detected.
Figure 10. Firewalls and honey pots
Ensure that password policies are enforced for shoppers and internal users. A sample password policy, defined as part of the Federal Information Processing Standard (FIPS), is shown in the table below.
| Policy | Value |
| Account lockout threshold | 6 attempts |
| Consecutive unsuccessful login delay | 10 seconds |
| Matching user ID and password | N (no, they cannot match) |
| Maximum occurrence of consecutive characters | 3 characters |
| Maximum instances of any character | 4 instances |
| Maximum lifetime of passwords | 180 days |
| Minimum number of alphabetic characters | 1 alphabetic character |
| Minimum number of numeric characters | 1 numeric character |
| Minimum length of password | 6 characters |
| Reuse user's previous password | N (no, cannot be reused) |
You may choose to have different policies for shoppers versus your internal users. For example, you may choose to lockout an administrator after 3 failed login attempts instead of 6. These password policies protect against attacks that attempt to guess the user's password. They ensure that passwords are sufficiently strong enough so that they cannot be easily guessed. The account lockout capability ensures that an automated scheme cannot make more than a few guesses before the account is locked.
Intrusion detection and audits of security logs
One of the cornerstones of an effective security strategy is to prevent attacks and to detect potential attackers. This helps understand the nature of the system's traffic, or as a starting point for litigation against the attackers.
Suppose that you have implemented a password policy, such as the FIPS policy described in the section above. If a shopper makes 6 failed logon attempts, then his account is locked out. In this scenario, the company sends an email to the customer, informing them that his account is locked. This event should also be logged in the system, either by sending an email to the administrator, writing the event to a security log, or both.
You should also log any attempted unauthorized access to the system. If a user logs on, and attempts to access resources that he is not entitled to see, or performs actions that he is not entitled to perform, then this indicates the account has been co-opted and should be locked out. Analysis of the security logs can detect patterns of suspicious behavior, allowing the administrator to take action.
In addition to security logs, use business auditing to monitor activities such as payment processing. You can monitor and review these logs to detect patterns of inappropriate interaction at the business process level.
The infrastructure for business auditing and security logging is complex, and most likely will come as part of any middleware platform selected to host your site. WebSphere Commerce, for example, has extensive capabilities in this area.
No comments:
Post a Comment