Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
2 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

Readers may wish to see this questionthis question first, as it's a simpler presentation. Or go to the source, which is the PCI SSC Information Supplement: Protecting Telephone-based Payment Card Data

For a non-automated payment card entry system, if a caller is providing a payment card details over the phone to a call centre employee who confirms the number to the caller, does that mean the organisation is non-PCI DSS compliant?

If the call is recorded, here are the PCI DSS compliance requirements:

  • The recording must be "encrypted using strong cryptography, or otherwise rendered unusable." So the card number - the PAN - may be recorded, but the recording must be encrypted.
  • Some parts of the call, however, may not be recorded: it is "prohibited to use any form of digital audio recording (using formats such as WAV, MP3, etc.) for storing CAV2, CVC2, CVV2 or CID codes after authorization."

If the call is not recorded, then the PCI DSS does not apply (to the call - if the human call center employee is typing the card number they hear into a computer, the DSS starts applying there).

Automated payment card entry system that typically include call recording and masking the bit where the caller says the number. Assuming this satisfies the PCI-DSS compliance, is there a way an attacker can steal the payment card data?

If the PAN portion of the recording is stored encrypted, then an attacker would have to compromise that encryption control. That's certainly not impossible, but it represents a significant barrier that has to be overcome.

If the PAN portion of the recording is masked, that may be impossible to compromise.

If you PCI compliant, the CVV isn't on the recording, which would be impossible to compromise.

For all of these scenarios, the call center employee is going to enter the card data into a system for processing. Everything else being equal, the attacker is going to focus on the processing end of the chain, not the call end - voice is analog and messy, but processing systems are juicy and digital. And that's where the rest of the DSS kicks in...

Readers may wish to see this question first, as it's a simpler presentation. Or go to the source, which is the PCI SSC Information Supplement: Protecting Telephone-based Payment Card Data

For a non-automated payment card entry system, if a caller is providing a payment card details over the phone to a call centre employee who confirms the number to the caller, does that mean the organisation is non-PCI DSS compliant?

If the call is recorded, here are the PCI DSS compliance requirements:

  • The recording must be "encrypted using strong cryptography, or otherwise rendered unusable." So the card number - the PAN - may be recorded, but the recording must be encrypted.
  • Some parts of the call, however, may not be recorded: it is "prohibited to use any form of digital audio recording (using formats such as WAV, MP3, etc.) for storing CAV2, CVC2, CVV2 or CID codes after authorization."

If the call is not recorded, then the PCI DSS does not apply (to the call - if the human call center employee is typing the card number they hear into a computer, the DSS starts applying there).

Automated payment card entry system that typically include call recording and masking the bit where the caller says the number. Assuming this satisfies the PCI-DSS compliance, is there a way an attacker can steal the payment card data?

If the PAN portion of the recording is stored encrypted, then an attacker would have to compromise that encryption control. That's certainly not impossible, but it represents a significant barrier that has to be overcome.

If the PAN portion of the recording is masked, that may be impossible to compromise.

If you PCI compliant, the CVV isn't on the recording, which would be impossible to compromise.

For all of these scenarios, the call center employee is going to enter the card data into a system for processing. Everything else being equal, the attacker is going to focus on the processing end of the chain, not the call end - voice is analog and messy, but processing systems are juicy and digital. And that's where the rest of the DSS kicks in...

Readers may wish to see this question first, as it's a simpler presentation. Or go to the source, which is the PCI SSC Information Supplement: Protecting Telephone-based Payment Card Data

For a non-automated payment card entry system, if a caller is providing a payment card details over the phone to a call centre employee who confirms the number to the caller, does that mean the organisation is non-PCI DSS compliant?

If the call is recorded, here are the PCI DSS compliance requirements:

  • The recording must be "encrypted using strong cryptography, or otherwise rendered unusable." So the card number - the PAN - may be recorded, but the recording must be encrypted.
  • Some parts of the call, however, may not be recorded: it is "prohibited to use any form of digital audio recording (using formats such as WAV, MP3, etc.) for storing CAV2, CVC2, CVV2 or CID codes after authorization."

If the call is not recorded, then the PCI DSS does not apply (to the call - if the human call center employee is typing the card number they hear into a computer, the DSS starts applying there).

Automated payment card entry system that typically include call recording and masking the bit where the caller says the number. Assuming this satisfies the PCI-DSS compliance, is there a way an attacker can steal the payment card data?

If the PAN portion of the recording is stored encrypted, then an attacker would have to compromise that encryption control. That's certainly not impossible, but it represents a significant barrier that has to be overcome.

If the PAN portion of the recording is masked, that may be impossible to compromise.

If you PCI compliant, the CVV isn't on the recording, which would be impossible to compromise.

For all of these scenarios, the call center employee is going to enter the card data into a system for processing. Everything else being equal, the attacker is going to focus on the processing end of the chain, not the call end - voice is analog and messy, but processing systems are juicy and digital. And that's where the rest of the DSS kicks in...

1
source | link

Readers may wish to see this question first, as it's a simpler presentation. Or go to the source, which is the PCI SSC Information Supplement: Protecting Telephone-based Payment Card Data

For a non-automated payment card entry system, if a caller is providing a payment card details over the phone to a call centre employee who confirms the number to the caller, does that mean the organisation is non-PCI DSS compliant?

If the call is recorded, here are the PCI DSS compliance requirements:

  • The recording must be "encrypted using strong cryptography, or otherwise rendered unusable." So the card number - the PAN - may be recorded, but the recording must be encrypted.
  • Some parts of the call, however, may not be recorded: it is "prohibited to use any form of digital audio recording (using formats such as WAV, MP3, etc.) for storing CAV2, CVC2, CVV2 or CID codes after authorization."

If the call is not recorded, then the PCI DSS does not apply (to the call - if the human call center employee is typing the card number they hear into a computer, the DSS starts applying there).

Automated payment card entry system that typically include call recording and masking the bit where the caller says the number. Assuming this satisfies the PCI-DSS compliance, is there a way an attacker can steal the payment card data?

If the PAN portion of the recording is stored encrypted, then an attacker would have to compromise that encryption control. That's certainly not impossible, but it represents a significant barrier that has to be overcome.

If the PAN portion of the recording is masked, that may be impossible to compromise.

If you PCI compliant, the CVV isn't on the recording, which would be impossible to compromise.

For all of these scenarios, the call center employee is going to enter the card data into a system for processing. Everything else being equal, the attacker is going to focus on the processing end of the chain, not the call end - voice is analog and messy, but processing systems are juicy and digital. And that's where the rest of the DSS kicks in...