Xjyuk

We are a brick and mortar company... literally. We are brick masons. At our office we connect to the internet through our cable modem provided to us by Spectrum Business.

Our Treasurer uses a Verifone vx520 card reader to process credit card payments. It connects via ethernet. We don't store credit card data.

We got a vulnerability report stating that we were not PCI compliant.

They scanned our cable modem.

Part 2b-1. 38173 - SSL Certificate - Signature Verification Failed Vulnerability
Part 2b-6. 38628 - SSL/TLS Server supports TLSv1.0
Part 2b-7. 38601 - SSL/TLS use of weak RC4(Arcfour) cipher (CVE-2013-2566, CVE-2015-2808)

I don't understand what they mean. We don't have a server or an online store or anything. I was told they scanned our network and this is what they found. They told us to get with ISP to fix issue.

How is the ISP supposed to get an SSL certificate installed on a cable modem? I did call our ISP and he didn't know what to tell me.

We just use the card reader and it connects to our payment processor.

Am I supposed to do something here? Is any of this applicable to us?

At our office with connect to the internet through our cable modem
provided to us by Spectrum Business.

Our Treasurer uses a verifone vx520 card reader to process credit card
payments. It connects via ethernet. We don't store credit card data.

It sounds like you fall under SAQ B-IP (and you will be amused that the mnemonic is that "SAQ B-for-Brick-and-Mortar"):

SAQ B-IP has been developed to address requirements applicable to
merchants who process cardholder data only via standalone,
PTS-approved point-of-interaction (POI) devices with an IP connection
to the payment processor

It sounds like someone did an external ASV ("Approved Scanning Vendor") scan on your known IP address and found the cable modem was, unsurprisingly, not up to snuff.

Am I suppose to do something here? Is any of this applicable to us?

Yes, this is applicable to you, and many other things besides, all of which are outlined in the Self Assessment Questionnaire linked above. And if your other office systems - desktops, printers, whatever - are also sitting on the same network behind that cable modem, then the requirements of the SAQ apply to those as well. Things like patching and access controls.

For now, you will need to continue to work with your ISP. They either need to update the modem, upgrade it, or get it to stop accepting connections from the Internet at large.

To break down those error messages for you:

Part 2b-1. 38173 - SSL Certificate - Signature Verification Failed Vulnerability

There's likely a self-signed certificate on that device, common for things like cable modems that need TLS but don't care about being trusted by random users. (PCI cares, though, even when users don't).

Part 2b-6. 38628 - SSL/TLS Server supports TLSv1.0 

When you go to a secure web site today, it's usually TLSv1.2 or TLSv1.1. TLSv1.0 is old, relatively insecure, and PCI declared it unacceptable to use a few years ago.

Part 2b-7. 38601 - SSL/TLS use of weak RC4(Arcfour) cipher (CVE-2013-2566, CVE-2015-2808)

TLS gets to pick from multiple algorithms; over time, weaknesses are found and individual algorithms get retired because of it. RC4 got retired a few years ago.

Since you are physically handling cards, and sending that card data across a network to your card processor, you do need to secure your network. Besides just being compliant in order to get auditors off your case, if someone sneaks a program into your network, it might be able to eavesdrop on the rest of the network and steal that card data.

Based on your question and comments, some computer in your network has a web server that is publicly responding to requests.

It is most likely the cable modem/router itself, and the web server is part of a remote management console -- It allows you or your ISP to change settings without needing to be inside of the network. It also allows anyone else in the world to change settings, as well, though.

The error message that you're getting is saying SSL/TLS Server supports TLSv1.0, (among a couple other errors) which means that the web server is using security settings that are several years old. This is what your card processor is complaining about -- That web server is just too old and there are several known vulnerabilities.

However, your most critical problem is that there is a remote management console that is available to the public. People can guess the login information at their leisure and gain access to your internal network. When you turn off remote management in your modem, your card processor should be able to scan your network and won't be able to see anything at all, and you'll be back in PCI compliance (assuming that you were in compliance before).

In the big picture, the problem is that internet-connected devices face a lot of security threats. The other answers give good tips to address the specific issues that were detected this time.

On the other hand, if you'd prefer to stay out of that whole mess, you could downgrade to a standalone payment terminal that uses an analog phone line and doesn't touch the internet. It may not avoid all possible security problems, especially in the long term, but for now it will move you back from SAQ B-IP to SAQ B:

SAQ B: "...Standalone, dial-out terminals..."

SAQ B-IP: "...standalone...terminals with an IP connection..."

The advantages of moving to a dial-out terminal using an analog phone line are:

• It takes your modem and other internet-connected devices out of the picture


• You're less likely to be affected by new PCI security requirements


• You're less likely to be affected by some future internet-based credit card security breach

The disadvantages are:

• It might not be supported by your current payment processor (ask them)


• It requires a regular analog phone line, not VOIP or anything like that

EDIT: After reading Harper's answer recommending P2PE, I now think it's a bad idea for any regular brick-and-mortar business to try to address its own SAQ B-IP issues as suggested by other answers. Trying to keep up with SAQ B-IP is simply too risky. A regular brick-and-mortar business should only use solutions under SAQ B (dial-out terminals) or SAQ P2PE-HW:

SAQ P2PE-HW: "...terminals...managed by a validated, PCI SSC-listed P2PE solution..."

TLDR: that card reader stinks, and exposes you to all sorts of liability. Get a modern card terminal with P2PE.

You need to comply with PCI... unless...

PCI-DSS is serious business. Most small businesses do not have a breach. But if you do have a breach (which would most likely be crackers surveilling your credit card transactions for an extended period of time), you'll need to pay extremely painful penalties that have a (the figure I've heard is 90%) chance of bankrupting your small business.

What is in scope for PCI is

• your card terminal


• the network it's on


• every PC, wait, device that can access that network
  
  
  • including IoT: security cameras, Sense power monitor, and every silly WiFi-enabled gadget you bought on a lark and forgot all about
  
  


• every network that can access that network, and


• every PC, er, device on those networks.

... unless you avoid the entire issue with P2PE

If the data going through your app, PC, phone or network is all encrypted with strong encryption, then PCI-DSS doesn't apply to it. This is a very useful escape!

When Square came out with the first card reader for proprietorship sized businesses, it was a simple magnetic tape head. Obviously, the Square app handled card data "in the clear". That placed the app, phone/tablet, network etc. in scope for PCI-DSS.

PayPal Here put an encryption processor inside the scanner fob itself. The fob itself talks to PayPal servers, via Point to Point Encryption (P2PE, or as we call it, a "secure VPN"). The PayPal app simply relays the encrypted data, and it cannot know what it says (and neither can anyone else). If everything checks out, PayPal servers tell the PayPal app "approved".

Because the app, phone and network see only encrypted data, that does not place them in scope of PCI-DSS. All you have to do is make sure your fob has not been physically tampered with.

Consequences of a breach

• A PCI audit, upfront, even if you are proved to be innocent


• The fraudulent transactions themselves, if you are guilty


• The cost of reissuing credit cards to all the customers


• Penalties

I've heard statistics that a breach and the consequences about 90% of affected small businesses into bankruptcy. It nearly did in Target, after all!

Needless to say, P2PE is not only a smart way to go, it's the only way to go, in my book.

Why isn't every acquirer supporting P2PE and even making you use it? Because the industry kinda sucks that way, and a rapid switch-over will break a lot of larger businesses that do things with credit card data (think: Home Depot's ability to find your receipts and do returns based solely on your credit card number). They took over 10 years to adopt chip, and they'll probably take another 10 to adopt P2PE. This is one reason I do not like the traditional acquirer model. That, and their prices.