107

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?

John Deters
  • 33,650
  • 3
  • 57
  • 110
user3512967
  • 793
  • 2
  • 5
  • 6
  • 6
    Have you tried putting your public IP address into your web browser's address bar to see if it will connect to anything? Try with both "`http://1.1.1.1`" and "`https://1.1.1.1`" (note the S in the second URL). – Ghedipunk Aug 01 '19 at 23:04
  • 6
    Also, since you are running credit cards that are physically located at your office, you do need to secure your network to be PCI compliant. This will probably just be configuring a firewall on your modem/router, though I'm putting off making an answer to this question depending on what you'd see from trying to bring up your IP address in your browser. – Ghedipunk Aug 01 '19 at 23:08
  • 1
    I typed our IP into a browser. Got prompted for a username password. We have a centos file server behind a firewall. Private network that is not publicly accessible. We don't store credit card data. Why would an SSL certificate be needed if it isn't accessed publicly. – user3512967 Aug 01 '19 at 23:20
  • 27
    @user3512967 that cert and user prompt is almost certainly to log in and control the modem itself. It really shouldn't be exposed to the Internet at large. – gowenfawr Aug 01 '19 at 23:25
  • 12
    "Also, since you are running credit cards that are physically located at your office, you do need to secure your network to be PCI compliant." That depends on the card terminal, the good terminal providers works hard to keep the stores network out-of-scope for PCI. – Mattias Aug 02 '19 at 08:43
  • 1
    @user3512967 A quick solution would be to ask your ISP to switch your modem to bridge mode, then get a dedicated device to act as a firewall (e.g. server with pfSense). That way, the modem doesn't do anything aside from translate e.g. fiber optic to Ethernet. Your new device would then handle the networking stuff, with you fully controlling it (e.g. you getting an SSL certificate and installing it on pfSense, or disabling access from WAN side, etc.). – Aloha Aug 02 '19 at 11:52
  • 4
    I think the current answers are kind of lacking on the non-technical side. The non-technical side is that the information you got from the security people is probably right, i.e. it's your ISPs fault. So you should continue to bug your ISP until they have someone look at the problem who understands the problem. The ISP might decide to cancel your contract instead, but hopefully you should be able to find an ISP that is willing to provide you with a secure connection. – Nobody Aug 02 '19 at 12:15
  • FYI, when someone does that kind of test (browsing a server that responds to the IP address of the network itself), one must make sure that the test is run from outside the network (from home or on a mobile phone with data) as many network setups will not allow NAT loopback unless they explicitly require it. – sleblanc Aug 02 '19 at 14:05
  • 34
    From whom did you get this report? Were they trying to sell you something to fix it? – Kevin Aug 02 '19 at 15:02
  • 2
    It is worth noting that most (all?) internet routers do include a web server, so that you can manage the settings. Even a [WiFi Coffee maker](https://www.slashgear.com/smarters-wifi-coffee-maker-adds-caffeine-to-iot-05361984/) will have a server running on it, so that it can respond to the user's actions. – jpaugh Aug 02 '19 at 19:28
  • In addition to everything else that was said, if you have WIFI that is not secure someone can use that to get to your network. If you have credit card transactions going across your network, you need to make sure that your network is secure. You may want to hire someone to set up a more secure network. Including business grade WIFI if you need it, and a firewall router. – Gandolf989 Aug 02 '19 at 20:19
  • 1
    The provider of your reader should be able to tell you whether your network is in scope or not. It depends on a lot of details only they would know. It is entirely possible that the network the card reader is connected to is in scope and must meet the compliance requirements. – David Schwartz Aug 02 '19 at 22:54
  • Do you own the card reader / payment terminal or do you lease it from the payment provider? If leased, ask them for an upgraded terminal - even a cellular one might help here. – Criggie Aug 02 '19 at 22:59
  • 5
    Why did you write "I don't even have a server" in your title when your comment discloses "We have a centos file server behind a firewall."??!? You not only need to upgrade your payment processing to end-to-end encryption, you also need to get the vulnerable modem fixed or one day you may find your firewall is compromised after the modem spent the last 27 months making continuous brute-force login attempts at LAN speed. – Ben Voigt Aug 03 '19 at 15:25
  • 1
    all you need is a better modem, unless your modem can be configured to block all incoming connections, in which case all you need is to configure your modem. – user1067003 Aug 04 '19 at 20:31

5 Answers5

107

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.

Avamander
  • 117
  • 6
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 7
    If the verifone and processor were P2PE-certified, would that remove the whole store network from scope? I’m not very familiar with B, but my impression is that if the device is encrypting everything then there is no “card data environment”, so presumably most questions wouldn’t apply. But I have no idea if that’s how it actually works for a location like this. – Bobson Aug 02 '19 at 00:48
  • 2
    @Bobson I don't think so; see Q4 of the [P2PE FAQ](https://www.pcisecuritystandards.org/documents/P2PE_v1_1_FAQs_Aug2012.pdf). But IANAQSA! – gowenfawr Aug 02 '19 at 00:58
  • 52
    RC4 may have been _officially_ retired only a few years ago, but it was discovered to be broken literally hours after it was published in public, in the 90s. It's only through incompetence that it was used for so long. – forest Aug 02 '19 at 06:15
  • 12
    RC4 should be called "poor man's plaintext" – Hagen von Eitzen Aug 02 '19 at 12:12
  • 3
    @Bobson you would have to do SAQ-P2PE instead, which has far fewer requirements than B-IP (and doesn't have the ASV scan, or really anything related to your network). – rbsec Aug 02 '19 at 14:46
  • 3
    A note: "CVE" are the serial numbers we use for security weaknesses. So "CVE-2013-2566" was the 2566th security weakness filed in 2013. – lynn Aug 02 '19 at 15:53
  • 3
    @gowenfawr Thank you so much for helping make my local more security aware! – jpaugh Aug 02 '19 at 19:25
32

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

Ghedipunk
  • 5,766
  • 2
  • 23
  • 34
  • 1
    "it might be able to eavesdrop on the rest of the network and steal that card data" - card processing isn't my thing, but I assumed they would be robust to that threat. – Flexo Aug 04 '19 at 01:43
24

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?

enter image description here

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.

Harper - Reinstate Monica
  • 3,101
  • 10
  • 17
  • This seems to be the simplest solution --- many card readers are simply just that (i.e., "readers!"), not necessarily doing any "encryption" on their end either! – ManRow Aug 03 '19 at 22:40
  • This is 100% the answer. Hoping for a fix from an ISP who doesn't know how to fix obsolete, SSL errors on *their* equipment is a recipe for disaster. Disasters should be removed from the equation. :) – dannysauer Sep 27 '19 at 15:18
11

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

Community
  • 1
Krubo
  • 789
  • 5
  • 9
  • 5
    Disadvantage three: unless you add a phone line just for that, you’ll have customers standing around waiting (or leaving in a huff) while you’re phone line is busy doing something else. (I once waited many minutes for a card transaction while someone else was trying to decide what to do at an ATM dialing out on the store’s only line!) – WGroleau Aug 02 '19 at 14:16
  • @WGroleau the vendor would probably have to get a phone line (a physical wire) installed for him if he want to use an analog phone for dial-up these days. In some places it might not even be available. I doubt he will have trouble with a blocked phone line. Of course YMMV depending on your country and province. – Mindwin Aug 02 '19 at 17:17
  • Indeed. My incident was less than three years ago. – WGroleau Aug 02 '19 at 19:50
  • 3
    Where I'm from a lot of shops use mobile (GSM/3G/4G) payment terminals connected directly to the internet. In such cases I assume the vendor/manufacturer is responsible for PCI compliance. You do need to pay for a data plan for the sim card though. – slebetman Aug 03 '19 at 03:14
  • Saying "Trying to keep up with SAQ B-IP is simply too risky" is like saying "PCI compliance is too hard for merchants to meet and maintain." I'm not saying either statement is wrong, mind you, but let's be aware we're surrendering when we do it. – gowenfawr Aug 03 '19 at 20:34
  • 1
    @gowenfawr: The two are not equivalent, though. The whole point of Krubo's answer is that you don't have to care about "If you are sending card data over the public internet, PCI compliance is too hard for merchants to meet and maintain." when not using the internet for the connection. – Ben Voigt Aug 04 '19 at 00:55
1

If user3512967's modem is like mine, then hardening the web interface's TLS settings is pointless. My Cisco EPC3212 has an interface that is accessible from within the LAN via HTTP only. It has login credentials that can be googled and cannot be changed. Even if it were served via TLS (weak or strong), my network would not be more secure. Public knowledge cannot be undisclosed.

So my question is: Does user3512967's modem's interface offer restriction-worthy control or confidential information that is not accessible via public knowledge? If it does not, then fixing it's TLS does not solve anything.

Damian
  • 11
  • 1