[Dataloss] Firms play Data Protection roulette

[Saundra Kae Rubel]

PCI Data Security Standard #6.3.4 requires that "Production data (real
credit card numbers) are not used for testing or development."
This applies to all levels of merchants no matter how many transactions are
performed.

See more at :
http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cis
p_PCI_Data_Security_Standard.pdf

Saundra Kae Rubel, CIPP
 

-----Original Message-----
From: dataloss-bounces at attrition.org [mailto:dataloss-bounces at attrition.org]
On Behalf Of George Toft
Sent: Monday, July 10, 2006 5:32 AM
To: dataloss at attrition.org
Subject: Re: [Dataloss] Firms play Data Protection roulette

If the client is really serious about this effort, I think it is much 
better than using real data.  I suggest scrambling the credit card info 
(SSN's as well) unless there is some aspect of the application that does 
a validity check on the value.  For CC numbers, if the CC processor 
returned an authorization code at the time of sale, it must be valid, so 
I see no reason to maintain that number intact.

I also recommend they make someone personally accountable for any real 
data stored outside of the prod environment.  Without accountability, 
the rules won't be followed, and you'll find real data stored on 
machines without adequate security...

My thoughts :)

George Toft, CISSP, MSIS
My IT Department
www.myITaz.com
480-544-1067

Confidential data protection experts for the financial industry.


Peter Wood wrote:
> We discussed recently the matter of real data in a test environment 
> with a client. Frequently, when conducting an internal penetration 
> test, we find copies of real data on development machines unprotected 
> by passwords or encryption. Rather than try to insist that developers 
> protect this real data properly, which is never going to happen, we 
> suggested the following: (1) replace all name fields with alpha 
> garbage (of the correct field lengths) so as to depersonalise the 
> data (2) randomly swap fields such as city, zip code, credit card 
> number etc. so that any given row of data is useless to a thief but 
> still valid per range checks etc.
> 
> Any views on this idea?
> 
> Pete
> 
> At 08:10 09/07/2006 -0700, George Toft wrote:
>  >I think we should make a distinction between live data and real data.
>  >
>  >Some companies make copies of their live data and put it in their
>  >development environment(s) for development and testing.  It's not live
>  >data, but it is certainly real.
>  >
>  >There are many benefits to using a copy of live data, but in today's
>  >reality, I think the risk to the business is too great to endorse this
>  >activity.  I think it also might violate the spirit of "separation of
>  >duty" that most companies implement to keep developers out of production
>  >systems.
>  >
>  >Regards,
>  >
>  >George Toft, CISSP, MSIS
>  >My IT Department
>  >www.myITaz.com
>  >480-544-1067
> 
> 
> --------------------------------------------------------------------
> Peter Wood FBCS CITP MIEEE MIMIS CISSP
> Chief of Operations
> First Base Technologies
> Office: +44 (0)1273 454525
> Mobile: +44 (0)7774 239915
> www.fbtechies.co.uk
> www.white-hats.co.uk
> 
> _______________________________________________
> Dataloss Mailing List (dataloss at attrition.org)
> http://attrition.org/errata/dataloss/
> 
> 
> 
_______________________________________________
Dataloss Mailing List (dataloss at attrition.org)
http://attrition.org/errata/dataloss/