02.18.04
 By
Mel Davey
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.
About the Author:
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.
| | From the Forum: | | Paypal | My website uses the Paypal shopping cart for retail - it's going ok but I wonder if customers are put off with having to register with Paypal first?? I've recently heard a few bad reports of Paypal but when I did a web search all the criticisms seemed to be from a few years ago - 2000, 2001 - has anyone any advice or warnings or even anything good to say about Paypal? Have they fixed all their problems? |
    |
|
