I received a mailing from American Express today discussing data security operating policies for merchants. American Express claims they are a leader in consumer privacy protection. What got me scared was the statement that in the event that credit card data sitting on my server is hacked into and I neglect to notify American Express, that I am held liable for all fradulant charges should any occur.

So, just to make sure my site is following the American Express guidelines, I'm wondering.....

1. They require that "all stored payment data use triple DES encryption." Do we have that?

2. "Never store payment data on a web server or cache anywhere in memory related to a web server. Payment data may only be stored in a separate database, with at least one external firewall." Do we have that?

3. "Web site must be enabled with Secure Socket Layer 3.0 with 128-bit encryption." I just bought my own secure server certificate through GeoTrust and remember that that part is 128-bit. But I'm not sure on the 3.0 thing.

I use the Custom Payment Manager method for capturing my customer's cc information when they place their order. Once their order has shipped, I use my Authorize.net virtual terminal to process the transaction. To prevent against an attack from hackers into my database where my customer orders are stored (along with their cc info), should I be deleting the orders after a few months?

These are all questions I hope the fine employees at can answer. This is a very important issue to every merchant. I hope your answers will give me and other worried merchants complete peace of mind.

Rachel,

Sorry I misses this posts.... thanks for PM-ing me. I will have Adnan and Steph respond. Thanks.

Ryan

>1. They require that "all stored payment data use triple DES encryption." Do we
>have that?
We use a better encryption algorithm than triple DES, if I recall correctly the developers are using AES although I may be mistaken. I do know we satisfy/exceed this requirement, but just to make sure I am not completely off on which algorithm is used... one of the MC developers should confirm shortly.

>2. "Never store payment data on a web server or cache anywhere in memory
>related to a web server. Payment data may only be stored in a separate
>database, with at least one external firewall." Do we have that?

It is not possible to not store the payment data non-cached or not in memory, as "in memory" is how all transactions are sent, such as cc info, names, addresses, products, etc, etc. As for the duration of time in memory, the data is not stored per se in memory, as the resource/memory allocation is freed upon termination of the https session, but the data is transient during submission time....there is no way around this nd I believe AMEX is refering to long term storage and not tranactional. The data is stored in a database that is not a flat file or similar caching tool, but a standalone database file (3.x uses MDB files/Access type, where 4.x uses SQL Server db files and is completely external to the web site itself).

Additionally, our servers are behind a constantly monitored and secure Cisco PIX 525 UR, with regular audits.


>3. "Web site must be enabled with Secure Socket Layer 3.0 with 128-bit
>encryption." I just bought my own secure server certificate through GeoTrust and
>remember that that part is 128-bit. But I'm not sure on the 3.0 thing.

I believe this is a misnomer, all our certs are acquired with 1024 bit keys, so we definitely satisfy that requirement. As for *must* use 3.0, we do...but we also allow for 2.0 type SSL protocol handshakes/negotiations as otherwise many customers to our sites without a current browser would not be able to shop.

2.0 is no worse than 3.0 but the best answer here is we use 3.0 by default, except in the occasional cases where the client browser requires an older type of negotiation, which is handled by the server on a per client basis.


>I use the Custom Payment Manager method for capturing my customer's cc
>information when they place their order. Once their order has shipped, I use my
>Authorize.net virtual terminal to process the transaction. To prevent against an
>attack from hackers into my database where my customer orders are stored
>(along with their cc info), should I be deleting the orders after a few months?

This is really up to you, although I strongly doubt that there is much to worry about in general a we make security a very important priority at MonsterCommerce and have yet to encounter any type of external security problem/issue from server or network compromise during my tenure to date with the company....keep in mind this includes the last few IIS, SQL Server, and related worms, virii and other compromise issues that affected a large percentage of machines on the internet...which goes to illustrate we keep up with our software, system, and network security/integrity.

Yay, that's great news! And thanks for responding!

Good news to hear from . But...

What about Authorize.net?

We use the AES Algorithm for many reasons, here is just one of them.

Currently, there exist four FIPS-approved symmetric key algorithms for encryption: Advanced Encryption Standard (AES), Data Encryption Standard (DES), Triple-DES, and Skipjack. AES is the FIPS-Approved symmetric encryption algorithm of choice.

Yeah... I'd say they've got it covered!