Okay, my name is Nuno, I've been around VoIP and RTC for the last, I think, 15 years.
The last 10 were more involved with open source and, well, right now I'm working at Talk Desk,
which is a contact center cloud-driven company and we are 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.
Okay, 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
how to do it.
Yes, 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, BasterCard, Visa, etc.
So they created a bunch of mandatory rules for the industry, this is called the PCI data
security standard and, well, in PCI, all business that process credit cards are referred as
merchants, which is our case at Talk Desk 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 six million transactions, whatever, so they
are level one, usually contact centers, if they're not that big they end up in the levels
three or four, 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 like to tell the partner that the
actual partner 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 to be able to start
typing the credit card information, that was being done by the usage of a PIN on the Asian
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, in order 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 number and well we also had 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 Camille 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 like 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 into 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 SIPAS, it's our asterisk, it can be cloud, a cloud provider like Twilio or Neximo
or SignalWire 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
is 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 weather in the SIP with a token, so the token comes
back down here and it's extracted and is sent to a smaller helper microservice that we have,
this microserver basically then uses an internal API to tell the C pass and the actual call
that is coming in as that token for starting the secureization 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 C pass side without leaving and whenever the agent on the C pass wants to start the
secure process for starting a payment, basically he uses the token that was passed into his
UI and that triggers, re-invites 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, but here we are telling
for in this part it's the dispatcher that we are populating for Camelio, there's some
also some information about how the process of Camelio is started, the certifiers that
are used for TLS, a lot of description for the services, so yeah, the one before, okay.
Here it's a small snippet of the Camelio config file itself, so in this case, sorry about
it, 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 Camelio 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 touch, 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 CPAS 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, art 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 Camellia and sent to our internal API for the contact center layer and it appears there,
so whenever the agent needs to start the payment, it 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.
The one that we did more recently was last November and the year before it 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 the 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 as 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 thought 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 PBX or so from a client, let's say, you can
always intercept a call on his side and that could not be good, so yeah, that was it and
that's what I add, thank you. Okay, I guess any questions? There's one over there.
Yeah, there's small differences when you basically switch a PCI partner that processes
the payments, right? There are small differences between them, but we basically worked with
three, four partners for this and they must 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
reinvites 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 involves media redirects and that kind of stuff. Can you recommend any specifically?
Any partner? Not really. I really don't want to say names here, but if you basically look
for the most relevant ones in the Internet, they're the ones that will work under this.