We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Secure payments over VoIP calls in the cloud

00:00

Formal Metadata

Title
Secure payments over VoIP calls in the cloud
Subtitle
How to architect an oncall live payment system in the cloud using Kamailio & RTP Engine.
Title of Series
Number of Parts
542
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Just using OSS, namely kamailio and rtpengine and using a public cloud provider for hosting (it can be anything), we want to share how we have put an oncall live credit card payment system PCI/DSS certified together. We will also go through the infrastructure parts and networking requirements that show how we also did this to be stateless as possible and horizontal scalable towards anyone's need. This will be a company sponsored talk by people that advocate for OSS technology adoption. On the call center industry it is often needed to process payments while on call with customers, Talkdesk is a cloud native contact center solution provider where customers demand such feature for their daily usage. The talk goal is to show how we at Talkdesk have replaced proprietary resources previously in use, just by OSS namely kamailio & rtpengine and how we have architected a new solution for oncall live credit card payments PCI/DSS certified. We will go through some of the issues we were having before with a proprietary dependent implementation and on how we replaced it by a totally new solution totally owned by Talkdesk that just replaced the old buggy proprietary based implementation. We will also share how we made the implementation secure, stateless, scalable PCI/DSS certified also being cloud native.
14
15
43
87
Thumbnail
26:29
146
Thumbnail
18:05
199
207
Thumbnail
22:17
264
278
Thumbnail
30:52
293
Thumbnail
15:53
341
Thumbnail
31:01
354
359
410
Physical systemCloud computingArchitectureProcess capability indexDecision support systemInternettelefonieProcess capability indexRule of inferenceOpen sourceInformation securityStandard deviationCloud computingComputer architectureOrder (biology)Computer animation
Standard deviationInformation securityMemory cardPlastikkarteRule of inferenceProcess capability indexProcess (computing)Decision support systemAdditionComputer wormFormal verificationLevel (video gaming)EmailIntegrated development environmentOperations support systemSession Initiation ProtocolDisintegrationNP-hardArchitectureDefault (computer science)Database normalizationCodeExclusive orCloud computingComponent-based software engineeringComputer-generated imageryContinuous integrationSingle-precision floating-point formatCharge carrierFlow separationRouter (computing)Process (computing)EmailArrow of timeInstance (computer science)CASE <Informatik>HypermediaInformationMultiplication signOrder (biology)PlastikkarteIntegrated development environmentSystem callRule of inferenceInformation securityNumberSession Initiation ProtocolProcess capability indexVirtual machineComputer architectureOvalNormal (geometry)Personal identification numberCodeImplementationTouchscreenCloud computingDialerType theorySquare numberLevel (video gaming)Telecommunication1 (number)Memory cardDifferent (Kate Ryan album)Computer animation
World Wide Web ConsortiumMereologyOrder (biology)InformationService (economics)Process (computing)Descriptive statisticsCodeComputer animation
ArchitectureIntegerIntegrated development environmentProduct (business)Computer fileHard disk driveConfiguration spaceTouch typingEncryptionComputer animation
CodeRevision controlInstance (computer science)ArchitectureData managementInstance (computer science)Row (database)Charge carrierDirect numerical simulationComputer architectureProcess capability indexInternet service providerDecision theoryInformation securityFirewall (computing)System callSoftware testingProcess (computing)Data managementService (economics)CodeProcedural programmingMemory cardSession Initiation ProtocolPublic key certificateState of matterContext awarenessCodeToken ringNumberDialectComputer animation
1 (number)HypermediaComputer configurationCASE <Informatik>Session Initiation ProtocolProcess capability indexDifferent (Kate Ryan album)QuicksortComputer animation
Program flowchart
Transcript: English(auto-generated)
Ok, my name is Nuno, I've been around VoIP and RTC for the last, I think, 15 years, the last 10 more involved with open source, and, well, right now I'm working at TalkDesk,
which is a contact center, cloud driven company, and we are starting adopting more and more open source technology into the company, and, well, that's what also drives me. So my talk will be about secure pavements over VoIP calls in the cloud, it's something
that all contact centers probably need, and in order to do this we have to follow some rules and specifications, and let's dive into that. Ok, so I'll be telling you what PCI DSS is, what was the existing problem, and what was
the solution for our own implementation, the actual architecture of the solution, and our DSS, Payment Card Industry Data Security Standard, well, it's a standard
that was put up together by a bunch of companies like American Express, Discover,
MasterCard, Visa, etc. So they created a bunch of mandatory rules for the industry, and this is called the PCI Data Security Standard, and, well, in PCI lingo all business that process credit cards are referred as merchants, which is our case at TalkDesk,
and whenever we are big or small we have to follow these rules for credit card security. And basically there are very different levels for the merchants, the ones that process like
6 million transactions, whatever, so they are level 1, usually contact centers if they're not that big they end up in the levels 3 or 4.
Again, SAQs, so SAQs are self-assessment, questionary levels, so we have to kind of answer some questions to see where we fit, and basically since we are an electronic processing company we fit in under SAQA, and so no face-to-face merchants, everything
is done with e-commerce or telephone, so this is where we are at. So, the existing problem and solution, why we did something different.
So in order to do this kind of payments we were using some proprietary equipment like SPCs, etc., and everything in the end sometimes had some failures, there's the usage
of DTMFs on this a lot, at least for typing the credit card number we need to use DTMFs, but besides the credit card numbers itself we have also to use DTMFs to tell the partner that the actual partner, I will be speaking more about it later, the partner basically
needs to know when you want to have your channel secure for the actual customer be able to start typing the credit card information.
That was being done by the usage of PIN on the agent side, so the agent would basically use his dialer in the screen most of the times to type a PIN in order to engage with the PCI partner and if all went well the actual customer would be hearing a voice
telling him the call is now in a secure situation, you can follow up like typing the credit card. Most of the times this works but there are a lot of times that the DTMFs are not well recognized, sometimes the SBC failed completely because there was a need, I will be on that
later on again, but there was a need of transcoding the actual DTMF from the RTP to SIP infos in order to tell the partner about the actual DTMF, the number, and well
we also have a very hard time integrating the SBC world, the proprietary world with modern APIs in order to have more fluent scenarios.
The alternative, the solution, basically we decided to use Camellio and RTP engine for the new solution, it lets us have more easy to adapt and evolve, it's easy to integrate
with modern APIs, everything can be done with SIP and we will get into the actual architecture next. So about architecture, the PCI environment itself needs to be contained from whatever
you have in your void for normal calls, it has to be separate and contained, so in order to actually use payments, so the phone number that the customer uses to call and do a payment basically goes through a contained environment, in our case we are all in AWS,
so we have basically a separate account just for this, and for our new implementation we did everything with infrastructure as code and by doing CI CD we were able to deploy
without the need of like logging in to a machine or having SSH access or that kind of stuff. So about the actual architecture for this, so we have the actual carrier and we have
this CPAZ which are asterisk, can be cloud, a cloud provider like Twilio or Nexpo or single wire or whatever, and this secure router is what we call this new solution that
we developed, it's basically several possible instances of Camellio and RTP engine and there's in the top the PCI partner, this is the actual partner that processes the payments so we don't process and we don't touch the actual credit card data, and the way this
works is basically the call comes in from the carrier side, if it's an inbound one and it goes through like this, this is the media for the normal call without being still under the secure channel for payments, so the call comes in, it ends up in the
agent on this side and whenever the agent wants to, in this case this blue arrow here, it goes always through the PCI partner, the PCI partner injects a new header in
the SIP with a token, so the token comes back down here and it is extracted and it is sent to a smaller helper microservice that we have, this microserver basically then uses an internal API to tell the CPaaS and that the actual call that is coming in
as that token for starting the securization process in case of a payment needs to be done. So the signaling goes always through the PCI partner, the media goes from the carrier
to the CPaaS side without leaving, and whenever the agent on the CPaaS wants to start the secure process for starting a payment, basically he uses the token that was passed into his UI and that triggers, reinvites from the PCI partner down to our secure routers
and basically the media starts flowing through them for the actual time of the payment processing, so this is basically how this works. So this yellow square here means that we are
under a closed environment just for PCI, we have to follow that because rules imply that. And basically some snippets on the infrastructure as code for this, so we are using a bunch
of Terraform with Ansible in order to deploy everything automatically, sorry it doesn't read too much here, sorry about that. But here we are telling, in this part it's the dispatcher
that we are populating for Camellio, there's also some information about how the process of Camellio started, the certifies that are used for TLS, a lot of description for the services.
Would you put the previous one just a moment? Yeah, the one before, okay.
Here it's a small snippet of the Camellio config file itself, so in this case, sorry about that it's unreadable, but it's where the actual engage with RTP agent was happening, so we have a bunch of ciphers here that need to be used, but by using this and with
containerization, so the actual Camellio is put inside the container, the container is then launched, mapping an external volume with some defaults, and that way we don't need basically to
human touch this deployment. Okay, another important part, we rely a lot on DNS, so we use NAPTR records with SRVs for
basically describe where our instances are, so the PCI partner uses DNS to speak to us, the carrier the same thing, the CPA is the same thing, and by doing this and without need to be
stateful for anything, we can basically launch the number of instances that we want. Since we are using AWS and we need basically this kind of deploys to happen in several regions of the world, we also do that very easily by using this approach, and as I say here,
R coding is almost not a great thing, but in this case, as I say around here, it gives the rigidity that we need to fulfill the requirements and the standards, and it proved to work well.
So, how it actually works, this is a screenshot of the UI that the agent sees, so basically these are what we call context cards for the agent, one of the context cards gives the PCI token that
comes in the SIP and then it's extracted in Camellio and sent to our internal API for the contact center layer, and it appears there, so whenever the agent needs to start the payment, he just needs to press a button that will use that token
and the call will be in what is known as a secure state for payment. Okay, wrapping up.
So, something about the certification process and the audit, every entity that wants to be processing payments needs to go through this every year, the certification needs to be renewed every year, and the one that we did more recently was last November, and the year before
still was on the old proprietary stuff, there were several small issues that kept open from last year to this year, and by using the new implementation, we basically passed everything,
the solution is put under test for pen tests, it's something that is in the runbook of the audit, so everything passed, I didn't mention, but the actual infrastructure
s code also configures the firewalls in AWS, so we just have the ports that we need to work with open, and we have also ACLs for the PCI partners that we are using to
process payments, the carriers, the same thing, so that's the way we did it, and in the end, basically the audit identified some strengths for this, so they told there was excellent management and procedures in this, we adopted a risk treatment approach,
and we always used certified service providers for carriers and for the partners that do the payments, they also need to be PCI certified. About the carriers, this architecture basically
lets you use any carrier you want, but you have to kind of decide if you really trust some of the carriers that you put into this, because basically if you integrate this with a PBX or so from a client, let's say, it can always intercept the call on its side, and that could not be good,
so yeah, that was it, and that's what I add, thank you. Okay, I guess you, any questions?
There's one over there. So do you find that your solution's been built around one particular
provider, or is the solution that you've built sort of, you bet that it's really worked with other ones as well, did they follow the same paradigm? Yeah, most, there's small differences when you basically switch a PCI partner that processes the payment, right? There are small differences between them, but we basically worked with three, four partners for this, and
they most use SIP. If they use only SIP, that's the best option. The one that I presented here, it's the most complex one because it involves re-invite, sending media to them during the actual
payment process, but it will depend, so sometimes it's more direct and easy. The case that I spoke about was the most complex one that involved media redirects and that kind of stuff.
Any partner? Not really, I guess all of them, if you, I really don't want to say names here, but if you basically look for the most relevant ones in the internet, they are the ones that will work under this, fine. Thank you. Yep, thanks.