MERCHANT AT RISK
In part of 1 this article, risk management was covered, outlining some of the threats and the need for a risk management plan.
This installment reviews the security requirements being mandated by the financial acquiring networks. They include VisaNet International, American Express, Nova, and Wells Fargo over which credit card transactions are settled. The requirements were announced last year, are similar across all networks, and affect every merchant taking credit cards through an on-line store.
The mandated requirements are known collectively as CISP (Cardholder Information Security Policy) and should have been implemented by merchants and processing providers as of May of 2001. These are administrative, not legal, requirements and aren’t necessarily enforced across the board, that is, until something goes wrong. So it is essential to make an effort to implement these requirements wherever possible. Otherwise, your merchant account could be in jeopardy.
The mandates apply to any merchant taking credit cards no matter if they host their own storefront or rely on a processing provider. If you are a merchant using a provider, make sure the provider complies with CISP requirements because you as the merchant are the responsible party.
CISP MANDATES
1) Establish a company privacy policy statement that discloses how cardholder payment data is being stored and used.
2) Install and maintain a working network firewall to protect credit-card data accessible via the Internet.
3) Keep security patches up to date.
4) Encrypt stored data accessible from the Internet.
5) Encrypt data sent across public networks.
6) Use and regularly update anti-virus software.
7) Restrict access to data on a “need-to-know” basis.
8) Assign a unique ID to each person with computer access to data.
9) Do not use vendor-supplied defaults for system passwords and other security parameters.
10) Track access to data by unique ID.
11) Test security systems and processes daily.
12) Maintain a policy that addresses information security for employees and contractors.
13) Restrict physical access to cardholder information. Give an individual or team specific responsibility for managing information security.
14) Limit storage of CID (Cardholder Identification) or other rightful owner verification information.
15) Notify the acquiring processor of security breaches.
16) Capture the remote host IP address.
17) Restrict customer access to payment forms by time and sessions.
WHAT YOU NEED TO DO
Looking at the list above:
Item 1, privacy statement: A cardholder privacy/security statement should be placed in a prominent location in your web site. A good location might be from link to a small pop up window that loads the statement. According to an Information Resources study earlier in 2001, 63% of consumers polled said they want to find security statements on sites. Remember, there is no privacy if you don’t provide security.
Items 2 and 3, network protection Network security is a major topic that will not be addressed here; however, you should ask your provider or IT staff about the network security tools in place, including network layers, routers, firewalls, and IDS (Intrusion Detection Systems).
Item 4, encrypt stored data Interpret this requirement to include vital credit card information stored in any database that is ultimately accessible to the Internet even though the database file itself may reside in a location accessible only from a trusted server. The encryption requirement is 3DES called triple DES, standing for Data Encryption Standard, first introduced in the ’70s and subsequently modified. Triple means that the data is twice redundantly encrypted making it virtually impossible for ordinary hackers to afford the resources to crack the code.
To comply with this requirement, if you’re storing credit card numbers and possibly addresses, you’re going to have to add a module within your database entry script that does the encryption prior to entry. Alternately, if supported in the database itself, you could encrypt all entries. This, however, can result in an extremely bloated database file.
Fortunately there are available some free 3DES encryption modules so you won’t have to start from scratch. There is a custom ColdFusion tag for doing 3DES encryption as well as a Java module. A little searching should turn up a Windows COM object as well.
Item 5, data sent across public networks The standard protocol for transferring information over the Internet is TCP/IP using ascii text to format information. This makes information, while in transit on the Internet, human readable by any party with a computer that can intercept the information.
The security being mandated by the acquiring networks is 128 bit SSL 3.0 (Secure Socket Layer) encryption. This is an encryption method used when your browser talks to a server and when the server talks back to the browser. Implementation is standard in all current browsers, but requires you to purchase a certificate for the server. You may in some instances recognize that SSL is in use by the little lock that shows up in a browser or the “https://” protocol in the browser address bar. In a frames enabled site this will not be so evident.
Item 6, anti virus software Just do it on your own machine! It makes sense with or without transaction processing. Make sure your hosting provider runs anti virus software as well.
Items 7, 8, 12, 13: “need to know” and restricted access These requirements were covered in the previous installment of this article under policy. They cost nothing to implement and serve as your best first line of defense. Don’t forget to password protect databases.
Item 9, default settings This is mostly under the purview of your host provider and their network security staff. Ask them what their policy is. We’re sure it’s more than you ever imagined.
Item 10, track access by unique ID Again this is a policy function, but may require a certain amount of technology to implement. What is being required is recording to a file the time, the information requested, and the ID number of the employee making the request. You’re going to have to check with your hosting provider for help with this, if it’s to be done automatically.
Item 11. test security daily Be aware and be informed. Your designated security manager must be up to date on new risks and the steps needed to make adjustments. If risks concern your remote hosting provider, don’t assume that they are as current on credit card processing issues as you are. Give them a call to be sure.
Items 12 and 13, policy and physical access Policies and physical access restrictions should be a part of your risk management plan.
Item 14, limit storage Introduced by American Express and as CID (Cardholder Identification), CVV2 for Visa, and CVVC for MasterCard this is a card specific rightful owner authentication means. CID values can only be stored for up to 10 minutes and only to facilitate the original authorization transaction. This restriction includes storage in the cache memory on the server. Make sure you flush session information once the order and card authorization is complete. This is just good programming practice anyway, but required if you want to use the SID system for authentication.
Item 15, notification The merchant is required to notify the acquiring processor anytime payment data has been or may have been compromised. Notification requirements may vary, but should be made within 5 days of a breach. In some cases, a failure to make timely notification could result in the merchant being liable to the acquiring processor for the full amount of fraudulent transactions conducted using that processors cards.
Item 16, capture remote host Capturing the remote host IP address of your customer is a requirement with some acquiring networks and is generally a good idea. The IP address is available through the CGI parameter, “cgi.REMOTE_HOST”. This value should be captured and stored with the order and credit card transaction information. The IP address may not provide for specific customer identification since most ISPs (Internet Service Providers) use a floating IP number network system. However, orders comming from the same IP address over a relatively short time span are probably comming from the same user. In cases of fraud, the ISP, given the IP number and time of the transaction, may have a legal requirement to disclose log information which can point to the specific client.
Item 17, restrict access Hackers as well as legitimate customers have access to credit card payment forms. It is necessary to time out customer sessions and to prevent multiple form submits within the same session. Maintaining information integrity when using forms is very important for the merchant since it is the public avenue through which a mischievous user can gain access to your system.
CONCLUSIONS
If you didn’t begin early on to address the CISP mandates, then you have a formidable task ahead. First though, create a risk management policy and put someone in charge. Implementing CISP in its entirety will take time; however, it is important in the event of a security breach to show your acquiring network that you are making the effort to comply. Remember, as a merchant, you are the responsible party.
COMMING UP
The third installment of this article will cover in some detail Web site forms and site operation where risks can be high, but easily reduced through design practices.
Mel Davey is the creator of ImagineNation (http://imaginenation.com/), a full service E-Commerce Application Service Provider, offering Storefronts, Order Management Utilities, and 3rd party credit card processing.
