realizată de Stephen Skinner 12 ani în urmă
635
Mai multe ca aceasta
Can do this are the organizational group and job level.
At some point education will need to be targeted to individuals (org mgmt can handle ensuring specific individuals are identified).
Made sure you answer (document) all the questions the PCI survey is going ask you. This means extra levels of details. For example; are the users using unique ids?, do printed/produced materials in the full card number?, is the a support policy-procedure for the work?,
If Card Data is stored, we need to understand why - what function it serves. Our compliance solutions cannot cripple service delivery. This does not mean that "reasons" cannot be challenge. Brianstorming can help to identify alternate solutions. For example;
- Business needs to issue refunds at times; we need to Card Data for that? Alternate solution: re-obtain the card holder data viable?
- Business needs to process recurring payments - we don't want to ask the customer for their card data every months. Alternate solution: tokenization
Typically cross system but can be specific "systems". For example; "POS Devices", "System-X", "System-Y", "Paper Handing / People". Probably a few different ways to do this.
Remeber we have our guideline/control to use them throughout the process but it is particularly important here. Make sure that your remedies are sound (not only adequate but also not overboard!)
Consider the followng (be comprehensive)
- physical elements
- people
- process (policy-procedure)
--- day-to-day operations
--- how do "prove" we are doing what we said we'd do?
Some of the "macro" ones listed below. Understand and refine those for started.
At a "micro" level - do this in context to your threat vectors - do NOT just randomly apply the PCI standards, maybe that works for some people but it seems more logical to have a threat-risk as a frame of reference. You are doing this to protect your environment, address the risk - that is the the driver (not the standards).
- Information Systems
- Finance
- Revenue / Sales agencies
- Your Bank
Any/All instituted changes need the backing/support of formal (vetted, approved) policy - procedure.
- processes
- decisions (& rationale)
- correspondance with QSA
Does not mean totally linear. Yes, you have to understand Current State before you Assess it, but you don't need to understand the current state of everything. Feel free to take some services through from start to end - learn how to apply a "becoming compliant" process with something small. There is a risk that you take measures which do not "scale" well or would have been better concieved at a wholistic level but just keep in mind "reusability" (can I able this solution to multiple scenarios), "scalability).
See the Vector - Progress graphic to understand this concept.
You won't know / remember everything but build a foundation. You need to know what questions to ask, what kinds of things to look for. Your QSA will help to assess the details and come up with remediation strategies-approaches.
[speculating a little here but...] the standards "seem" to be well layered; meaning "C" builds on "B", "D" builds on "C". Jumping right to "D" level compliance can be brain numbing - start small and work your way up seems logical.
Minimize the scope; physical, logical,
The PCI standards give you a check list (a bunch of "standards"). The natural thing to do when you get a list is to work your way through it, right? Right.
Well, guess what, that stinks. We tried that - our head hurts & we chased our tail, killed some time and dough; with little of value to show for it.
We are doing this to protect our environment, to find the risks and eliminate them or mitigation them. That means become PCI compliant does NOT start with the check-lists. This "work breakdown" (not quite a plan), gives you an approach to getting there.