1

The full Account number data plus Personally Identifiable Information (PII) for a credit card is captured in a document that is scanned as an image for later processing. This image is then uploaded to another application. I am concerned that these scanned images contain all credit card data (Primary Account Number, Cardholder name, Expiry date, CVV number) and other PII information such as Residential Address and Phone number, all in plain text, though saved as an image.

The data is sent over HTTPS protocol. I am looking out for further more controls to strengthen this from capturing the track data at the first point. I request for more insights on this.

(Bit more explained: The card data is collected in document written down (all data in a credit card). The document is scanned and the image is sent through an application to the service provider. The service provider agent sees the data and manually enters it on another application. This application has the truncation enabled)

Improve this question
5
  • how is this any different than submitting credit card information in a web page?
    – Whome
    Jan 8, 2016 at 16:07
  • 1
    I am sorry it is really hard to understand what you are asking, perhaps you could rephrase it or add additional information. Why do you have images of credit cards and for what purpose? Don't you need the information that you listed (cardholder name etc.)? It is also is contradictory the data is sent over https, but the headline says in plain text.
    – John
    Jan 8, 2016 at 16:13
  • I have edited/clarified the OP as I believe correctly describes the scenario.
    – Rodrigo Murillo
    Jan 8, 2016 at 16:51
  • To oversimplify slightly, anytime the card information you mention hits an electronic "storage" medium (whether hard disk/SSD, optical disk, USB flash drive, etc.) it must be kept there only in encrypted, tokenized, or otherwise appropriately (ie. meeting the standards set down in the Requirements) protected form. The media format in which that info is stored--whether in an image, in text form, in a video, in an audio recording, etc.--doesn't change whether encryption (or tokenization) is needed.
    – mostlyinformed
    Jan 8, 2016 at 19:35
  • Also, remember that a provision in the PCI Requirement governing storage completely prohibits storing CVV data.
    – mostlyinformed
    Jan 8, 2016 at 19:44

2 Answers 2

Reset to default
2

Regardless of the format it is in, storing full PAN data increases security risk and, consequently, it’s scope of PCI compliance.

You would need to make sure that at every step, these compliance requirements are met:

  1. One-way hashes based on strong cryptography
  2. Truncation
  3. Strong cryptography
  4. Index tokens and pads

If you storing PAN data as indicated, then PCI DSS Requirement 3.4 requires that you render it unreadable and unrecoverable through one of those methods.

If you implement one of those methods, you are fine.

If not you have to implement one of those on that scanned image. Encryption of an image as a ZIP would be one option. Key management is always an issue with encryption, but if properly architected, it is feasible.

Improve this answer
4
  • Please avoid the use of not well known acronyms. This forum has a wide variety of backgrounds, and not everyone is in the credit card industry and knows that PAN is Primary Account Number. (I myself had to google this)
    – Steve Sether
    Jan 8, 2016 at 17:58
  • One point: if the OP does intend to meet PCI standards by encrypting the images--and I absolutely agree that they need to be encrypted, just as if Word docs or database files containing similar info in them would need to be encrypted in transit & at rest--then the encryption method/implementation has to meet the requirements stated in the Rule pertaining to stored card info. Some ZIP archiving programs do not protect "encrypted" archives with anything close to strong encryption under the Rule. (Of course, some can/do.)
    – mostlyinformed
    Jan 8, 2016 at 18:56
  • @halfinformed - good points. The "at rest" requirement could be a challenge, apart from the strong encryption issue. The image presumably exists at rest as a file before encrypting - not good. You would need to generate the image in memory then encrypt the stream to zip via a native library.
    – Rodrigo Murillo
    Jan 8, 2016 at 22:22
  • @Rodrigo I think that's absolutely true: you'd prefer that no unencrypted version of a file with sensitive information in it ever be written to disk (or whatever other medium) in the first place. Otherwise, for every file that gets written you have to ensure that (1) a new, encrypted version is created correctly and (2) the old, unencrypted version is securely deleted. Versus just-forgotten-about-by-the-filing-system, which is what some tools will do. And, of course, what constitutes that "secure" deletion of all sensitive data in a file on a drive somewhere has its own complexities.
    – mostlyinformed
    Jan 10, 2016 at 8:42
2

You cannot store sensitive credit card data "after authorization" (as per PCI DSS requirements, point 3.2) so you must make sure (and provide evidence) that every copy (the original printed copy captured at the scanner and the digital one sent to the application at both ends) are securely destroyed inmediately after. It is not a problem itself to send the data the way you want, but it could be to demonstrate that every copy is correctly dispossed off:

  • Hard-copy materials must be crosscut shredded, incinerated, or pulped [...]
  • Cardholder data on electronic media must be rendered unrecoverable (e.g.,via a secure wipe program in accordance with industry-accepted standards for secure deletion, or by physically destroying the media )

Also, if there is personal information, some countries have their own regulation that require levels of protection for that data that are similar to PCI standards. Check for those that would apply to your case.

Improve this answer
2
  • A good point for the OP to remember about properly destroying the on-paper copies of the card information, ie. the stuff that gets written down and then entered into the computers. Maybe the business in question is already be diligent enough about securely shredding 100% of that stuff immediately after data entry. But more likely anybody who did some dumpster diving at the site would be able to recover at least some amount of card information usable for fraud.
    – mostlyinformed
    Jan 10, 2016 at 8:57
  • Also, I would like to add another information to this. The number of transaction is approximately 3000 per year. I would need some help on the applicability of SAQ.
    – Bala
    Jan 11, 2016 at 11:33

Not the answer you're looking for? Browse other questions tagged .