29

Note : not a QSA, but I do have some PCI experience. There is nothing in PCI about storage of source code - there are requirements about change management, which github would help with, but nothing about where source code should be or any requirements to keep source code private (it allows use of open source, after all). Given a private repo and assuming ...


11

... if a bad actor is able to run javascript on your page That's exactly the point one want to avoid. Iframes allow third-party sides including script to be part of the visible page without having access to the parts of the page outside the iframes served by this specific third party. This is much more safe than embedding a third party HTML (for the form) ...


9

Unfortunately for you, because the raw card data transits your servers in cleartext, you have to use SAQ D, and because you aren't the merchant yourself, it would be SAQ D for Service Providers. There may be entire sections of the SAQ that don't apply to you and can just be marked N/A, but you still have to fill out the whole thing. If you could get the ...


8

Using that external storage effectively brings it within PCI scope, however you are correct: If you have strong encryption sufficient to protect the data, and can evidence that, storing it on an archive should be allowed. Don't try and word it as outside PCI scope though - account for it in the usual way when speaking with your QSA, and include the info ...


7

PCI-DSS only applies to computers and systems that handle PCI (Payment Card Industry) information. If it is handled by a third party and you are only given a receipt token, then no PCI data is being handled by your system and it doesn't fall under PCI-DSS.


7

The short answer is yes, but it's more difficult. The main principle of using VLANs to segregate the PCI DSS environments is reducing scope for assessment and maintenance. If you reduce the scope, then only the servers which need to be compliant are assessed. If you don't segregate, then the rest of your network (and all the users of those devices) come ...


6

Yes, they should be separate servers. However, they don't need to be separate physical servers; they can be three virtual servers on one physical server. There is some room for debate in the standard. Separating web and database is pretty much non-negotiable. But if email is a minor function - say, the web server just uses it to send the odd email ...


5

That is correct. if you are using the Stripe or similar processors that utilize a redirect method to post payment data to the processor you will use the SAQ A-EP. if you use an iframe or payment is 100% hosted by a compliant service provider then you can fill out SAQ A. Here is a FAQ from the PCI council that explains things in a little more detail: PCI SSC ...


5

You don't so much achieve a passing scan, as work with your QSA to agree the scope of the scan, and ensure this traffic is out of scope. This will require you have a QSA who can understand this - and a lot does depend on their opinion, but that would be the approach I would take. If you don't currently use a QSA, ensure you have fully documented the scope ...


5

I am attempting to ascertain the boundaries of personally identifiable information. That is a legal question, and varies by jurisdiction. Perhaps the best known is California: (a) The term “personally identifiable information” means individually identifiable information about an individual consumer collected online by the operator from that ...


5

Basically, they don't have to be. While merchants and service providers are often contractually obligated to be PCI-DSS compliant, payment applications tend to be PA-DSS (Payment Application Data Security Standards) compliant and certified (if they want to be used by merchants who wish to maintain PCI-DSS compliance). According to the PCI Security Council'...


4

Oh. As per your update... No. Firewalls not connected to the CDE are not in scope simply because encrypted PAN data transits them. If that were the case, the whole freaking Internet would be in scope. Part of being PCI compliant involves mapping out cardholder data and network topology. The firewall closest to your CDE is in scope, and if the assessor ...


4

Instead of trying to toe some ill-defined line, think about your security, and your responsibility to your customers. If a hacker was in your network, what would happen? Even if PCI didn't technically require it, if this data is in my network, I would require it. That said, our QSA's interpretation is that it always needs to be encrypted internally.


4

Ultimately, I think you're going to have to figure this out with your PCI auditor, which I am not. I think you're going to have a hard time figuring out how to do this is a way that is a) not overly burdensome to you and the ultimate users of the card data, and b) leaves you with a system that is still PCI compliant and that your auditor will give a stamp ...


4

Caveat IANAQSA In these three scenarios, is there a difference in PCI scope for the server running in Azure? What is the scope? Does our Azure infrastructure need to undergo an annual audit? Scope here should be measured as a per-merchant thing, not as a per-server. Yes, your Azure servers would be covered by your scope (the level of which I'll ...


4

This depends how you do the integration with the payment processor. Let's pretend for a minute you are a merchant - then the correct SAQs would most probably be SAQ A or SAQ A-EP depending on the integration / re-direct / IFRAME / JScript. As a service provider you can't complete A or A-EP but you must complete D or undertake a full Report on Compliance. ...


4

First, anyone who says "PCI compliance is baloney" is incompetent; you absolutely did the right thing by walking away from them. Also note that PCI liability means you are on the hook not only for fines and card replacements, but all the fraud that was committed with card data stolen from your environment. If the thieves buy a fleet of Ferraris, you are ...


4

The PAN alone is sufficient to make it in-scope. To quote PCI DSS 3.2.1 "PCI DSS Applicability Information": The primary account number is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment (...


4

I'm writing this as an answer because a comment would be too long. But some time ago there was some malware that was used to infect some e-commerce websites, and the malware simulated a fake paypal popup window, or something like that. To check if the window was real or fake, they suggested trying to move the payment popup outside of the browser's window ...


3

Part of both answers: Disclaimer: I am not a QSA. And I'm straying farther into opinion here than I prefer to, so apply salt in grain form. New answer following edit of question: There are two changes with DSS 3 that bear on what you seem to be flirting with the addition of the new SAQ A-EP category. the back alley tussle that has been iframes versus ...


3

Without checking, I'm going to assume that your CentOS RPMs contain backported fixes which address the CVE's listed in their report. (That's how RedHat does it and CentOS is RedHat in this regard). Because of this, your packages are probably immune to issues that their banner would otherwise indicate they're vulnerable to. What you need to provide ...


3

The language/summary that addresses your question is requirement 4: "Encrypt transmission of cardholder data across open, public networks" Here is a couple links (with additional references) that give an overview of the requirements. I'll leave this as a community wiki in case someone can find a better link. Wikipedia pcisecuritystandards.org That being ...


3

Yes, it's in scope. There's actually a pretty thorough and explicit guide from the PCI Security Standards Council (the DSS people) to your exact question here: Information Supplement: Protecting Telephone-based Payment Card Data Which makes reasonably clear statements like this about card numbers: Call centers will need to ensure that PAN data is ...


3

Whether a data leak is because of internal or external factors does not matter. In the situation you describe the UK company is the data controller and solely responsible for taking the appropriate measures to avoid data leaks. Even if they used a processor this processor may be liable, but the UK company is still responsible. See the basis for all ...


3

Yes, this is bad. One primary application per server would mean that, given the functions you've listed, you would have three servers. One web server, one mail server, one database server. In fact, given that you're in a PCI environment and assuming that you are storing PCI data in the database, the database cannot be on a system that is able to ...


3

Scanning versus Manual Code Reviews Custom built, in-house software is in-scope for PCI compliance if it deals with PAN data. The PCI DSS, Requirement 6.6 expresses two options for in-house developers of software that handles PAN data: You can either do code reviews, or implement a web application firewall (WAF). Of course, it specifies the nature of the ...


3

Yes, moving card holder data (CHD) handling off of your network to PCI compliant 3rd parties is an excellent way of reducing the PCI scope of your implementation. Having the payment page hosted with a PCI compliant 3rd party, and integrating the transmission of CHD to a PCI compliant 3rd party tokenization and secure storage service provider, greatly reduces ...


3

Is the OMS system and its network in PCI scope because it is reaching out directly (no proxies) to the processor's APIs? No, it is not in scope. The processor will be using a combination of network firewalls, application security firewalls, and restricted APIs to provide segmentation between their PCI-scoped network and you, the consumer of their ...


3

I will take a different approach to this answer. Gowenfawr, and SilverlightFox provided excellent answers from the textbook/guideline perspective, so I will tackle answering your "John and Doe equate to personally identifiable information since there could be several thousand John Does" portion. Many portions of current PII laws, come from inference attacks. ...


3

Well, the first thing you'd do is put the iPad in "Guided Access" (single app mode) so that the only app that can be used is whatever point of sale software you've got on there. Next, put it on an isolated network segment that doesn't have external access and is properly secured, and you can actually have a pretty secure setup. At least as secure as ...


Only top voted, non community-wiki answers of a minimum length are eligible