Jump to content

jimmer5

Members
  • Posts

    11
  • Joined

  • Last visited

Profile Information

  • First Name
    Jim
  • Last Name
    Albert

jimmer5's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. We're definitely getting into the "fuzzy" side of PCI which I definitely find as one of its problems. Lots of good advise, no doubt, but I admit, the whole PA-DSS seems to be left intentionally vague. For example, on several of the SAQs, you are asked if you use a payment app and if so, if it is listed as validated. But nothing I can see indicating the consequences of the PA not being validated. Same kind of fuzziness with SAQ A vs SAQ A-EP. Have you ever tried to figure those two out? My take on them in terms of what I believe they are supposed to represent. SAQ A - pretty much your whole ecommerce site is hosted and manged by a PCI compliant vendor. SAQ A-EP - I believe redirects and iframes off to payment gateway for handling card information implies SAQ A-EP, but a lot of the documentation points differently, which I tend to think is a cop-out to prevent a lot of existing SAQ A customers from having to migrate to SAQ A-EP which is way more work. But that's my cynical opinion on that one. SAQ D - everything else as in reposts.
  2. I don't know what the word certified means on that site. Read the disclaimer at the bottom of that page.
  3. Whether you agree with every one of the 12 commandments of PCI DSS or not doesn't really matter. In terms of accepting cards, it's the rules you play by. What do you think ecommerce sites probably looked like before PCI and having good security thrown in peoples' face. Would people even use VPNs and proper DMZ and other network segmentation if they weren't told to? Who knows. But, like I said.. it doesn't matter if you agree or not. They are the rules. For the most part, I think the requirements are written pretty well, albeit in some cases left open to interpretation and yes in some, overboard. But even if you weren't taking payment cards, 75% of the requirements are sound security advise for any company with regards to IT. Go and try to apply for cybersecurity insurance, you'll see much of what's probably listed in the application is covered by PCI-DSS regs. The requirements really only get updated maybe every 3 years so in some sense they have to remain generic. As far as ciphers, what would you like to be stated? Bitlengths can be specified, but do you want them to come out and say prioritize RC4 ciphers in your SSL configs because that helps defeat a Beast attack and then 6 months somebody realizes RC4 weaknesses are worse than Beast. Those regs have to be written so they are fluid and dynamic with the changing vulnerability environment. Good gosh, just look back at 2014, that was most certainly the year of the vulnerability. What do you mean by "certifies it for their gateway" with regard to the PrestaShop authorize.net payment module? So are you saying authorize.net will provide some sort of PCI Attestation regarding the PrestaShop payment modules? Off hand, I don't know what that would be, as I don't think a Service Provider Attestation would make sense. But again, if I don't write the code and I don't examine it for all the PA-DSS regulations about writing payment modules, then how can use of it be written in to a merchant's PCI Attestation? Just consider the problem in terms of versioning, I just don't see how that happens with out some sort of certification that the author adhered to PA-DSS. Granted if you are a programmer you can always examine the key pieces of a payment module for PA-DSS standards and attest to it yourself as if you had written it. I tend to think most merchants using such modules don't have programmers on staff. Then as far as finding bugs, well gosh, what software doesn't have bugs? Adobe flash must come out with security updates once a month. You write the software with the best of intentions following proper security as best you can, bugs are bugs. Software that's passed a compliance audit can certainly still have bugs. You find them, you patch them and let people know. No different than every other piece of software. Not having used the PrestaShop authorize.net payment module, give me some insight please as to how it works. Is it reposting data to authorize.net... eg with the authorize.net AIM API or is doing something much simpler and less card-centric like a redirect?
  4. In order to do what? Sell payment modules or accept credit card payments for Bellini Services? Any merchant accepting cards as a form of payment fall into one of these sections for PCI SAQ: https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf That could work if I assume all my customers will have javascript enabled, and then what decision has to be made if js is disabled and no hash arrives. This assumes, of course, one can effectively shop on a PrestaShop store without js enabled. I haven't played with PrestaShop enough to answer that. But that is an interesting approach and might such a solution reduce your PCI SAQ status from SAQ D to SAQ A-EP? That hashing js code which would be my js would have to have access to card number field which I would assume is generated by the payment module. Although that depends on what the payment module is doing as well. In the payment modules for which you are familiar or wrote are they doing redirects to payment gateways which are then supplying the payment forms or are the payment modules receiving the card data and then posting it to the payment gateways? The later would I would say would most certainly imply SAQ D since the card data flows through my server in order to do the posts. Although the whole SAQ A and SAQ A-EP decision is still kind of fuzzy at least to me. The PCI Council in my opinion leaves a lot of these standards fuzzy and then it seems left to the interpretation of the 'field' then you have to read enough different A vs A-EP analysis write-ups to decide which one you believe you agree with. I've seen some analysis state if you are doing redirects or iframes then SAQ A, if reposts then SAQ A-EP, but I don't think I agree with that, seems if the card at all crosses my servers, I'm SAQ D. btw... I do appreciate the conversation we're having here in this thread. You are causing me to think from certain angles that I had not considered.
  5. Well... those are absolutely legitimate complaints about the lack of PA-DSS validation on the PrestaShop developed payment module. I will add though, that I believe PCI leaves the whole PA-DSS subject intentionally vague. For example, the SAQ D has a section 2D before you get into the 12 Requirements sections about if you use a payment application and if it is PA-DSS Listed? You state if you use one and if it is listed, but no indication of consequences or compliancy if you state that you use a payment application that is not listed. But, I'd be cautious of using a payment module that was not developed in house to which I could attest and was not listed as PA-DSS. I would agree though that if using authorize.net payment gateway and if need customizations it would be worth starting with something that already exists. Although I'd then be attesting to code we didn't write so it would have to be examined. What did you mean by you use BrainTree and no PCI certificates required? I didn't follow that. As far as the in-house fraud prevention... I want to maintain a card history via a SHA2 hash. How can I do that without seeing the plaintext card in memory, hashing it and then storing that hash? I don't see how the card can't cross my environment if I'm going to store a hash on it or make other in-house fraud decisions.
  6. With regard to a payment module like: http://addons.prestashop.com/en/payments-gateways-prestashop-modules/4423-authorizenet.html What would you make of the statement in the bullets of that page that state "Safe and secure (PCI-DSS compliant)". Note they do not state PA-DSS validated. This module would clearly be a Payment Application according to PCI and according to: https://www.pcisecuritystandards.org/pdfs/pci_pa-dss_faqs.pdf would qualify as follows: Q. What types of payment applications are subject to the PA-DSS requirements? A. Payment applications that are sold, distributed or licensed to third parties and are installed “off the shelf” without much customization by software vendors are subject to the PA-DSS requirements. I didn't write the payment module, PrestaShop did so what does PrestaShop's statement of 'PCI-DSS compliant mean? As far as I can see from: https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true there is no listing for PrestaShop payment modules. So, I don't know who is attesting to the payment module being PCI compliant. If I didn't write the code and I have no PCI documentation from PrestaShop backing the PCI compliancy of the payment application, how can I attest to anything about it in my own PCI documentation unless I examine the code myself and attest to it. How much have you been invovled with assisting PCI SAQ D merchants make use of PrestaShop?
  7. You're more PCI-knowing than most. 1. I currently do not use PrestaShop. Current environment is custom code but I'm considering a move to PrestaShop or other open source solution. Basically want to take advantage of all the front end bells and whistles that would take in house developers a long time to reproduce. For the purpose of discussion, payment gateway would be authorize.net and likely via the authorize.net AIM API. 2. I've been looking for some good reading on extending/customizing the PrestaShop database in terms of either adding fields to existing tables or new tables. Much of what I've read suggests editing what looks to me to be core modules and I know that can't be a good idea. Can you point to some good reading on that, please?
  8. Thanks for the helpful response, ok... so I fall into the area you outline as: "Then there are gateways that allow you to capture the card information, and send it to them securely using server to server technology. Since the card information crosses your hosting environment, this would bring you into scope of PCI compliance rules. Even if you do not store the card information, simply crossing your hosting environment puts you into scope." So, current scenario environment as you define above... SAQ D where card crosses the server environment. Dedicated hosting with proper security zone network segmentation and firewalled and we've gone through the 12 PCI DSS Requirements using various log and traffic watching sources such as AlertLogic and employing WAFs and all the other PCI measures including the enormous amount of documentation. Yes we understand it and yes it is daunting. We believe we are fairly confident in what we are doing there at least as much as anyone else that has had to go through SAQ D, and yes, it is beyond reasonable for a small business. We have tech professionals in house and contracted as needed. So current scenario, no card storage in terms of plaintext or encrypted... tokenization, but we maintain a cryptographic hash of the card number for the purpose of fraud prevention. We are in a business that heavily attracts fraud. Yes, there are outsource services for fraud prevention, but most are not as good as what our inhouse staff can do. Part of that is the ability to maintain card usage history. PCI allows storage of a cryptographic hash of the card number if you store in plaintext no more than the last 4 digits of the card, so that is something I would want to maintain with a migration to PrestaShop. So, are you saying in such a scenario we would be writing or contracting with a company (perhaps such as yours) to develop a payment module that would do such a thing? Extend the PrestaShop database to mantain a card hash... say a SHA2 along with other customizations that fit our business model? At that point the PrestaShop module is custom and written by someone who is assumed to understand PCI programming practices such as OWASP and others, but at that point the module need not be PA-DSS validated since it is not licensed or mass-distributed. Are we getting to be on the same page?
  9. Thanks, I'm reasonably PCI-literate having had to fill out SAQ D for an environment in which we manage the hosted environment and custom software. We're looking to move away from some of the custom software and take advantage of something like a PrestaShop or Magento. I'm tackling the investigation from the security and PCI side so I am asking these questions with the best of intent in terms of my analysis of PrestaShop and PCI conformity. More information: https://www.pcisecuritystandards.org/security_standards/glossary.php#P Payment Application:In the context of PA-DSS, a software application that stores, processes, or transmits cardholder data as part of authorization or settlement, where the payment application is sold, distributed, or licensed to third parties. Refer to PA-DSS Program Guide for details. So a Payment Application is any software through which the card flows that is of a commercial variety or licensed. Not a custom piece of software one would write on one's own, but licensed as licensing PrestaShop and any relevant payment modules. Then further: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/If-a-merchant-develops-an-application-that-runs-on-a-consumer-s-device-e-g-smartphone-tablet-or-laptop-that-is-used-to-accept-payment-card-data-what-are-the-merchant-s-obligations-regarding-PCI-DSS-and-PA-DSS-for-that-application/?q=what+is+a+payment+application&l=en_US&fs=Search&pn=1 which would involve software written by someone through which card information flows. Now if this is custom software that I wrote, then I can attest to the fact that it was developed according to PCI DSS standards. But if it is not software which I wrote, then I can't attest to its development and therefore in order to claim compliance I must be able to indicate that the payment application conforms to PCI DSS. In other words is the payment application PA-DSS validated and the only way I know of confirming that is to search for the payment application here: https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true
  10. Oh my goodness.... not at all. Those online merchants where cards flow through their enviornment must conform to PCI SAQ D which is far more involved than you state it to be. But of particular importance is the payment application, that part of the software that communicates credit cards to processors. For example I see an authorize.net payment module by PrestaShop and it uses AIM which is the authorize.net Advanced Intengration Method and thereforce you program to the authorize.net AIM payment API. Is the PrestaShop authorize.net payment module PA-DSS certified? If not, how does a merchant using it answer such questions on the PCI SAQ? What is PrestaShop's response to something like: http://magento.com/resources/pci These are incredibly important questions to be answered for anyone considering PrestaShop and must conform to PCI SAQ D.
  11. https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true Search on PrestaShop and nothing is returned. Believe me, I've been through the 12 commandments of PCI SAQ D and if you aren't writing the code yourself at stating you follow all the appropriate procedures and protections, you have to use a PA-DSS approved payment application. How does one use PrestaShop and accept credit cards and maintain PCI compliance? Are PrestaShop payment modules created such that the card number never crosses any of the PrestaShop software itself? Is the customer taken off the PrestaShop software to an external payment gateway such that my server will never see a card number? Unlke one of PrestaShop's big competitors, I'm finding little to read on PrestaShop and PCI. Is there a PCI link somewhere on the PrestaShop site? Thank You.
×
×
  • Create New...