Security Strategies

In general, we make our systems more secure by

• Limiting access to the system by means of firewalls, passwords, and so on
• Understanding the system and security requirements
• Keeping up to date on the latest patches and security alerts

Of course, the easiest way to limit access to a system is to disconnect it from any public network, such as the Internet, and physically secure all the points where the network meets the real world. This type of security measure might be fine and appropriate for military systems, but for Internet e-commerce systems, it wouldn't do much to help business.

Another option to limit access to intranet-based Web applications is to establish a firewall between the intranet and the Internet. Most companies maintain a firewall to insulate their internal systems from the external world; they are relatively easy to install and maintain. Firewalls, however, are no guarantee that an intruder or a disgruntled employee won't gain access.

Firewalls get their name from the steel wall between the driver's compartment of an automobile and the engine compartment. The idea is that a fire in the engine will have a difficult time spreading to the rest of the automobile. A network firewall is designed to prevent unwanted traffic from going into or out of an internal network (Figure 5-9). Typically, firewalls use a proxy server to monitor ingoing and outgoing traffic. Traffic can be limited a number of ways: by typeHTTP, FTP, or e-mailor by addresswww.waste-employee-time.com, and so onas well as by others.

Figure 5-9. Firewall placement

Perhaps the most important precaution you can take to protect your system is to have a realistic password policy. This policy should include training system users about the basic security risks and emphasizing the seriousness of keeping passwords private. All too often, passwords are shared and exchanged over the phone. The password policy must take into consideration the relative security risks and consequences with the personal considerations of the user. For example, 30-character passwords with nondictionary words and updated every two weeks are certainly more secure than 8-character passwords left completely up to the users' discretion and that never expire, although 30-character passwords are often difficult to remember, especially for infrequent users. The password requirement can be configured to require at least one numeric character and periodic changes and to prevent the reuse of passwords.

In addition to complex password requirements, workers today are continually being requested to remember more and more unique passwords for various systems. I have to remember passwords for half a dozen Internet sites, my company network account, the HR intranet application of my employer, and several e-mail accounts that I continue to use. Even though it is insecure, I have little choice but to duplicate passwords or variants across systems just so that I can remember them. This is practical reality, and any password policy needs to consider this.

An additional option to authenticate a user can be done with personal certificates. Just as with code signing, individual users of a system can be required to authenticate themselves with a digitally signed certificate. Personal certificates, which can be obtained from the major CAs for a small fee, are of two levels. At one level, the certificate verifies only that the person claiming to be a specific user name has applied and paid for a certificate. The other, more expensive level verifies that the CA has checked into the identity of the applicant and has verifiedusually via a government agencythat the person is who he or she claims to be.

Instead of relying on public certificate authorities, large organizations can distribute their own certificates to users of their system. These certificates, however, imply an existing trust relationship between the user and the company acting as its own CA. Distributing your own certificates is a cost-effective way to authenticate users of intranet systems.

Encryption

Certificates and code signing rely on digital cryptology. This same technology can be used to help secure the underlying network traffic in a Web application. Because many Web applications use the public Internet to connect clients and servers, crackers can monitor and decode network traffic and, with some effort, determine access patterns and confidential information, such as passwords and credit card numbers.

To make client and server network traffic more secure, it can be encrypted. The push to e-commerce has prompted the emergence of several schemes to protect confidential information over the network. The two most promising are Secure Sockets Layer (SSL) and Secure Electronic Transaction (SET).

SSL was introduced by Netscape Communications Corporation and is a low-level encryption scheme used to encrypt higher-level protocols, such as HTTP and FTP. SSL requires that the server present a certificate from a CA to verify its identity and can, optionally, verify a client certificate as well. SSL is implemented on most of today's browsers, and nearly all e-commerce applications use it to provide a measure of security for their users.

SET, a relatively new scheme to process credit card orders over the Internet, is being proposed by Microsoft, Netscape, Visa, and Mastercard. SET uses a complex system of CAs to verify the identities of everyone involved in the transaction: the customer, the merchant, the card issuer, and the merchant's bank. The key benefit of SET over other schemes is that it goes to great lengths to protect the identities and information in the transaction from those who don't need it. For example, the merchant doesn't have access to the type of payment the customer is presenting, only the item, cost, and approval of payment. Also, the card issuer has access only to the purchase price, not to the item purchased. This level of security protects the customer from being placed on specialized marketing lists, based on purchasing preferences.

Encryption technology today is based principally on the concept of public/private key pairs. A message is encoded by using a public key, which can be obtained by anyone from a CA or is usually distributed by the person who owns the key pair. Once the message is encoded, the only way to decode it is with the special private key. Not even the original public key can be used to decode the message, thereby keeping it safe. The only way the message can be decoded is with the matching private key, which the owner should guard jealously (Figure 5-10).

Figure 5-10. Public/private key encryption

The one disadvantage of public key technology is that the key is usually a long and cryptic code that can't be memorized by an individual. Therefore, keys are managed by copying and moving key files. So, just as with physical keys, a private key can be stolen or copied, and its protection is only as good as the protection of your physical machine. For example, anyone who can gain access to my personal computer will be able to decode encrypted messages sent to me at that machine.

Best Practices

Relying on technology alone is no way to ensure the security of your application. Making a secure application requires constant attention and awareness throughout the process of developing and maintaining the application. One of the first things that should be done when building a Web application is to create a written security policy. The mere fact that a policy is written down will help keep everyone involved aware of the issue.

A security policy should include at least the following:

• Who is allowed access to the system
• When they are allowed access
• What they are allowed to do with the system
• How users get added to the system and how they get removed
• System-monitoring procedures: types of logs and frequency of review

As with any policy manual, a security policy needs to be simple and easy to read. The policy manual should be read by every member of the development team and the users of the system. The purpose of the manual is to give everyone a better understanding of the issues related to the security of the system.

When configuring a Web application system, it is always a good idea to make the server as lean as possible. This will typically increase execution speed, but the fewer unused modules and features installed on the server, the fewer potential software bugs and security holes there will be. For example, if the application doesn't use CGI, turn it off. If directory browsing is not part of the designed application, turn it off.

Proper management of user accounts on a Web application server is also very important. As a general rule, I create a number of accounts or groups for particular roles in the development and maintenance process. The privileges for each account need to be carefully examined to ensure that they are sufficient to complete the user's tasks, and no more than that.

During the development process it is also useful to create a security view in the architecture model. A security view would contain such elements as users, policies, authentication, and so on. As with any other model in the system, a security model abstracts part of the system into something more easily understood. For a typical e-commerce application, the model will contain entities for customers, account managers, certificate authorities, policies, and so on.

Keeping a system secure goes beyond its design. System administrators need to be ever vigilant and actively monitor the popular security forums on the Web and Usenet newsgroups. The most up-to-date information about security holes and software bugs that might affect your system can be found on the Internet.