[NSRCA-discussion] FMA Database Compromised

Gene Maurice gene.maurice at sgmservice.com
Wed Nov 19 07:53:57 AKST 2008


Whoever they are processing the payments thru, Payment Processor, Payment
Clearinghouse, etc.,  SHOULD be informing them of the standard and have them
verify that they meet the standard.  If found in violation the CC companies
could go back thru the food chain, Clearinghouse - Processor - Merchant, to
recoup any losses. In this day, any business storing a clients CC data, or
any other secure personal data, on an internal system is asking for trouble.


 

Gene Maurice

Plano, TX

AMA 3408 NSRCA 877

PACSS.sgmservice.com

gene.maurice at sgmservice.com

 

 

 

 

 

From: nsrca-discussion-bounces at lists.nsrca.org
[mailto:nsrca-discussion-bounces at lists.nsrca.org] On Behalf Of Dave Burton
Sent: Wednesday, November 19, 2008 10:16 AM
To: 'General pattern discussion'
Subject: Re: [NSRCA-discussion] FMA Database Compromised

 

I'll make you a bet that 95+% of small businesses don't know about much less
follow the standards.

The bad guys hit my account too but the bank fraud control unit called to
alert me and resolved it with a new account number.

Dave Burton

 

From: nsrca-discussion-bounces at lists.nsrca.org
[mailto:nsrca-discussion-bounces at lists.nsrca.org] On Behalf Of Gene Maurice
Sent: Wednesday, November 19, 2008 10:56 AM
To: 'General pattern discussion'
Subject: Re: [NSRCA-discussion] FMA Database Compromised

 

Credit card information is suppose to be encrypted and secured. There is an
organization PCI (Payment Card Industry) who has issued a Data Security
Standard that "mandates" certain security measures be implemented if you
deal with CC payments.  

Quote: PCI DSS requirements are applicable if a Primary Account Number (PAN)
is stored, processed, or

transmitted.

 

The standards further states, quote:

 Do not store sensitive authentication data subsequent to authorization
(even if encrypted).

 

And, quote: 

Render PAN, at minimum, unreadable anywhere it is stored (including data on
portable digital

media, backup media, in logs, and data received from or stored by wireless
networks) by using

any of the following approaches:

. Strong one-way hash functions (hashed indexes)

. Truncation

. Index tokens and pads (pads must be securely stored)

. Strong cryptography with associated key management processes and
procedures.

 

Sounds like FMA ain't following the standard......

 

Gene Maurice

Plano, TX

AMA 3408 NSRCA 877

PACSS.sgmservice.com

gene.maurice at sgmservice.com

 

 

 

From: nsrca-discussion-bounces at lists.nsrca.org
[mailto:nsrca-discussion-bounces at lists.nsrca.org] On Behalf Of Jay Marshall
Sent: Wednesday, November 19, 2008 7:42 AM
To: 'General pattern discussion'
Subject: Re: [NSRCA-discussion] FMA Database Compromised

 

This is the reason I use "one time" credit card numbers from Shop Safe where
you specify the max amount and a valid period. I have never understood why
credit card numbers must remain on a database after they have cleared. They
ought to be encoded also!

 

 

Jay Marshall 

-----Original Message-----
From: nsrca-discussion-bounces at lists.nsrca.org
[mailto:nsrca-discussion-bounces at lists.nsrca.org] On Behalf Of MKMSG
Sent: Wednesday, November 19, 2008 12:15 AM
To: NSRCA Discussion List
Subject: [NSRCA-discussion] FMA Database Compromised

 

If any of you have recently bought products on line from FMA Direct using a
credit card, check your credit card account.  FMA's database has been
compromised/hacked and whoever has the information is making charges against
the credit cards.  I read this in the electric forum on Ezonemag.com.
Sure enough, when I brought up my VISA account, there was a NAPSTER charge
there so I cancelled the card.  You might want to check yours if you've done
business on line with FMA recently.

 

Mike

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nsrca.org/pipermail/nsrca-discussion/attachments/20081119/391ee6fb/attachment.html>


More information about the NSRCA-discussion mailing list