Topic: Third-party compliance - Norex

stuckwarmersMobile - Wireless

Dec 14, 2013 (7 years and 10 months ago)





NOREX members discuss PCI (Payment Card Industry) issues during this October,
2011 WebForum. Topics discussed include third
party vendors, tokenization, cyber
insurance, two
factor authentication, security, training and certification. NOREX retains
the or
iginal, unedited version in order to facilitate future networking.

Contact your
NOREX Member Care Team for assistance.

*Please note that this is a transcript of an audio conference and it may contain misspellings and grammatical errors.

The names of
participants have been abbreviated, and their organizations have been deleted from this transcript.

Strategy for protecting data



party vendors for PCI



ber insurance



party compliance



Full PCI compliance



factor authentication



A Certification and training



Remote support



Contingency plans



Electronic wallet



PCI penetr
ation testing and internal audit testing



Recording phone calls



Who owns PCI compliance




NOREX WebForum

PCI Issues

October 18, 2011

Topic: PCI definition and standards


Hello, folks. Let’s go ahead and get started with about 25 on right now, and
we are still growing. Update to PCI definition and standards. I thought we could start
there, just to see if someone could possibly speak up with a definition, anything that is
ew, or an update to the Payment Card Industry, that could just kind of define where it
is at. Could anyone do that? Does anybody need a better definition of PCI right now?

Chuck G.
Actually, the standard, the 2.0 version, that everyone needs to follow, i
s out
since last October. What they have done in the interim, in the past year, they have put
out some guidelines on
wireless, t
okenization, mobile application FAQs, and point
point encryption. Again, they are guidelines. Some of the newer documents
have come
out in the past 12 months.


Thank you. Related to those newer documents, does anyone have anything
more to share on these newer updates and new requirements for wireless, etc.? Well, if
anyone would like to share something here, we wou
ld certainly be happy to have you
speak up. Let’s do a quick poll to see compliance levels of the group on. Basically, level
one through level four if you are required to be compliant for PCI. Go ahead and take
this poll if you know what your level is, and

it gives us an idea of our audience today.
We have got one level one at this time, several at level two and growing, level three is
growing. I would say two is the highest at this time. Any comments while we take the
poll, in general on PCI definition, up
dates, best practices? We will close the poll in just a
moment. We have one person at level one, six at level two, or 33% taking the poll, three
at level three, and the poll is still growing.



are level two.


Who is level one on today?


Judy D.
We are level one.


We do have two at level one now. Anyone else want to speak up? OK, I am
going to close that poll with 9.5% level one, 28.6% level two, 19% level three, 27% level
four. It is still growing
just a little bit, but we will go ahead and close and get into our
conversation. Dave, you have our first topic. You are interested in understanding what
effect PCI has on information protection strategy.

Topic: Strategy for protecting data

ve W.
m what I understand, that is kind of a very general question. I am just
doing some initial investigation, trying to get the 50,000 foot view in how to create a
strategy to go about protecting our data information, not only PCI, but you know, any
other kind

of information that would need to be protected as well.


Thank you, Dave. What is your level?

Dave W.:
I am not sure. I was one of the ones who answered “unknown.”


OK, thank you. In general, hopefully you will get some good information
from this call, and we do have some other great transcripts. I will mention, Norview 859
was earlier this year, in May, and we had a real good PCI compliance discussion at that
I will link to this transcript, as well. Comments for Dave, please?

NOREX members who are required to be in compliance with Payment Card
Industry Data Security Standards
discuss tools and processes during this May 2011
WebForum. 20 Pages (NV859)

Brian M.
We were required to get PCI compliant back in 2006 for various reasons.
of the mistakes that we made in hindsight


we did a complete rollout of an
information security program that was airport
We saw this as an opportunity, with
all the folks on PCI forced to go ahead and clean house, if you will, with regard to the
rest of information technologies.
One of the m
istakes tha
t we made was;

we did try to
roll up the entirety of technologies into our PCI compliance.
So, I guess what I mean is,
we made our policies and standards airport
wide, instead of just applying to the PCI
environment. We did have a segregated PCI

environment, and we still do, of course, but
everything we applied to the PCI environment, we tried to make it airport
wide. What we
found is, trying to communicate that level of standard, which was a fairly drastic change
from where we had been, was not
very successful in getting that level of control rolled
out to the rest of the organization.


Brian, thank you very much. Hearing the gotchas is always helpful. Anyone


Topic: Third
party vendors for PCI

Peter P
Our strategy changed
from managing a lot of our transactions, storing our
transactions, and trying to protect those to simply giving them to someone else,
changing vendors and changing platforms so that we kept nothing. Back in 2006 as
well, when we had to get PCI compliant, w
e offloaded everything to third parties to
secure vault systems, for payment processing, so that we did not store anything
anymore. It makes things a lot more difficult when you are dealing with customers who
refund or need information about their transact
ions, but it takes a good chunk of the PCI
standards out of your requirement by offloading that on a third


Pete, did you share who your third
party is?

Peter P.:
We use Merchant Link as our intermediary between our credit card
sale processing systems and our bank.


Thank you. You are pretty happy with them?

Peter P.:
Yes, much improved over our previous

and they allow us to store
nothing other than basically a transaction key for the information, no m
ore card data.
Like I said, it makes it difficult to do certain things that we used to be able to do for the
customer, but overall, it means that large chunks of the PCI standard are not, I guess,
my responsibility to comply with. They are Merchant Link’s


Thank you very much, Pete. I moved us over to Carl’s topic, because that is
right on with what you are looking for. Correct, Carl?

rl G.
Yes, it is. Thanks, Marcey. Pete, that is good information.

That is what we are


as well, to kind of reduce our internal PCI requirements, having an external
party do the actual credit card processing. It is similar to almost like a PayPal
model, where somebody went and signed a process to credit

they are transferred

an external website that handles everything. We are looking at CyberSource, which
we would use to our merchant bank, which is Wells Fargo. I was just looking for other
people’s experiences and how that may have worked for them, both operationally and
as a

means of reducing PCI.

Thanks, Carl. Anyone else with experiences with a third
party, who they are
using, and their satisfaction? Everyone else on,
are you

doing this all on your own, no
third party involved? Is that what we are hearing, or n
ot hearing?

n B.
We are not using anyone right now. We have been looking at Chase
Paymentech, and I was hoping to see if anyone had had some experience with them.
We have an issue with, you know, global reach, international commerce. So, we were
ng for them, because they would handle the most. I think we looked at First Data,
and First Data did not handle those multi
currencies. The other thing that we were
looking at, for just a particular website we dabbled in, was

BigCommerce has a

section that they do a lot with different vendors, and you can pick
who you want to process your credit card information. They have a whole processing
section there too. So, I do not have a lot of information on that. We have used that, but
for the bulk o
f our information, we are looking at Chase Paymentech. It is actually
Chase Bank, but their process or the branding name of the credit card processing used,
and I do not think anyone has mentioned it, would be Tokenization. So, we are not just
completely o
utsourcing it, you know, we would get a token back. The idea would be to
integrate that with our Legacy system, so that it is a call out to Chase Paymentech. Also
for our online system, and again, we have not gotten this far, but it would be using our
ne systems to an API, so that when someone is putting in their credit card
information, it just goes straight out. It does not even come in. Then, we are given a
token. But, you know, there are some changes that have to go along with that. We
would actuall
y have to set the customer up


Great, Jean, thank you. Others?

Peter P.:
Obviously, we use Merchant Link, and that has worked out well for us. They
happen to be one of the vendors that our point
sale system was certified with. I
for those of you who are trying to use it, it is a lot of middleware software, with people
that sit in the middle, like Merchant Link, ProtoBase, Southern DataComm, Monetra, a
number of other software packa
ges. They are great because the

APIs, they
have ways
to integrate to your different systems, websites or point
sales or whatever you are
doing. Then, they essentially connect to any number of banks, which can make it really
easy to integrate.
I did not like Southern DataComm or the ProtoBase pac
kage when
we had it.
But, I did like, and we still use, Monetra, and it is from a company called Main
Street Softworks. They have a very good API, and they also work with any number of
different, like Chase Paymentech, First Data,
BA Merchant Services, and

, all
those other acquirers or banks. The
ir plat
form runs on anything, U
, Linux, I believe
they even

an OS2 version, Windows. So, their software is really good. I really liked
it. We customized it quite a bit. It was great. So, if anyone
is looking for an application
they can work with and customize with their own websites or whatever, I would take a
look at Monetra.

I think the company’s website is


Wonderful, thanks for all that insight. We appreciate
it. Anyone else?

Carl G.:
One of the things that I have assumed with
okenization is that, even though
the actual processing of the credit card is off your systems, if you are entering the data,
even though you are not

cardholder data and sending
it off via APIs, you still
have more PCI requirements around the whole security of your network, because the
information is passing through your systems. Can anyone comment on that?

Issam H.
We had a similar circumstance, and we are now in the position
of having to
become PCI compliant. We used U.S. Bank, and initially we were using U.S. Bank to
avoid having to become PCI compliant. But, because we have agents processing
transactions on the U.S. Bank site, those credit card numbers are passing through ou

employees to the U.S. Bank Site, and we now need to become PCI compliant. So, our
initial approach to it turns out to not give us what we were hoping.


When you learn something like that, do they give you a certain amount of
time to become com

Issam H.:
You know, I am not very familiar with the actual process of becoming
compliant. I know that we do have a deadline. I am not sure when that is, but it is
coming soon, and we have been doing audits against our system and remedying any
es that have been identified.


Thank you. Anyone else to comment on that?

Jean B.:
I guess my question with that would be, depending on their API, I mean, is the
credit card information actually coming into your system? Or, is it just being sen
t directly
to the places, the Tokenization places? Or, at the very worse, I cannot even see it going
to the web server. I cannot even see that, because you would not store it there. But,
where were you not PCI compliant? I am sorry, I guess another part of

that would be, at
least it would greatly reduce your scope, if you are not bringing it into your internal

Issam H.:
As far as my understanding, the crux of the issue for us was that our agents,
even though they are not sitting on our system, are

handling these numbers on behalf of
the customers and passing it directly on to the third
party. So, the data is not
necessarily being stored anywhere on our network, but it is just the fact that our agents,
our associates, are handling those numbers.

an B.:
I did not think that that was an issue. I mean, you can get to handling the
numbers, so they would see the full number? If somebody had to take the information


Thank you. Carl, how are we doing?

Carl G.:
Good. To kind of elabora
te on what we are hoping to do with our third
party, we
are a level four, so we do not have as many transactions, so it might apply more to us,
but as our customer service representatives take a customer order, and a customer
wants to pay by credit card, t
hey can send them to a URL that is right on the
CyberSource website, and the customer enters their information there. So, our people
never get the number, never enter the number, and it never crosses our network. So,
that was the concept there.

Topic: Cyb
er insurance


Thanks, Carl. Mike just chatted, does anyone have cyber insurance? Mike,
can you elaborate a little?


Mike T.
We are in the process of looking for cyber insurance, as we do a lot of ticket
transactions via the web. I was curious i
f anyone else has pursued cyber insurance and
can give us a little insight on their experience with it.

Can anyone address cyber insurance? Is it a pretty new concept, Mike?

Mike T.:
It has been about ten years.


OK. Has anyone looked at this, given this some consideration?

Brian M.:
We actually looked at it. We worked with our risk management group to get
some insurers in here.
After going around a bit
this is why I did not speak of it initially
what o
ur insur
ers opted to do is;

they are providing us a full business impact analysis for
the airport and for information systems and operational systems beyond that.
That grew
out of our inquiry about cyber insurance, and they came back and said, well, that is not
ally what we offer, but here is what we will do. We will perform this business impact
analysis for you, and then we can see if there is something they can do to adjust our
premium space on what they find and what our response is. But, we did not actually g
to the point of getting cyber insurance.


Thanks, Brian. Let’s go to Luke. Luke, in the chat, has a few comments
related to compliance and our last question. I do not know if that would be the third
party one, Luke, or are you talking about
the general one from Dave?

Topic: Third
party compliance

Luke M.
Yes, just a couple comments regarding third
parties and compliance. We are
not compliant now, and it is for two reasons. I think the first is, most of the time when
somebody wants to pay w
ith a credit card, they call in and they give the credit card
information to somebody, and they enter it i
nto the virtual terminal.

So, even though we
are processing it through a third
party, our fol
ks are actually still

aware of the credit
card, and they
know the number and they enter it in. So, it is not that you are not
compliant if you do that. It is

you have to jump through a lot more hoops to show
that you are compliant. Whereas, if you can say, OK, everybody who pays us with a
credit card does
it through this secure form hosted by a third
party, and so we truly
never see their credit card information, if you can get all of your transactions going that
way, then PCI compliance with a third
party truly is pretty easy. We have gone so far as,
we ha
ve various payment forms, but developing just a basic payment form where
client can go there, enter a
n invoice number, amount they want to pay, boom, as
opposed to calling our office or mailing something in. I think that is the way, as I see it,
for th
e most straightforward compliance.
The second hiccup we have is

we have a
handful of clients who we actually charge a recurring payment.
So, they give us a credit
card, and they say, charge this credit card every three months for X amount of dollars.

that becomes a problem too, because if you store that credit card information,
there again, understandably that makes PCI compliance much, much more difficult. You
have to jump through a lot of hoops to show that you are securing that information. One

ng I will throw out there is that third
party online gateway is Authorize.Net. It is really
common, and it is really full
A lot of resellers, like Wells Fa
rgo resells it, Chase
resells it
, they have a feature called, I believe, Sim

(?), where they will actually store a
client’s credit card and allow you to charge it periodically.
They will actually keep it for
you. So, we have not implemented it yet, but we are thinking that will give us the ability

do these recurring payments but

still say, hey, the third
party has all the credit card
information, so our path to PCI compliance is pretty straightforward. I hope that is


Excellent, Luke. Authorize.Net.

Luke M.:

use Wells Fargo, and they are a reseller.
I know Chase is. I mean,
there are a lot of resellers of it. Again, as a third
party online gateway framework, I
would recommend it.


Luke, can you share what you organization does, and what level of PCI you

Topic: Full PCI compliance

e M.:
You bet. We are a financial services,

primarily accounting and audit

about 300 people throughout the state of Montana. I actually work remotely off in Texas.
So, that is who we are and what we do. I guess, what level of PCI compliance, we

definitely be level four. We are not compliant, just because we are still working
out our processes so that we can make sure we do not ever see that credit card
information. I will say, interestingly, we are not compliant, and the result of that is that
e are charged a $25 fee per month from Wells Fargo. We want to be compliant
because it is the right thing to do, and we are confident now that we are securing our
client’s data. But I will say that, it is unclear the true consequence of being non
. To be honest, we have kind of gotten some pushes from our bank to say, oh,
well, just go through the survey one more time, and in other words, just answer what
you need to answer to be compliant. So, I do not know. I probably should not have said


That is OK. We are going to give everybody a chance to share, Luke. We
are fully PCI compliant, is the poll, and then you can strongly agree, all the way to
strongly disagree. Many are taking that poll right now, with 40+ on our discussion today
Do others want to talk about being fully PCI compliant?

Brian M.:
I am a member of a LinkedIn community with about 20 or 30 airports and port
authorities around the nation, and over the last two years, we have talked a little bit
about being compliant.
One interesting thing I ran into, similar to what the previous
gentleman just mentioned, is that a number of organizations in that group opted not to
become PCI compliant. These were the security

who wanted to be
compliant, and they were ask
ing organizations like mine how we became, and I said,
well, the threat of significant fines really helped. We were looking at fines into the seven

and eight digit figures. These guys were telling us that they were being fined, but their
fines were in the
six figure area.

For a number of those organizations they opted instead
to pay the fine because for them, one of the airports I believe was facing about $120
150,000 fine. To them that was far cheaper than hiring a security team.


Thank you, g
reat comment. We a
ppreciate it Brian. We have
a comment
from Tad. He is sharing that he would like to get Luke’s contact information as he is
currently developing against
We will make sure and have that happen

Luke, you are good with
that too?

Luke M.:
Yes, sure.


We had 27 take this poll. Our results; 2 people or 11% said strongly agree
that you are fully compliant. Agree 18% or five of you. Neutral was four. Disagree for
nine people or 32% taking the poll. Strongly disagree was 10% or three
Then n
ot applicable was four on the event. We have now grown to about 29 on that poll.
Both of our polls of course will be available in the transcript that you will receive later.
Thanks for the results.

Chuck G.:
A question came up
. I believe it was Brian

that was speaking regarding that
LinkedIn group. I am curious to understand what those operations that chose to pay the
fine as opposed to implement protective measures when one of the card brands comes
back and says; enough is enough. We are going to rem
ove your ability to process our
card brand. Do you think that would change their

Brian M.:
Yes in fact the mentality of the security professionals that I was working with
were hoping for. The light in which the question and the discussion came up

was we
became PCI compliant in 200
6 and I believe we were the first international airport to be
PCI compliant. These other airports were trying to figure out what did it take for your
airport to drive that home. In our case unfortunately it was much more
significant fines
than what anyone else in that organization was facing. So a couple of the
other airports,
not speaking
their names since they are not here, they did eventually see an escalation
of those fees but what seemed to be the common thread across

all of them was; pay
the fee this year. Let’s pursue compliance but at a slow pace and at a rather
inexpensive pace. The things that you are doing for compliance aren’t typically too far

above and beyond what any good security professional would recommend
. The only
part that is a little bit over the top, that is not really the right phrase, is the fact that most
organizations are going to completely separate out their PCI environment, their entire
cardholder environment. So these organizations were deployi
ng various tools and
scanning systems, patch management and stuff like that, documenting their processes
with their existing staff and paying the fine. I believe over time most of them did end up

PCI compliance but they weren’t willing to do it th
at first or the second year
based on the size of the fine compared to what their investment would have to be.

Chuck G.:
Right and I totally agree with your comment that becoming PCI compliant,
we did it in 2008, it definitely enhanced our whole security architecture. There was a
twofold benefit. One, we became PCI and

it also enhanced our security in our

Brian M.:
We felt the same thing.
In fact we are one

of the strongly agrees on the PCI
compliance. My very first comment, talking

about our mistake about trying to roll it out to
the entire airport, what we ended up doing was we backed off of that.
We foc
used on
our PCI environment once we realized that mistake and we are now back to having just
succeeded in rolling everything back out to the entire set of technology systems at the
airport. That has been a process.

Topic: Two
factor authentication


hank you.
I am going to move on

to Judy
’s topic
. How are other
companies addressing requirement 8.3, the two
factor authentication? Do you provide it
for all remote access? What are you doing at your

now Judy

Judy D.:
We are
forcing two
factor authentication

for any case where there is direct
access to

a server. So anybody who is administering a server, needs to access a
database directly, anything like that they have to use two
factor authentication.


OK, other’s

solutions and plans? Does anyone provide it for all remote

Mike T

We are a


and we have about 600 users that can
touch our ticketing system to process credit cards. We are rolling it out to all of those
individuals as well as all of our internal staff even if they do not touch the ticketing
system so it would be engineers or stag
e hands and electricians. Anyone that is on our
network is getting a two
factor token in addition to everyone that touches our ticketing
system. So that is about 600 users in total.


Thank you.

Judy D.:
Can I just a quick question? Have

you s
egregated your card data at all?

Mike T.:



Judy D.:
So even with the segregation you are still doing two
factor for everyone.

Mike T.:


Judy D.:
That is interesting. Thank you.

Dave G

We also segmented our cardholder data environment and forced two
authentication for anybody getting into cardholder data environment. I also took the PCI
ISA training this year and that was discussed. Basically there must be two
on for any access to the cardholder environment

without any exceptions.

Judy D.:

but where we are getting confusion is we are having people say that
you need two
factor even if it is not in the card data environment.

Dave G.:
If it is not in the

cardholder data environment and the cardholder data
environment is segmented off

then it is not in scope.

Judy D.:
That is what we were trying to say. That is why I was asking the question of
the gentleman from Pittsburgh.

Chuck G.:
Judy, there is act
ually, if you have ever had the opportunity to go right to the
PCI security website there is actually a document library and there is a really good
document called “Understanding the Intent of the Requirements,” for version 2.0. That
should provide some pr
etty good insight.

Judy D.:
Yes and my take from that is just what Dave said; they are talking about the
card data environment.

Chuck G.:
Honestly that is what I picked up. I also went and got ISA
(Information &
Security Assurance)
certification this yea
r. That is what I picked up. The primary focus is
cardholder data environment.

Dave G.:
I would highly recommend the ISA certification and training for anyone who
deals with PCI. Basically it is the same training that the auditors have and now you can
k their language and you can ask these kinds of questions at the training.

Topic: ISA Certification

and training


A little more information on this training?

Dave G.:
It is by the PCI C
ouncil. It is the same training that the QSAs
Security Assessor)
get except that it is only for people within an


is for people in the risk group so they can provide their own audit so the leve

one and

two merchants. However the class I took had a lot of IT pe
ople in it who just
wanted to have the same training and talk the same language as the QSAs.


Judy D.:
I am glad to hear a couple of the people on the call have taken


because I was wondering the same thing. What has happened is our QSA is saying we
are fine and our internal audit who has no PCI training whatsoever is second guessing
our QSA’s findings.

Dave G.:
I think the two of you need to go to training.


We did get some links to that

too. Thanks to Noah and Chuck
here in the chat.

and then you can get into


Chuck, you mentioned
has document library and training offered?

Chuck G.:
Right and the other thing to conside
r is level two merchants. Now I know
MasterCard pushed the data back but if you are a level two merchant and you still want
to self
assess on an annual basis you have to have an ISA on your staff do that or you
can’t self
assess. Now MasterCard was set to
have that come effective as of June 30th
2012. I believe they pushed it back another year.


It was current yesterday.

Chuck G.:
But that was a requirement of

that if you want to level two you
can still

but you have to have an

ISA and that is the person that has to do
the questionnaire.


Great information.

Dave G.:
What is interesting is the ISA cannot be part of the IT department if they will
be doing the assessment. They need to be part of the risk group, howeve
r the class that
I was in the majority of people were IT people who just needed to understand fully PCI
and have the same training that a risk or a QSA would have.

Chuck G.:
Interesting, I questioned that to the council when I read that. They said that
asically if you can distance yourself, because I am actually IT security and they
permitted me to get the ISA. As long as it is basically a separation of duties which that is
how we operate.

Topic: Remote support


I am going to move us along
then folks to Ryan’s topic. How do any of you
handle remote support of the payment apps? Do you require physical onsite support?
Do you support VPNing by the vendor and if so what restrictions do you put on it?

Brian M.:
We go through Chase Payment Tech b
ut we have an onsite applications

we work with; ACS. They have had a significant number of issues with their
systems here because of the system that we are running. It is a one off from their off the
shelf product. When we have support issues

what I

am c
rious is

if any other people

are in a situation where in their cardholder environment they have to have the vendor
doing remote support. We do have two

for any access into our
cardholder environment. Sometimes we will get push
back form the vendor on that which
just blows me away that they would push back on that. So we have got to the point
where we are just demanding that they come onsite.
We are wondering if anyone else is
running into support issues for their cardholder envi
ronments that

VPNing or
bringing people onsite.

Peter P.:
Here there are a lot of Applebee’s and Pizza Hut

so almost all of
our tech support for point of sale had issues

which is obviously part
of the credit card
environment, is don
e by third
parties. Basically those third
parties maintain a secure
environment and we require that they submit to us on a yearly basis that they maintain a
secure environment. It is easier for them because essentially they are point of sale
software vendo
rs so they have PCI requirements to begin with. What we do for them to
come in is we actually pin up permanent tunnels. One side is a tunnel into our data
center that is essentially firewalled and has IDS and IPS and everything else in case.
Even though th
ey are certified o
r certified PCI compliant we

require them to tell us that
every year in writing. We still don’t trust them. So we protect ourselves from them but
that gives them access to our environment and then the other side is actually similar but

is actually a larger MPLS network that the vendor is able to access our network
environment. In fact is it their environment to be honest with you. Since it is YUM
Brands, the largest restaurant management company in the world they have very strict
PCI re
quirements. So it has to go back on the vendor. You have

have support. You
have to let them in. a vendor has to be PCI compliant if you are going
to let them in your
network and you still don’t trust them. We still don’t trust them.

Brian M.:
So this may not apply as much to your environment. We actually do have a
site to site with ACS as well. This is a separate group that

have access to


site. One of the things that they have been requesting is they wanted one generic
shared toke
n that they can give to anyone in their support group. That violates one of

the rules of PCI; having a single identity.

Peter P.:

We don’t allow that even though the connection is in there. They actually have

one of the ways that you can manage that is
for remote support any remote access
to the machine essentially has to be permitted by the end user on the other end. So
instead o
f saying; do you want a generic token that allows you to connect to our
machines for support at any time, you will generate a unique session for this one
instance and that end user will have to agree to allow remote support and then that is
how any session

each user is unique. Then we actually ask our vendors to provide us
transcripts and logs of each transaction to ensure that those transactions were clean
because what happens is our end users tend to walk away when remote support
begins. So we receive tra
ctions of everything that they do; what they access, what
they click on, what folders they go into, what

they open, what commands
they run. I can

t say that we review those on a regular

it is a lot of stuff.

Brian M.:
that is a goo
d thing to show an auditor.


Peter P.:
Right, it is a good thing to show an auditor that we

did. So I believe they use
MeIn Rescue and they are able to provide those transcripts of each session or our
environment is configured to only allow them to requ
est remote support and the end
user has to approve it. Our policies are that unless you are specifically instructed by our
internal IT department or you have requested support and are on the phone with this
person you don’t say yes to remote access.

It ha
s managed to get us through our PCI.

Topic: Contingency plans


All right, anyone else? Dave asks; curious if folks have contingency plans
in case their third
party service falls out of compliance.

Brian M.:
We didn’t opt for a contingency party in case they fell out of compliance
because all

the experiences that we have had both with us and the vendor lead us to

that there will be a grace period while we get back into compliance or while the

gets back into compliance. So we

felt the need to have a contingency
plan in case ACS or Chase looses their compliance. I don’t see a hammer coming down
and turning it off overnight and surprising me.

Chuck G.:
No, you are correct. I think there
is like a 30, a 60 and I think a 90 day is a
red flag and after that then they remove their ability, like an approve payment

Topic: Electronic wallet


Thank you. I am going to move us on folks. Clark asks; electronic wallet
payment at the point of sale. This would include available technologies and apps.
Clark, are you on? Anyone want to take this one on electronic wallet for payment at the
point of sale? What does that mean? Can anyone give a description here? Payment
over t
he web or what is that? No one has a definition for it?

Dave W.:
I am just going to take a wild guess. For example Google has their wallet
application that came out recently. So basically you ca
n install it on your phone, an
ndroid phone for example, an
d I forget the name of the technology but it is a near field
technology or something like that. Basically you take your phone and you tap it to the
point of sale device or something to that effect and the payment occurs. It is just a wild
guess at what he
might be referring to.


We did get a little bit more explanation of the electronic wallet from Chuck.
Can be used to look at approved payment applications and when they were validated or
when the next validation is due. Is that what you were s
haring Chuck?

Chuck G.:

that is actually a Visa site where you can go in there and how it actually
links back into the PCI site. You can look, if you are looking for an approved payment
application vendor you can go in there to see what is approved, when it was approved,
when th
eir next validation is due and it also gives you an opportunity to see which ones

might be in that 30 day window where it is still permissible to use them but they haven’t
revalidated those that are in the 60 and those that basically are being removed from

list. So it is a good reference list.


Chuck, thank you very much. I am sorry I took that the wrong way. I think
one of our team did give us a little description; an encrypted storage medium holding
credit card and other financial informat
ion that could be used to complete an electronic
transaction without reentering the stored data at the time of the transaction. That might
have been a Google explanation
. Thank you Leila from the NOREX

team on the
electronic wallet.

PCI penetration

testing and internal audit testing


We appreciate it. Thank you. We will move on to Ted. What vendors do
people use for PCI pen testing and internal audit testing? Are you happy with
? A
little more input Ted?

Ted R.:
Yes, we are just kind of fleshing out our PCI compliance and we have a vendor
that we use but they are not part of that. We are looking at some other vendors that may
be compliant for PCI penetration testing and internal audit testing. So I just wanted to
know if somebody had any names they wanted to throw out as somebody that they

been extremely happy with and would recommend.

Mike T.:

We are currently in negotiations with Dell SecureWorks for our external
penetration testing and for our internal
audit testing we are using QualysGuard. We
have an internal appliance so we can scan our internal devices as well as doing an
external scan. External scans can go right to our merchant to find that we are compliant.

Ted R.:
That is funny. I have two meeti
ngs today with them.

Mike T.:


Ted R.:

Mike T.:

We have been reviewing with them and a couple of other vendors and we feel
that they are going to give us the best product.

Ted R.:
Awesome, thanks.

Chuck G.:
We also use Qualys for int
ernal and external. We are very pleased and
satisfied with that and for pen testing we use CoreBTS. Again we are very satisfied with

Dave G.:
We also use QualysGuard and Qualys. The nice thing about their appliance,
you can run the internal non
icial test and make sure it is clean. So I run the Qualys
external PCI

every week. If something comes up we see it immediately before the

official test is run which needs to be run every three months. So there are no surprises.
The other vendor we use
d did not have any kind of unofficial test and suddenly we
would be blindsided after three months if they found something and we would be out of
compliance. So we run the QualysGuard scan. It will be clean and then I can promote it
to the official PCI scan
. So we are very pleased with Qualys.

Chuck G.:
I agree with what you are saying. Plus Qualys gives you unlimited scans
where some of the other vendors were limiting you to your scans.

Dave G.:
OK, great.

Topic: Recording phone calls



you very much. Another topic came in

here from Mike. Is anyone
dealing with recorded phone calls that contain credit card information? What are they
doing to mitigate the risk?

Brian M.:
We are dealing with that by choosing not to deal with it.
We actual
ly excluded
those particular phone calls from our recording list.

Mike T.:

We have a call center that has tellers manning it and people could call in to
purchase tickets.
So we basically record them for security reasons and make sure that
quality of
the calls is

proper and everything else. We are looking at products that
can scrub the credit card information out or just blank it out so whenever they get to a
field to enter in the information it basically stops

recording for that set period of time and

then will continue to record once they leave the field. We are looking to see if anyone
else is doing anything out there.

Issam H.:
We have a very clever developer here who modified our call recording and
video recording software so that when the agent e
nters into

the portion of the call where
they are taking the payment before they can engage the US Bank site they have to click
a button on a site. It kills the video. It kills the audio. They conduct the transaction and
complete the payment and go back an
d the

recording resumes.

Mike T.:

So they are disabling and
enabling that when they are doing the credit card
information piece?

Issam H.:
Right, they can

t get into the credit card portion of the transaction without
disabling it.


cellent, thank you. Great information sharing folks.

David L.


the back end

where your credit card information is, what system is
that on that he was able to change that around?


Issam H.:
I believe that our call centers use CallCopy. That is w
hat we use to record the
audio and the video.

Topic: Who owns PCI compliance


Who owns PCI compliance at your
; in case anyone wants to

Or would someone like to bring something else up? Folks I put this topic on
here if anyone would like to adopt it. Who owns PCI compliance in your

Does anyone want to share a comment on that topic?

Peter P.:
I will say that unfortunately

IT owns PCI compliance. The reason that I think it
is a problem for us is that a network although it can be complex, there are a lot of
vendors and technology out there that can help you secure your network. There are a
lot of things that you can do.
You c
an do it all sitting at your desk. You can set up IPS
and IDS and you can monitor all

the traffic but our biggest vulnerabilities and our
biggest issues I think actually revolve around physical security

with all of our remote
locations our operators and

our managers in all of our

have not taken PCI
as seriously as we would like. That causes or creates a big problem for us with the
physical security because these people are using our computers all of the time. They
are in 100+ locations. What
they do with them and how well they are secured and how
well they lock the doors to our server rooms like they are supposed to on a regular

something that we can’t enforce. It is very difficult to be sitting in one office and
enforce that somewher
e else. The end users, the IT people usually aren’t the places
where the issues and the problems begin

although there is development and
technology issues

when you develop websites and payment applications. That is one
piece but for us it is all of our e
nd users. We have got thousands and thousands of them
and they don’t take a lot of the PCI stuff seriously.
If you go into one of our restaurants
you may still see somebody taking an imprint of your card if they are having issues with
their point of sale.
What they do with that afterwards, they don’t care. They

it on a
desk or throw it in the office, leave it on the counter. That to us is a problem and I think
that operators, the people who use the system need to take ownership.
IT can do all of
the b
ackend stuff pretty easily if you have the money.


Thanks for your comments. Let’s do a show of hands, those who are on
the web portion. How many folks or organizations on the web portion; IT owns the PCI
compliance at their organization, tha
t responsibility or the majority of it anyway. Thanks
for participating. A lot of hands being raised here. We are up to 20 out of 34. Does
anyone else have a comment?

Chuck G.:
As with the previous gentleman IT owns it and just to follow up on his
s with physical security 28 years of my life were spent in physical security
world. I made the jump to the dark side so to speak to go to computer security. That
gives me a little insight that I understand the physical measures that also need to be in
e in our server rooms and in access control and monitoring. So I get to work with
our physical security team also to implement what is needed.



Thank you very much. We peaked at 21 hands raised out of about 33.
It is
sort of IT, Brian said

Brian M.:
Mostly because we have created an organization above IT where reporting at
a peer level we have IT networking, some business and finance functions, project and
program management and then my group, the information assurance group. That large
p is called technologies. So we are part of what some people consider IT.


Thank you On behalf of NOREX

thanks again everyone and have a great

End of discussion

© Copyright 2011, by NOREX, Inc.

5505 Cottonwood Lane

Prior Lake, MN 55372 The opinions expressed in this
NORVIEW are those of NOREX members, not necessarily those of NOREX, Inc.