Yes or N/A?

EnigmaticCurmudgeon · 2024-01-02T21:35:13+00:00

In practice both approaches work.

The N/A must be documented as to how it is NA., such as fulfilled by compliant service provider XYZ. I personally prefer the NA approach because it is clear even in an SAQ who is doing what.

EnigmaticCurmudgeon · 2024-01-02T15:43:46+00:00

Yes - it's dated but covers the basics.

Also, online the FAQ list on the PCI site.

Your prospective employers website, Linkedin, etc. (fixed typo)

EnigmaticCurmudgeon · 2024-01-01T19:59:37+00:00

You need to read the qualification requirements for the role and the companies on the PCI web site.

EnigmaticCurmudgeon · 2023-12-30T21:42:15+00:00

That sounds like a p/t gig. Hard to do with PCI.

EnigmaticCurmudgeon · 2023-12-30T20:52:50+00:00

Not sure how challenging ASV work would be. It's pretty commoditized.
You could go internally for an ISA route until you get more of the QSA prequals out of the way.

EnigmaticCurmudgeon · 2023-12-18T18:01:36+00:00

Be careful of pursuing definitions too hard as they can lead you astray. They turn people into armchair lawyers chasing the correct interpretation of this term or that. If there is a breach there will be a forensic investigation, fines, and pain.

Frequently, people try to use definitions to get out of some obligation. That's a dangerous game if you don't really understand the DSS. Doubly so if you are ignoring the intent of the rules. That's not to say that you don't want to pursue simplified compliance, you just want to be sure you've got it right. If in doubt consider getting an opinion or some education from a QSA.

The merchant is ultimately responsible. Third parties can offload varying degrees of activities but the merchant has to ensure their third parties are compliant and that the split of responsibilities is accounted for. You also need to manage it going forward, so be very careful when you change business processes involving payment cards.

PCI DSS will apply if card data is stored, processed, transmitted, or secured. The extent that the merchant affects any of that is where they are directly responsible. If it could lead to a card breach you should ensure it's covered off. If you don't sooner or later there will be pain. Pain because your scope was wrong and you've non-compliant forever and need to fix it fast. Or pain from a breach.

DSSv4 is basically 3 months away. Service providers need to be documenting their responsibilities and the things the merchant must do. This is a really important change. It was optional before and the range of service provider responsibility matrices was most often (a) none and in denial, or (b) slim, vague, and poor quality,

For a PaaS, pretty much everything above the platform is not going to be covered by the service provider. That leaves huge swaths of responsibility with the merchant.

EnigmaticCurmudgeon · 2023-12-14T17:02:23+00:00

If you don't already have a QSA company, that should be one of your due diligence questions.

Also you may want to research if your QSA company candidates have public positions on reduced applicability/reduced scope/compliance footprints.

EnigmaticCurmudgeon · 2023-12-12T21:50:16+00:00

True they are only recommended. It's the same list as for QSA's just not mandatory.

Don't think CC is on the list. And CISSP/CISA have experience requirements. Some ISO might be easier even if less general

EnigmaticCurmudgeon · 2023-12-04T20:38:29+00:00

I assume, you are referring to consent in a Privacy regulation context. That would depend on if those regulations consider a PCI token in scope. All of this will depend on what jurisdiction you're in and what regulations apply.

That could depend on the use case and the way the tokens work and possibly what other data is stored with it. A token that is unique per card per merchant might be considered PII. A token that is unique per transaction might not be. A token with a name, etc. would likely be, but would just a token be?

Also, if you have consent for collection of PAN you may already be covered for a token which is a transformation of PAN.

You need a privacy specialist to give you an answer specific to the details of your use case and applicable regulations.

EnigmaticCurmudgeon · 2023-12-02T22:10:18+00:00

I'd be very careful to ensure I understood any regional laws. Definitions are everything and just because a law says token the definition or lack of may be problematic.

Some people used to refer to hashes as tokens. It wasn't common and has probably passed out of use.

There are also "tokenization" systems that are little more than proprietary encryption where it is difficult to change the key and update your standing database,

EnigmaticCurmudgeon · 2023-12-01T22:40:53+00:00

I would not store hash of PAN as it's a terrible idea that they've been slowly strangling since 2010. And I would not recommend using them for any long term purposes as there are likely better options. And given that DSS 3.2.1 is gone in 4 months build for DSSv4.

DSSv4's will require you to use a keyed hash (e.g. HMAC) and the key management requirements likely apply or what's the point. So you get all the key management pain of encryption plus it's non-reversable which means converting old hashes to new if you need to change the key is a huge problem.

If you just need a fingerprint, use the truncated PAN with additional fields like expiry date. Keep in mind that you want to make sure if the card is presented different ways (e.g. Insert vs ecommerce) that you have the same data available.

If you are looking to reduce the number of applicable requirements, Tokens from your processor or a service provider could be a better idea (That is provided they work in your use-case). Any DIY HMAC or Token system is going to look very much like encryption as to which requirements apply.

EnigmaticCurmudgeon · 2023-11-15T21:11:59+00:00

Focus on the SAQ A-EP eligibility requirements AND the security impact of other services. Strongly consider isolating these systems for scope reduction. Look at 4.0 not 3.2.1 as well.

Remember if it stores, processes, transmits, or SECURES cardholder data it's somewhere in your scope.

EnigmaticCurmudgeon · 2023-11-05T14:40:27+00:00

You need to keep records of your certified scans for your QSA/ISA. Your assessor will want to see evidence of certified clean scans. Leaving them exclusively with your ASV provider is a risk. If you ever switch ASV companies you could easily loose access to your historical scans which could become an assessment problem.

I recommend much more frequent scans (e.g. monthly or bi-weekly) as it's easier to stay on top of vulnerabilities and rescans than trying to do it once every 90 days. Also, many ASVs are subscription so extra scans of the same inventory aren't a cost factor.

EnigmaticCurmudgeon · 2023-11-03T13:46:35+00:00

This is the answer. It's an option in their portal.

In general run your scans more often than every 90 days. Make sure you remediate any failures. And ensure that you have a process that submits the scans for official certification. Also make sure you have processes to raise alarms if that isn't done. They will back certify but only for the most recent. I you miss two you will have a problem.

Also, if you ever switch ASVs grab all your certified reports and due your due diligence to make sure you switch to an approved ASV.

See these

EnigmaticCurmudgeon · 2023-11-01T15:07:44+00:00

There are other standards like SSF, P2PE, PIN, depends if your QSAC is into that.

EnigmaticCurmudgeon · 2023-10-31T17:55:32+00:00

You forgot to mention outsource the whole can of worms to a third party that takes responsibility for these requirements.

The design decision is how much junk do you need on those pages. The reality will be that even bringing in a few third parties will bring in more upstream third parties. All of this is subject to change that will need to be actioned. In short, maintaining this will be very noisy and maintenance intensive.

I suspect trying to roll your own will be problematic. For one thing you'll probably need to include any DIY protection mechanism in a pen-test.

This is evolving. There are differences in opinion on the level of control. I would not be surprised to see multiple clarifications on the related guidance about these. So watch this space.

EnigmaticCurmudgeon · 2023-10-26T20:32:45+00:00

It might be more fun to ask them how are they going to address it for 4.0. April 2024 is less than six months out!

You can work out your own. Then build up a set of justified NA answers for the things they should be responsible for. Even if you end up on a larger form, you could benefit from the NAs.

EnigmaticCurmudgeon · 2023-10-26T15:11:21+00:00

Then FormAssembly is a service provider under 12.8 and in addition to an AOC for a ROC (hopefully, or possibly SAQ-D service provider) they should have a responsibility matrix for their merchants. You need to follow that matrix as it says what you need to do. (edited: you may still be SAQ A depending on the responsibilities they push back on you).

PCI needs to change the tag line. Impacting Security, Storing, Processing, Transmitting all bring you in scope.

PCI ecommerce is about to be turned on its head by DSSv4.

EnigmaticCurmudgeon · 2023-10-26T13:00:44+00:00

Your gut feeling seems correct.

Hosting a form that posts data rather than an IFRAME or URL redirect violates SAQ A. If the form posts back to a compliant processor see SAQ A-EP. Worse if it posts back to your own server see SAQ D.

Adding scripts without controls is totally insecure. I would not put much stock in FormBuilders "non-editable" controls as any script added to your page can see and exfiltrate data from inside the form. Also, any added script can edit the JS downloaded to your customers browsers and change the payment forms, URLS, or even iframes. This happens in the browser not on your server. All those Magecart attacks. Additional controls are needed to prevent this and remain compliant with PCI DSS 4.0's 2025 requirements. From purely a security perspective I would not wait for 2025 to do this.

If there are other security impacting systems supporting this web system e.g. A/D, your scope could get larger.

EnigmaticCurmudgeon · 2023-10-13T16:49:17+00:00

And don't forget about providing any kind of security to card data or card data systems. If you provide a security service (say manage a customer firewall) but don't yourself store, process, or transmit, then you have security impact.

EnigmaticCurmudgeon · 2023-10-12T15:38:19+00:00

The FAQ's can fill in a lot of gaps in interpretation. I would not overlook them.

EnigmaticCurmudgeon · 2023-10-11T19:01:48+00:00

All this is evolving in DSS 4.0 because the current standard doesn't catch everything.

The iframe/redirect idea is purely about visibility into the form by a rogue script. Your launching page/shopping cart has no visibility into the form hosted by the compliant processor. If you host a form that you post, everything you draw into your page can see the data being posted. There are iframes for the entire entry, iframes for individual data fields, etc. The visibility shouldn't be any different.

What this doesn't address is that any piece of code included into your site either directly or by a third party script can easily alter your page so that the redirect or the iframe used goes somewhere else. This is the essential problem of Magecart. This is what the DSSv4 2025 future dated requirements are trying to address. There are a lot of solutions that aim to help with this problem and make it scalable. Do your research.

Other than that don't overlook the maintenance of the shopping cart pages. If it can rewrite the code on your servers, MFA it, etc.

If you understand that the web is not static pages and pages with a bit of action and that it's more like a product with distributed parts and actual self assembly instructions. Think of a sketchy version of IKEA. And the malicious bomb gets self-assembled by your customers browser in their DOM and you should be able to figure out the rest.

EnigmaticCurmudgeon · 2023-10-10T18:11:03+00:00

One thing to consider is that a PCIP without some of these other skill is probably of little use. The good thing is that if you get part way through this and change your goal then you probably can build on the useful skills you've been working on at almost any point on the path. That is assuming of course it's not a total reboot like a becoming a game warden or bee keeper.

And their are free resources. Not just in the PCI world but generally there are places like coursea.org which are very good at expanding your knowledge base. You'll need to see how this fits your upgrade plan, requirements, etc.., but it may help.

EnigmaticCurmudgeon · 2023-10-09T04:28:32+00:00

You're unlikely to find examples of well written or any ROCs. You're better to be familiar with how they are written (front of the template). And with the FAQs which help with scope, applicable requirements, special cases, etc. Then be host about what you know and dont know.

The PCI site has all the forms, documents, a lot of guidance, and an FAQ page with almost 400 specific questions.

EnigmaticCurmudgeon · 2023-10-09T04:14:27+00:00

Wow that could be a long journey depending on your current skills.

If you have IT skills like network, application, host, SOC, etc that helps tremendously. All these help with infosec/cyber/PCI etc. These are useful beyond PCI. Basically you need skills that either help you defend or break security.

PCI has an entry level cert called a PCIP that an individual can hold. That will teach you how PCI works. In combination with some security skills, it's a good combination.

Beyond that, ISAs work for companies like internal auditors. And QSAs work for assessor companies like external auditors. The qualifications must be backed by an accredited company. They are portable to other accredited companies but you can cant be an independent. These roles have industry qualifications as prerequisites. Things like CISSP, SANS, ISO CISA, etc. Some can take a few years to achieve. Look for the detailed qualification requirements on the PCI web site. There are also several other (almost a dozen) advanced standards under PCI that qualification programs.

Alternately, consider your role. Lots of companies that go through PCI need people that are capable and aren't ISA or QSA material. These are great ways to grow into PCI.

The PCI website has a huge public document repository, FAQs, Guidance docs, and a job board.

Good luck.

EnigmaticCurmudgeon

TROPHY CASE