Bsrgvty

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, the newest you'll see is TLSv1.3, however most websites only support up to 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).

TLDR: DON'T secure your network. Get a modern card terminal with P2PE (Point to Point Encryption) and acquirer who supports it - e.g. new-market products like Square or PayPal Here, which cost less than you think.

This transfers PCI-DSS responsibility away from you and to these billion dollar financial companies who are well equipped to handle it efficiently, at scale. Go encryption!

Complying with PCI-DSS is big work unless... (skip this)

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
  
  
  • and the WiFi bridged to 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.


• guest WiFi must be correctly set up to not be on this network

... unless you dodge it altogether, with P2PE

P2PE = Point to Point Encryption - essentially a VPN tunnel between the card reader device and the acquirer.

Square's first card reader was a simple magnetic tape head. Obviously, the Square app handled card data in the tablet. 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 P2PE. The PayPal app simply passes the data through and can't read it (and neither can anyone else).

This does not place the app, phone and network in-scope for PCI-DSS. If the acquirer guarantees the fob is secure, then all you have to do is make sure your fob has not been physically tampered with.

If all your credit card activity is via P2PE standalone devices, then you don't need to PCI-DSS your network.

P2PE is the only way to go.

But unfortunately, a lot of acquirers (particularly the kind with roving salesmen, you know the ones) have not gotten the memo. They force you to spend thousands securing your networks. Why?

Because they are super resistant to change (chip cards, heh) and P2PE requires a huge expense of back-end tech that they can get by without. And of course you, the retailer, needs to buy a new P2PE reader, which is a tough pill to swallow after just spending a bunch on chip readers.

And your acquirer sold you an obsolete jalopy; that reader dates from 2012, before P2PE became popular. See?

Look at modern payment processors like Square or PayPal Here. At first glance, they look terrible on percentage alone but there are no other fees, and that swings it back in your favor - no monthly fees, batch fees, trans fees, tiers, and the dozen or so little cuts that acquirers take. I've seen bills that claimed to be 1.4% but were actually 4.1% after all those fees/gotchas were accounted for. PayPal Here is 2.7%. Really.

Another benefit of modern acquirers is they work via Bluetooth to phones or tablets, using the tablet to ring up the sale and accept the finger-signature. This also means they can use the unbelievably cheap cellular data network access for tablets specifically ($100/year is readily available) rather than paying for commercial internet service.

And they work anywhere, so if you have roving salesmen they can swipe Visa-MC at the customer. Instead of writing down numbers for the treasurer (a whole 'nother PCI-DSS nightmare), to say nothing of declined charges!

Card Not Present (CNP) transactions

Use modern keypad P2PE devices such as PayPal Here's big reader for CNP transactions. Don't enter CNP transactions on any kind of tablet or PC or you place the PC, network, yadayada into PCI-DSS.

Alternately, minimize or outlaw CNP transactions, and convert them to billing out through PayPal etc. (which comes with PayPal Here obviously). That way the consumer is using his own device to interact with PayPal etc., and that makes PCI-DSS their problem.

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..."