Re: PCI DSS Information Security Policy

We're a Level 2 merchant - between 1 & 6 million CC transactions/year. We
went through a large project last year to get compliant. That involved
bringing in a QSA, architecting & deploying a number of technologies,
documenting policies & processes, tweaking existing things like change
control, etc. We spent a high-7 figures on it.

For PCI purposes, consider in-scope systems are those that "store, process,
or transmit" CC data. So a web server that serves forms that takes CC #s
is in scope even if all it does is pass them along to the back-end app
server.

Also in PCI is the "next to" concept; any system that is next to a system
that stores, processes, or transmits CC data may also be considered in
scope. Next to doesn't necessarily mean on the same subnet (though it can)
but would include any system that talks to a system that
stores/processes/transmits CC data (think a supporting FTP server, your
backup system, etc.)

One thing we did for some of our apps was to simply offload the CC
processing to a cloud provider. Easier to pay a transaction fee than to
remediate some of the apps.


On Tue, Mar 31, 2015 at 8:12 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
wrote:

John,

Did you get involved much in the PCI Compliance process? It is, IMO,
really onerous. While filling out the SAQ online, I called in to support
couple of times to ask questions. Recently I started emailing questions
instead. I swear the emails answers, in a couple of cases, are directly
contradictory to the answers I got on the phone.

We average 20 credit card transactions _per month_. Yes, per month. It

is

an unchanging set of 6 or so customers. We enter the transactions online
into a virtual terminal (it's an https site so it's encrypted). We never
see the card nor do we store any card info in any way. We can't even see
the card info when signed into this virtual terminal. (When one of these
customers changes cc, the next transaction we call them for the card info
and enter it into the virtual terminal while they are still on the phone.
Every time after that, we search on customer number to find a prior
transaction, then resubmit with a new amount.)

Yet I'm being told we don't qualify for the "SAQ C-VT" (VT for virtual
terminal) policy and must use the more onerous "SAQ C" policy because the
desktop used in entering the transactions is not on a completely separate
and private internal network. Huh? The virtual terminal is accessible
from anywhere on the internet (think any public wifi hotspot or your cell
mobile hotspot).

I'm about ready to call our bank and ask for someone knowledgeable in

this

area. Based on answers I got the last couple of days, I'm back at square
one.



On Mon, Mar 30, 2015 at 9:03 PM, John Jones <chianime@xxxxxxxxx> wrote:

SANS.org has some free policies. They're not great IMO - most seem to

be

too focused on the contributing author's environment - but can be a
starting point.

There are some relatively inexpensive "policy packs" you can buy. For

a

few hundred $ they give you generic IT policies that address most

topics;

you can use them as a draft and customize as needed.

At my employer, who went through the process of getting PCI compliant

last

year, we developed something like 30 point policies in addition to the
umbrella policy. The point policies addressed specific issues like

data

retention, encryption standards, segregation of duties, etc. Basically

as

you go through the DSS, the self-assessment questions should tell you

what

you need policies and processes for.

On Mon, Mar 30, 2015 at 1:30 PM, Jeff Crosby <

jlcrosby@xxxxxxxxxxxxxxxx>

wrote:

Does anyone have a written information security policy meant to

address

PCI

DSS Requirement 12: "Maintain a policy that addresses information
security" that I can plagiarize? :)

Thanks.


--
Jeff Crosby
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of

my

company. Unless I say so.
--
This is the PC Technical Discussion for IBM i (AS/400 and iSeries)

Users

(PcTech) mailing list
To post a message email: PcTech@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/pctech
or email: PcTech-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/pctech.

--
John Jones, CISSP
History has taught us that we don't learn from the past.
--
This is the PC Technical Discussion for IBM i (AS/400 and iSeries)

Users

(PcTech) mailing list
To post a message email: PcTech@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/pctech
or email: PcTech-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/pctech.

--
Jeff Crosby
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
This is the PC Technical Discussion for IBM i (AS/400 and iSeries) Users
(PcTech) mailing list
To post a message email: PcTech@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/pctech
or email: PcTech-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/pctech.

--
John Jones, CISSP
History has taught us that we don't learn from the past.
--
This is the PC Technical Discussion for IBM i (AS/400 and iSeries) Users
(PcTech) mailing list
To post a message email: PcTech@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/pctech
or email: PcTech-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/pctech.