Learn the fundamentals of the popular programming language JavaScript so that you can explore the realm of web development.
Issues with PCI compliance and being a small company.
My accounting department set up a credit card merchant account without my knowledge. I was getting Trustwave scan notices but they were going into my junk mail for a while. I just so happened to examine one of these "junk" mails one day and with a little digging found out that we were in fact signed up to process CC with a merchant account and were subject to the PCI compliance scans. We used to have a swipe machine that ran on a analog phone line and apparently it was too much work for accounting to get up from their desks to use the swipe machine for the 5 to 8 credit cards we get a month. We do not store any CC information here. It is basically just run through a website. So once I realized what was going on we had been failing scans for a while. I initially fixed the issues we were failing for. One issue with our VPN and another with my remote access to my firewall which i had to close. I also have been noticing i fix one thing and get a good scan and then the next scan they nit pick about something else......and so on. It seems never ending. Now we are right back to failing again for issues related to remote desktop/terminal server I believe.
1. TLSv1.0 Supported: This service supports the use of the TLSv1.0 protocol. The TLSv1.0 protocol has known cryptographic weaknesses that can lead to the compromise of sensitive data within an encrypted session. Additionally, the PCI SSC and NIST have determined that the TLSv1.0 protocol no longer meets the definition of strong cryptography.
2. SSL/TLS Weak Encryption Algorithms: The SSL-based service running on this host appears to support the use of "weak" ciphers such as:
- Ciphers suites that have key-lengths of less than 128 bits.
- Ciphers suites using anonymous Diffie-Hellman algorithms (no authentication).
- Ciphers suites offering no encryption.
- Ciphers suites using pre-shared keys.
- Ciphers suites using RC4 or MD5.
3. (Has shown up in the latest scan). Insecure Certificate Signature Algorithm in Use: This finding indicates that SHA-1 and/or MD5 hashing algorithms have been detected during your scan.
These are showing up for ports that I have for machines that are being used for remote desktop & my terminal server. I have been reading and from what I see if i were to alter TLSv1 that remote desktop will no longer work. This is no good. We have remote offices who remote into my servers to do business. If these are known issues is Microsoft going to patch or correct these issues? Or does anyone know how I can remedy these 3 issues while keeping my terminal servers available? I see that there are third party companies that will handle CC transactions but they change a fee on top of the fee we are already being charges for excepting a cc. How do small companies that only get a handful of CC a month do this? If anyone has an information on how I can clear any of these three issues it would be much appreciated.
1. TLSv1.0 Supported: This service supports the use of the TLSv1.0 protocol. The TLSv1.0 protocol has known cryptographic weaknesses that can lead to the compromise of sensitive data within an encrypted session. Additionally, the PCI SSC and NIST have determined that the TLSv1.0 protocol no longer meets the definition of strong cryptography.
2. SSL/TLS Weak Encryption Algorithms: The SSL-based service running on this host appears to support the use of "weak" ciphers such as:
- Ciphers suites that have key-lengths of less than 128 bits.
- Ciphers suites using anonymous Diffie-Hellman algorithms (no authentication).
- Ciphers suites offering no encryption.
- Ciphers suites using pre-shared keys.
- Ciphers suites using RC4 or MD5.
3. (Has shown up in the latest scan). Insecure Certificate Signature Algorithm in Use: This finding indicates that SHA-1 and/or MD5 hashing algorithms have been detected during your scan.
These are showing up for ports that I have for machines that are being used for remote desktop & my terminal server. I have been reading and from what I see if i were to alter TLSv1 that remote desktop will no longer work. This is no good. We have remote offices who remote into my servers to do business. If these are known issues is Microsoft going to patch or correct these issues? Or does anyone know how I can remedy these 3 issues while keeping my terminal servers available? I see that there are third party companies that will handle CC transactions but they change a fee on top of the fee we are already being charges for excepting a cc. How do small companies that only get a handful of CC a month do this? If anyone has an information on how I can clear any of these three issues it would be much appreciated.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
More and more, I see small companies with very minor CC processing needs outsource the whole thing, because it's not worth all the trouble you're going through now. Some then pass on part of the increased cost to the consumer for making the choice to use credit, and some just absorb the fees as the cost of doing business, at least for existing clients (new clients can be told of your surcharge for accepting their CC) to maintain good will. In any case, if you compare the costs to what you have to do to be PCI Compliant, it's not worth it in many cases (especially if you factor in productivity losses from remote workers).
Also, if you think you'll ever be compliant for very long, many find that is not the case, there are periodic updates and quarterly network scans. Also, I don't think you can go back to the analog phone line swiper. That is technically processing payment on premises and therefore needs PCI compliance ("All business that store, process or transmit payment cardholder data must be PCI Compliant." https://www.pcicomplianceguide.org/pci-faqs-2/#7). Even using Square/Paypal card scanners requires compliance.
The only thing you can really do is have a third party vendor which accepts the CC directly and it is not done on your website (even in an iframe). If your domain name appears in the URL which processes the payment, your whole business must be compliant. You can email a link to a payment page that is under your account with the processor, but that's the most you can do to stay under the PCI radar.
I avoid PCI like the plague, so maybe I am missing something, but I don't think so. It's not the answer you were looking for, though, but it is worth evaluating all the costs you really incur by accepting CC.
Also, if you think you'll ever be compliant for very long, many find that is not the case, there are periodic updates and quarterly network scans. Also, I don't think you can go back to the analog phone line swiper. That is technically processing payment on premises and therefore needs PCI compliance ("All business that store, process or transmit payment cardholder data must be PCI Compliant." https://www.pcicomplianceguide.org/pci-faqs-2/#7). Even using Square/Paypal card scanners requires compliance.
The only thing you can really do is have a third party vendor which accepts the CC directly and it is not done on your website (even in an iframe). If your domain name appears in the URL which processes the payment, your whole business must be compliant. You can email a link to a payment page that is under your account with the processor, but that's the most you can do to stay under the PCI radar.
I avoid PCI like the plague, so maybe I am missing something, but I don't think so. It's not the answer you were looking for, though, but it is worth evaluating all the costs you really incur by accepting CC.
That's what I expected to hear. Although I want to add we do not do any CC processing through our website either. They actually process the CC through a bank website. myvirtualcreditcard....thr
I remember reading about several levels of compliance based on storing data, and number of transactions.
So things maybe relaxed for your number of transactions.
We had departments refuse to use the POTS line and card scanner until we held them accountable for the thousands of dollars for vlan configuration, new equipment, consulting, etc.. Then the card terminals seemed like a good fit.
So things maybe relaxed for your number of transactions.
We had departments refuse to use the POTS line and card scanner until we held them accountable for the thousands of dollars for vlan configuration, new equipment, consulting, etc.. Then the card terminals seemed like a good fit.
The other thing to keep in mind is the penalty for non-compliance, which is unusual and unlikely, but it could be a huge hit to a small business.
Is it necessary in your situation that in-house staff process the CC#, is having the customer input it themselves out of the question?
Is it necessary in your situation that in-house staff process the CC#, is having the customer input it themselves out of the question?
I do not think it is out of the question however I have to do my research. From the information I did gather a lot of these are government CC that are only good for one translation. But not all of them.
You are PCI Level 4 (the lowest actually)
Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants — regardless of acceptance channel — processing up to 1M Visa transactions per year.
https://www.pcicomplianceguide.org/pci-faqs-2/#6
I would consult a QSA for further guidance however:
https://www.pcisecuritystandards.org/approved_companies_providers/qualified_security_assessors.php
I know a QSA and he says this situation is black/white, you may not in fact need to be PCI compliant with that low of a card count, or if your 3rd party stores the CC info, and your people are simply using those cards with-in the 3rd party bank site. When you transmit card data, which is not the same as inputting it into a web-form believe it or not. Contact a QSA, have them evaluate your situation.
-rich
Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants — regardless of acceptance channel — processing up to 1M Visa transactions per year.
https://www.pcicomplianceguide.org/pci-faqs-2/#6
I would consult a QSA for further guidance however:
https://www.pcisecuritystandards.org/approved_companies_providers/qualified_security_assessors.php
I know a QSA and he says this situation is black/white, you may not in fact need to be PCI compliant with that low of a card count, or if your 3rd party stores the CC info, and your people are simply using those cards with-in the 3rd party bank site. When you transmit card data, which is not the same as inputting it into a web-form believe it or not. Contact a QSA, have them evaluate your situation.
-rich
Premium Content
You need an Expert Office subscription to comment.Start Free Trial