Introduction

The following best practices should be considered when designing a security policy for network and web application.

Passwords

Best Practices

Good passwords use both letters and numbers. They are at least 6 characters in length and should be changed regularly. Information systems should be designed to force users to meet these simple requirements in their passwords.

Storing and verifing

Storing and verifying passwords should be done in a secure manner. Best password practice is to store passwords encrypted through a one-way hash. This prevents the passwords from every being decrypted. When a user attempts to authenticate with the system, the password they enter is encrypted in the same fashion, and these two encrypted password are compared to verify authentication.

Credit Cards

Receiving Information

When receiving credit card or other payment information through your website there are a number of steps you should take in securing this data. All communications should be done through SSL. Giving users an option to not use SSL is not recomended.

HTML forms that collect data should always "post" the data. When the "get" method is used the credit card number is included in the URL requested. This URL will be logged by any proxies and most likely by your web server. The credit card data is then in plain view to anyone who accesses these log files.

Log Files

It's important to make sure that your log files don't contain any critical information. Never print or save debug statements that included credit card numbers or passwords.

Storing Information

Storing credit card data is never recommended. The most common alternative to storing credit card data on your own systems is to store the credit card data in your processors system. Most credit card processors (CyberSource, VeriSign, Authorize.net) have features that let you store the credit cards in their systems and tell them when a recurring or one time charge should take place.

Most credit cards now contain an additional pin number, sometimes referred to as the CID or VVS number. This number can never be stored on your server in any data format. It is strictly prohibited by all credit card vendors.

If you've explored the alternatives to credit card storage, and determined that you still have to store the data locally, you need to do so in a secure manner. All data should be encrypted while stored or transported. The method or key used for decryption should be well guarded.

Cookies

Best Practices

Cookies are commonly used to track visitor information. Cookies should never contain any confidential or payment information because the are often logged by proxies and web servers.

Session IDs

Cookies are often used to keep track of user sessions. When you do so, the session ID included in the cookies need to be random and long enough to be difficult to brute force. A good session ID will be a random mix of upper and lower case letters and numbers at least 8 characters long. Dangerous session IDs are those that a predictable, such as an incrementing integer.

Network Scanning

At a minimum, conduct quarterly scans of all devices in the Demilitarized Zone (DMZ).

Quarterly or weekly scans will ensure that most threats and vulnerabilities are uncovered. Of course, to be completely up-to-date, daily scanning is highly recommended. The DMZ is the "neutral zone" of the network. This is the network area between the company's internal network and the outside public network: the Internet. Although devices in the DMZ should be only accessible through a firewall, hackers typically target vulnerabilities on these devices to gain further access to devices within the company's private network - beyond the DMZ.

Scan all "filtering" devices such as Firewalls or External Routers (if used to filter traffic).

Assuming that a firewall or router is used to establish a DMZ, these devices should be scanned for vulnerabilities.

Scan all web servers.

Web servers and Web applications allow Internet users to view web pages and interact with databases. Since these servers are fully accessible from the public Internet, and are the most common target for hackers, it is critical that they are scanned for vulnerabilities. Operations with multiple Web servers should scan each server individually if they have public IP addresses.

Scan web application servers if present.

Application servers act as the interface or "middle-man" between the web server and the back-end databases and legacy systems. For example, when cardholders share account numbers with merchants, the application server provides the functionality to transport data in-and-out of the secured network. Hackers will exploit vulnerabilities in these servers and their scripts to get access to internal databases that could potentially house credit card data. Some web sites are not configured with application servers. Instead the web server itself is configured to act in an application server capacity. Application servers, when properly configured, can provide an extra layer of security.

DNS servers.

DNS servers resolve Internet addresses by translating domain names into IP addresses. Merchants may utilize their own DNS servers, or may use a DNS service provided by their ISP. If DNS servers are vulnerable, hackers can potentially spoof a merchant's web page and collect credit card information from unknowing cardholders on their own server. If merchants operate their own DNS servers, scanning is required to be compliant with the SDP and AMEX CID programs.

Mail servers

Although mail servers may exist in the DMZ and can be vulnerable to hacker attacks, they do not normally give access to databases that can result in credit card fraud, but hackers can use them as a "stepping stone" to attack other servers that contain sensitive information. To maintain overall Web site security however, they are a critical element that must also be protected by regular scanning.