Greetings, I am wondering what you folks out there do when a customer needs their voice service providers to be PCI compliant. We use many ITSPs over the public internet and it doesn't seem that any of them support any type of SRTP. Do we need to step back and go TDM to our ULC for 'secure' customers? Anyone know of any good inbound/outbound ITSP that is PCI compliant AND supports SRTP over the public network? Thanks in advance.
I am wondering what you folks out there do when a customer needs their voice service providers to be PCI compliant.? We use many ITSPs over the public internet and it doesn?t seem that any of them support any type of SRTP.? Do we need to step back and go TDM to our ULC for ?secure? customers?? Anyone know of any good inbound/outbound ITSP that is PCI compliant AND supports SRTP over the public network?
One way to approach the issue would be to work with the customer on the actual requirements. PCI does not specifically identify a requirement that brings voice service into scope. I believe that any interpretation that would bring voice telecommunications into scope would end up applying to TDM, just as they would to VoIP. -jbn Justin B Newman
Most card processors work over IP now. Drop the pots entirely and reconfigure the customer to clear credit cards over the Internet On Oct 19, 2011, at 5:47 PM, Justin B Newman <justin at ejtown.org> wrote:
I am wondering what you folks out there do when a customer needs their voice service providers to be PCI compliant. We use many ITSPs over the public internet and it doesn?t seem that any of them support any type of SRTP. Do we need to step back and go TDM to our ULC for ?secure? customers? Anyone know of any good inbound/outbound ITSP that is PCI compliant AND supports SRTP over the public network?
One way to approach the issue would be to work with the customer on the actual requirements. PCI does not specifically identify a requirement that brings voice service into scope. I believe that any interpretation that would bring voice telecommunications into scope would end up applying to TDM, just as they would to VoIP.
-jbn Justin B Newman
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This PCI requirement covers the entire Internet, regardless of protocol: ## 11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols (for example, SSL/TLS, Internet protocol security (IPSEC), SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS are: * The Internet <snip> ## Odd that they kill the extra pixels to say "must support use of" instead of "must use", huh? David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 ###Please note my email address is changing: ###from David_Hiers at adp.com ### to David.Hiers at adp.com -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Justin B Newman Sent: Wednesday, October 19, 2011 3:47 PM To: Geoffrey Mina Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] PCI Compliance and VoIP
I am wondering what you folks out there do when a customer needs their voice service providers to be PCI compliant.? We use many ITSPs over the public internet and it doesn't seem that any of them support any type of SRTP.? Do we need to step back and go TDM to our ULC for 'secure' customers?? Anyone know of any good inbound/outbound ITSP that is PCI compliant AND supports SRTP over the public network?
One way to approach the issue would be to work with the customer on the actual requirements. PCI does not specifically identify a requirement that brings voice service into scope. I believe that any interpretation that would bring voice telecommunications into scope would end up applying to TDM, just as they would to VoIP. -jbn Justin B Newman _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
11.1 If the payment application sends, or> facilitates sending, cardholder data over public> networks, the payment application must support On Wed, Oct 19, 2011 at 6:26 PM, Hiers, David <David_Hiers at adp.com> wrote: This PCI requirement covers the entire Internet, regardless of protocol:
It covers the Internet when _payment applications_ are facilitating sending cardholder data. While I can identify ways this would apply, I wouldn't see this applying (as an example) to VoIP lines running to a call center, where the operators key in cardholder data to a payment applications. -jbn
That's the example scenario I'm working on. We are public internet to our itsp. There are call center agents on our network taking CC info on the phone. They are claiming that for pci 1 they can't use a service like ours. Geoff Mina CTO/Co-Founder Connect First Inc. 720.335.5924 888.410.3071 gmina at ConnectFirst.com Sent from my iPhone On Oct 19, 2011, at 5:35 PM, Justin B Newman <justin at ejtown.org> wrote:
11.1 If the payment application sends, or> facilitates sending, cardholder data over public> networks, the payment application must support On Wed, Oct 19, 2011 at 6:26 PM, Hiers, David <David_Hiers at adp.com> wrote: This PCI requirement covers the entire Internet, regardless of protocol:
It covers the Internet when _payment applications_ are facilitating sending cardholder data. While I can identify ways this would apply, I wouldn't see this applying (as an example) to VoIP lines running to a call center, where the operators key in cardholder data to a payment applications.
-jbn
On Wed, Oct 19, 2011 at 6:42 PM, Geoffrey Mina <gmina at connectfirst.com> wrote:
That's the example scenario I'm working on. ?We are public internet to our itsp. There are call center agents on our network taking CC info on the phone. They are claiming that for pci 1 they can't use a service like ours.
The PCI glossary specifically identifies wireless networks as a "public network." (In the body, it specifically mentions GSM). To extend PCI requirements to the communications link between merchant and customer, albeit an interesting idea, would suggest that the merchant should not accept a credit card # from a customer, if the merchant knows the customer is on a GSM phone. That said, because of the way PCI is written, I can see a customer's VoIP infrastructure coming within scope if they have no internal network segmentation. (PCI essentially says, if you don't segment the cardholder data from everything else, everything's in scope). A simple VLAN might take care of this problem for them. As an FYI, there are no "additional" PCI security requirements, per se, for a Level 1 merchant. Level 1 merchants have additional requirements in terms of "validation" ... they can't do a self-assessment questionnaire, and must instead hire an auditor, but the actual security rules are the same for everyone. -jbn
The technological logic of PCI and other compliance in relation to VoIP has always been elusive to me. We had a customer a while back whose equipment was colocated in a well-known carrier hotel. They bought DIA from Tier 1 vendor A, and they were buying SIP origination from another Tier 1 vendor B. Both A and B had POPs in the building. Now, sure, technically, this was going over the "public Internet", I guess, but, they were 50 ft from an extremely dense BGP peering mesh. The realities of routing, both EGP and IGP-wise, in a place like that pretty much ensure that the traffic physically hops inside the building core network only. Yeah, it's crossing a peering link between vendor A and B, but so what? But no, that didn't fly for their major customer in turn -- a payment processor of some description or another. No, they had to buy a dedicated IP circuit (well, mostly cross-connect) to vendor B and run their origination over that. Because that's so much more difficult to tap than an customer->A->B flow. Right. And why is TDM or analog LEC infrastructure inherently secure? In terms of interception, the process for tapping exterior analog plant and even deeply substrated DS0s is much better understood and widely implemented. After all, that stuff has only been around for what, a few decades? And while CALEA switch features and stuff like that is definitely accompanied by process and audit trail, the mechanical aspect of tapping is much easier than identifying, finding, extracting and playing back an RTP stream. "But building employees can be made to provide assistance with tapping IP traffic flowing over the peering point!" Yeah, because nobody's bribed ILEC personnel to assist with tapping wireline conversations before. The point being, if I had something to hide from an organised criminal organisation or even a government, I'd take a so-called "unsecured" VoIP call over the public Internet any day over a TDM or analog line. This crap is ridiculously arbitrary. And that "dedicated", "point-to-point" cross-connect from customer "directly" to vendor B? Yeah, that traffic physically flows through intermediate (and highly tappable) network elements on their side, too, like switches and routers, or maybe even an oversubscription bus provided by some MPLS or ONS-type optical aggregation box. It's almost like a ... network! Like the building network that facilitates the IX itself! If somebody wants to mandate end-to-end encryption or >= network and transport-level security across the board, fine. But to pretend that one type of circuit design through intermediate Layer 1-3 boxes is more secure than another is just infantile thumb-sucking that passes for financial security discourse. Where do they come up with this crap? </rant> -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
Can you encapsulate VoIP traffic in a VPN? The question then would be if they will understand and accept that as a solution. Good Luck, On Wed, Oct 19, 2011 at 7:42 PM, Geoffrey Mina <gmina at connectfirst.com>wrote:
That's the example scenario I'm working on. We are public internet to our itsp. There are call center agents on our network taking CC info on the phone. They are claiming that for pci 1 they can't use a service like ours.
Geoff Mina CTO/Co-Founder Connect First Inc. 720.335.5924 888.410.3071 gmina at ConnectFirst.com
Sent from my iPhone
On Oct 19, 2011, at 5:35 PM, Justin B Newman <justin at ejtown.org> wrote:
11.1 If the payment application sends, or> facilitates sending, cardholder data over public> networks, the payment application must support On Wed, Oct 19, 2011 at 6:26 PM, Hiers, David <David_Hiers at adp.com> wrote: This PCI requirement covers the entire Internet, regardless of protocol:
It covers the Internet when _payment applications_ are facilitating sending cardholder data. While I can identify ways this would apply, I wouldn't see this applying (as an example) to VoIP lines running to a call center, where the operators key in cardholder data to a payment applications.
-jbn
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 10/19/2011 08:21 PM, Oren Yehezkely wrote:
Can you encapsulate VoIP traffic in a VPN?
It would seem that this would meet the spirit and practical implications of the language. It's what we recommend. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
I've no doubt that they are correct; card information encapsulated in a codec needs to be encrypted over unsecure networks, which includes the Internet. We can safely assume that they are in contact with the PCI standards people, and getting advice from other PCI compliant entities. David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 ###Please note my email address is changing: ###from David_Hiers at adp.com ### to David.Hiers at adp.com -----Original Message----- From: Geoffrey Mina [mailto:gmina at connectfirst.com] Sent: Wednesday, October 19, 2011 4:43 PM To: Justin B Newman Cc: Hiers, David (DS); voiceops at voiceops.org Subject: Re: [VoiceOps] PCI Compliance and VoIP That's the example scenario I'm working on. We are public internet to our itsp. There are call center agents on our network taking CC info on the phone. They are claiming that for pci 1 they can't use a service like ours. Geoff Mina CTO/Co-Founder Connect First Inc. 720.335.5924 888.410.3071 gmina at ConnectFirst.com Sent from my iPhone On Oct 19, 2011, at 5:35 PM, Justin B Newman <justin at ejtown.org> wrote:
11.1 If the payment application sends, or> facilitates sending, cardholder data over public> networks, the payment application must support On Wed, Oct 19, 2011 at 6:26 PM, Hiers, David <David_Hiers at adp.com> wrote: This PCI requirement covers the entire Internet, regardless of protocol:
It covers the Internet when _payment applications_ are facilitating sending cardholder data. While I can identify ways this would apply, I wouldn't see this applying (as an example) to VoIP lines running to a call center, where the operators key in cardholder data to a payment applications.
-jbn
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
On 10/20/11 6:07 AM, Hiers, David wrote:
I've no doubt that they are correct; card information encapsulated in a codec needs to be encrypted over unsecure networks, which includes the Internet.
We can safely assume that they are in contact with the PCI standards people, and getting advice from other PCI compliant entities.
But is not the analog/TDM PSTN also a public, insecure, unencrypted network? What's more difficult, tapping an analog phone line with a simple recorder coupler from Rat Shack or intercepting a specific RTP stream over a random route mixed in with gigabytes of pornography and other assorted cruft? It boggles how people who think nothing about using cordless phones are so paranoid about VoIP security over the Internet. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
On 10/20/2011 10:55 PM, Jay Hennigan wrote:
What's more difficult, tapping an analog phone line with a simple recorder coupler from Rat Shack or intercepting a specific RTP stream over a random route mixed in with gigabytes of pornography and other assorted cruft?
That's what I was thinking, and of which my rant was an expression. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 20, 2011, at 10:55 PM, Jay Hennigan wrote:
On 10/20/11 6:07 AM, Hiers, David wrote:
I've no doubt that they are correct; card information encapsulated in a codec needs to be encrypted over unsecure networks, which includes the Internet.
We can safely assume that they are in contact with the PCI standards people, and getting advice from other PCI compliant entities.
But is not the analog/TDM PSTN also a public, insecure, unencrypted network? What's more difficult, tapping an analog phone line with a simple recorder coupler from Rat Shack or intercepting a specific RTP stream over a random route mixed in with gigabytes of pornography and other assorted cruft?
It boggles how people who think nothing about using cordless phones are so paranoid about VoIP security over the Internet.
Attached to my backpack is a massive PCI standard violation. I think nothing of carrying it every day. How long until they either try to ban my fluke ts44 deluxe, or wake up to the idea that POTS is less secure but still not considered a problem. It's not like it's hard to decode the 300 baud FSK datastream of a credit card terminal. A T1 is no match for my T-Berd 224, comparatively a relic but perfectly capable of doing what my harris can do to a t1. Even if that's some high rent money for you, my phoenix networks t1 test unit can do it and cost less than the buttset on ebay. Preaching to the choir here, of course, but it's just plain silly. Any of these devices could be used relatively anonymously with nothing more than a $30 assortment of various tools (can wrench, inverted hex wrench used on a lot of remote terminal and cell tower enclosures, smartjack enclosure key). If you're broke and your adversary has a pots line, climbing the pole and taking a corded phone with the jack hacked off to expose the wires will give you more access and anonymity than you could ever want. But here we are talking about military grade encryption for some RTP streams over a generally saturated backbone network with 10 gige links brimming with porn. LOL. Talk about killing an ant by running it over with a semi truck. -Paul
On Fri, 21 Oct 2011, Paul Timmins wrote:
On Oct 20, 2011, at 10:55 PM, Jay Hennigan wrote:
On 10/20/11 6:07 AM, Hiers, David wrote:
I've no doubt that they are correct; card information encapsulated in a codec needs to be encrypted over unsecure networks, which includes the Internet.
We can safely assume that they are in contact with the PCI standards people, and getting advice from other PCI compliant entities.
But is not the analog/TDM PSTN also a public, insecure, unencrypted network? What's more difficult, tapping an analog phone line with a simple recorder coupler from Rat Shack or intercepting a specific RTP stream over a random route mixed in with gigabytes of pornography and other assorted cruft?
It boggles how people who think nothing about using cordless phones are so paranoid about VoIP security over the Internet.
Attached to my backpack is a massive PCI standard violation. I think nothing of carrying it every day.
How long until they either try to ban my fluke ts44 deluxe, or wake up to the idea that POTS is less secure but still not considered a problem. It's not like it's hard to decode the 300 baud FSK datastream of a credit card terminal.
A T1 is no match for my T-Berd 224, comparatively a relic but perfectly capable of doing what my harris can do to a t1. Even if that's some high rent money for you, my phoenix networks t1 test unit can do it and cost less than the buttset on ebay.
Preaching to the choir here, of course, but it's just plain silly. Any of these devices could be used relatively anonymously with nothing more than a $30 assortment of various tools (can wrench, inverted hex wrench used on a lot of remote terminal and cell tower enclosures, smartjack enclosure key). If you're broke and your adversary has a pots line, climbing the pole and taking a corded phone with the jack hacked off to expose the wires will give you more access and anonymity than you could ever want.
But here we are talking about military grade encryption for some RTP streams over a generally saturated backbone network with 10 gige links brimming with porn. LOL. Talk about killing an ant by running it over with a semi truck.
Comparing an analog phone line or smaller TDM circuits to >= 1 gig backbone data connections does not seem very fair. Heck, my T-Berd can pick out and listen to a DS0 on a DS3 let alone a T1. But try doing that with an OC48. I am not even sure if they make gear to be able to do that easily let alone having a monitor point to jack into in most cases. Yet with a data connection, depending on the hardware and speed of the port, you can just mirror a port and dump all or selectively dump the traffic to a cheap linux box with monster size HDs. Retrieve it after business hours and pick out calls at your liesure. Data seems equally weak everywhere while larger TDM circuits seem more difficult. To me at least. I am also making an assumption one cannot take down any circuit for any amount of time to accomplish the goal of "listening in/recording". Hey.. someone has to attempt to defend the PSTN/TDM networks :-) matt
-Paul _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Oct 21, 2011, at 2:18 AM, Matt Yaklin wrote:
Comparing an analog phone line or smaller TDM circuits to >= 1 gig backbone data connections does not seem very fair.
Heck, my T-Berd can pick out and listen to a DS0 on a DS3 let alone a T1. But try doing that with an OC48. I am not even sure if they make gear to be able to do that easily let alone having a monitor point to jack into in most cases.
Lol, if you have a 15454, look under one of your cross connects and click the "Monitors" tab. Click on one of the circuits, and select the button at the bottom labeled "Create Monitor Circuit". Point it at a channel on a DS3 mux with your t-berd hanging off of it, instant port mirror! I love the PSTN too, but let's call overengineering what it is. :)
On Wed, Oct 19, 2011 at 6:26 PM, Hiers, David <David_Hiers at adp.com> wrote: That doesn't really "cover" the internet... it just mentions the internet. "11.1 If the payment application ... the payment application must support use of strong cryptography and security protocols". This would mean that the payment application software has to support encryption of data before emitting it over any public network, that's entirely agnostic to the nature of the transport, whether it be radio broadcasts, US mail, or carrier pigeons, the application has to encrypt the message, no matter whether the message is transmitted packetized as PCM over a series of IP packets, analog audio signals, a .WAV file attached to an e-mail, or printed on punch cards for snail mail. Modern payment applications don't normally utilize voice (or punch cards), however.....
This PCI requirement covers the entire Internet, regardless of protocol: ## 11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols [snip]
-- -JH
Whats really sad about all this is we can make everything as secure as possible using what ever transport method we can think of. But 99% of the fraud is going to come from an employee that has access to the data. Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / www.race.com On 10/19/11 5:49 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
On Wed, Oct 19, 2011 at 6:26 PM, Hiers, David <David_Hiers at adp.com> wrote:
That doesn't really "cover" the internet... it just mentions the internet. "11.1 If the payment application ... the payment application must support use of strong cryptography and security protocols".
This would mean that the payment application software has to support encryption of data before emitting it over any public network, that's entirely agnostic to the nature of the transport, whether it be radio broadcasts, US mail, or carrier pigeons, the application has to encrypt the message, no matter whether the message is transmitted packetized as PCM over a series of IP packets, analog audio signals, a .WAV file attached to an e-mail, or printed on punch cards for snail mail.
Modern payment applications don't normally utilize voice (or punch cards), however.....
This PCI requirement covers the entire Internet, regardless of protocol: ## 11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols [snip]
-- -JH _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Um, that's kinda the point, actually. One of the outcomes of the technical security of the network is to force attacks to occur at the endpoints. There is a much smaller, much more controllable set of people to deal with at the endpoints. You can even establish further controls at the endpoints to make attacks harder to perform, require collusion between multiple parties, limit the scope of a successful attack, and increase the ability to detect attack attempts. There will always be a soft spot in the system, you want to move it to where you have lots of "cameras". David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 ###Please note my email address is changing: ###from David_Hiers at adp.com ### to David.Hiers at adp.com -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alcantar Sent: Wednesday, October 19, 2011 11:26 PM To: VoiceOps Subject: Re: [VoiceOps] PCI Compliance and VoIP Whats really sad about all this is we can make everything as secure as possible using what ever transport method we can think of. But 99% of the fraud is going to come from an employee that has access to the data. Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / www.race.com On 10/19/11 5:49 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
On Wed, Oct 19, 2011 at 6:26 PM, Hiers, David <David_Hiers at adp.com> wrote:
That doesn't really "cover" the internet... it just mentions the internet. "11.1 If the payment application ... the payment application must support use of strong cryptography and security protocols".
This would mean that the payment application software has to support encryption of data before emitting it over any public network, that's entirely agnostic to the nature of the transport, whether it be radio broadcasts, US mail, or carrier pigeons, the application has to encrypt the message, no matter whether the message is transmitted packetized as PCM over a series of IP packets, analog audio signals, a .WAV file attached to an e-mail, or printed on punch cards for snail mail.
Modern payment applications don't normally utilize voice (or punch cards), however.....
This PCI requirement covers the entire Internet, regardless of protocol: ## 11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols [snip]
-- -JH _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
We are probably going to pull a private line from level3 and use them for TF inbound and LD outbound. Should satisfy the requirement of _not_ traversing the public internet. We are in level3 co-lo so it should be relatively cheap. Thanks for everyones input. Geoff Mina CTO/Co-Founder Connect First Inc. 720.335.5924 888.410.3071 gmina at ConnectFirst.com Sent from my iPhone On Oct 20, 2011, at 7:15 AM, "Hiers, David" <David_Hiers at adp.com> wrote:
Um, that's kinda the point, actually.
One of the outcomes of the technical security of the network is to force attacks to occur at the endpoints. There is a much smaller, much more controllable set of people to deal with at the endpoints. You can even establish further controls at the endpoints to make attacks harder to perform, require collusion between multiple parties, limit the scope of a successful attack, and increase the ability to detect attack attempts.
There will always be a soft spot in the system, you want to move it to where you have lots of "cameras".
David Hiers
CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277
###Please note my email address is changing: ###from David_Hiers at adp.com ### to David.Hiers at adp.com
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alcantar Sent: Wednesday, October 19, 2011 11:26 PM To: VoiceOps Subject: Re: [VoiceOps] PCI Compliance and VoIP
Whats really sad about all this is we can make everything as secure as possible using what ever transport method we can think of. But 99% of the fraud is going to come from an employee that has access to the data.
Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / www.race.com
On 10/19/11 5:49 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
On Wed, Oct 19, 2011 at 6:26 PM, Hiers, David <David_Hiers at adp.com> wrote:
That doesn't really "cover" the internet... it just mentions the internet. "11.1 If the payment application ... the payment application must support use of strong cryptography and security protocols".
This would mean that the payment application software has to support encryption of data before emitting it over any public network, that's entirely agnostic to the nature of the transport, whether it be radio broadcasts, US mail, or carrier pigeons, the application has to encrypt the message, no matter whether the message is transmitted packetized as PCM over a series of IP packets, analog audio signals, a .WAV file attached to an e-mail, or printed on punch cards for snail mail.
Modern payment applications don't normally utilize voice (or punch cards), however.....
This PCI requirement covers the entire Internet, regardless of protocol: ## 11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols [snip]
-- -JH _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
That's what we do with most providers and clients to satisfy the PCI requirements for our contact center customers. Cross-connects and data links are so cheap these days that it's usually a no-brainer. If not feasible, we use TLS / SRTP encryption to secure signaling/RTP. Best Regards, Ivan Kovacevic Star Telecom | www.startelecom.ca -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Geoffrey Mina Sent: October-20-11 9:52 AM To: Hiers, David Cc: VoiceOps Subject: Re: [VoiceOps] PCI Compliance and VoIP We are probably going to pull a private line from level3 and use them for TF inbound and LD outbound. Should satisfy the requirement of _not_ traversing the public internet. We are in level3 co-lo so it should be relatively cheap. Thanks for everyones input. Geoff Mina CTO/Co-Founder Connect First Inc. 720.335.5924 888.410.3071 gmina at ConnectFirst.com Sent from my iPhone On Oct 20, 2011, at 7:15 AM, "Hiers, David" <David_Hiers at adp.com> wrote:
Um, that's kinda the point, actually.
One of the outcomes of the technical security of the network is to force attacks to occur at the endpoints. There is a much smaller, much more controllable set of people to deal with at the endpoints. You can even establish further controls at the endpoints to make attacks harder to perform, require collusion between multiple parties, limit the scope of a successful attack, and increase the ability to detect attack attempts.
There will always be a soft spot in the system, you want to move it to where you have lots of "cameras".
David Hiers
CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277
###Please note my email address is changing: ###from David_Hiers at adp.com ### to David.Hiers at adp.com
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alcantar Sent: Wednesday, October 19, 2011 11:26 PM To: VoiceOps Subject: Re: [VoiceOps] PCI Compliance and VoIP
Whats really sad about all this is we can make everything as secure as possible using what ever transport method we can think of. But 99% of the fraud is going to come from an employee that has access to the data.
Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / www.race.com
On 10/19/11 5:49 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
On Wed, Oct 19, 2011 at 6:26 PM, Hiers, David <David_Hiers at adp.com> wrote:
That doesn't really "cover" the internet... it just mentions the internet. "11.1 If the payment application ... the payment application must support use of strong cryptography and security protocols".
This would mean that the payment application software has to support encryption of data before emitting it over any public network, that's entirely agnostic to the nature of the transport, whether it be radio broadcasts, US mail, or carrier pigeons, the application has to encrypt the message, no matter whether the message is transmitted packetized as PCM over a series of IP packets, analog audio signals, a .WAV file attached to an e-mail, or printed on punch cards for snail mail.
Modern payment applications don't normally utilize voice (or punch cards), however.....
This PCI requirement covers the entire Internet, regardless of protocol: ## 11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols [snip]
-- -JH _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (12)
-
abalashov＠evaristesys.com -
carlos＠race.com -
David_Hiers＠adp.com -
gmina＠connectfirst.com -
ivank＠rogers.com -
jay＠west.net -
justin＠ejtown.org -
matthew＠corp.crocker.com -
myaklin＠g4.net -
mysidia＠gmail.com -
orenyny＠gmail.com -
paul＠timmins.net