What Is the PCI of Bank Payments? | Hacker News Reader

What Is the PCI of Bank Payments?

moderntreasury.com

101 pointsmattmarcus59 comments

This article recommends using SOC2 compliant vendors. I wouldn't put faith an a SOC2 certificate. A vendor who's infrastructure consists of almost entirely of hardware and software that's been EoL for years (and wasn't up-to-date before support expired) can pass SOC2, so long as they show that their firewall does NAT for security.

Okay, I'm being somewhat hyperbolic, NAT for security is not the only box a company has to tick to get a SOC2 cert. But I'm being less hyperbolic about long-EoL kit passing SOC2 audits. IMO, a vendor running unsupport(-ed|-able) kit should be an immediate disqualifier.

A lot of banks are running core banking systems on mainframes with 40+ year old software. Core banking system may get updates but the underlying technology and systems haven't been updated for decades.

Yeah, but it’s running on system Z, and if they decide it needs beefier security at the interface, they can add it pretty easily. Just like you can put TLS on the boundary of a generally insecure local system.

Legacy hardware can be fine, and in many cases better than constant replacement with new trends. There’s no such thing as EOL if you have enough money.

Sometimes computer people can be as bad as fashion snobs about wearing last seasons trends.

When was the last time you heard of actual production issues caused by sticking with legacy systems? One often hears rumors about enormous entities running on ancient hardware and software but from the public side those entities seem to be doing very well.

There is a fair amount of issues caused by ancient hardware and software, that can't be sourced anymore or the code was lost. It is a very real issue. This seemingly works fine so it gets ignored until it explodes and there is nothing that can be done about. Maybe the motherboard finally died, maybe the network stack can't speak the recent TLS stack so can't connect to anything anymore.

Hardware do die and disappear over decades. Few vendors continue to provide newer replacement at a 100 times markup (maybe IBM and mainframes) the rest is dead in the water (maybe Solaris, Titanium, AIX)

As someone who has performed SOC2 compliance reviews, these are not small tasks. I've performed them on companies that manage core banking systems for other banks and credit unions.

Currently, across quite a lot of critical infrastructure there are legacy systems which are EoL. However, there are aspects or layers to the software which are not, or are protected by higher layers of security.

If your vendors ENTIRE environment is almost EoL software and hardware then yes that is highly concerning and would make it very difficult for them to demonstrate appropriate security controls. However, the reality is that most of the environments I have assessed have only a small portion of their software/hardware environment that is EoL. That is often protected by significant layers of security above that.

Out of curiosity, when you're doing a SOC2 compliance review, are your relying on their documentation of security measures, or would you check to see that the documentation matches the security measures that are in place?

Documentation of security controls means very little, yes having a framework with a suite of policies and procedures is important. But a proper SOC 2 review is all about actually seeing it in place.

We do a deep dive, where we understand all of the security controls, we then test the design of these security controls through reviewing security configurations within the systems themselves. Then testing the effectiveness of these controls.

So yes, we review documentation and then perform an independent review of the security measures/controls in place. For instance, understanding how batch processes are configured, then testing that the appropriate security controls in relation to batch processes operated effectively.

Both usually. The auditor have a list of a thousand and they want to verify.

Not enough to say that you have a list of active devices, need to show them an inventory. Not enough to say there is authentication, need to show them that they can't access the homepage.

That is not correct. The problem with SOC reports is that it is up to the company to scope what controls they want to be tested as part of the SOC2 report. Therefore in your example, the company is unlikely to include asset management controls (EoL / EoS) as in scope for their SOC report. Companies can also choose to only include the components of controls that are known to be effective, to avoid having a qualified report.

You are right that you shouldn't just blindly put faith into an organisation because they have a SOC report. To rely on a SOC report, you need to review it in detail, and understand the controls they have tested, and look for what has been omitted.

> The security risk to bank account details is regionally specific. In Europe, IBAN and BIC numbers are readily given out. One reason why is that they are only used in the credit direction.

That's not true, IBANs can be used for direct debit between supporting banks. That's most commonly used for repeat invoices but some shops also support it as payment option for one-time purchases, although instant payments are taking over the latter use-case.

Do IBANs allow debit without reliable authorization? In the US having a bank account number (and I suppose maybe a name/street address for more plausibility) is enough to print a check and then withdraw money from it. Do IBANs let a random person do that, or do they need verification from the account?

IBAN’s are basically publicly available (like to pay bills, you just use the IBAN of the receiver, which doesnt change). So I imagine this requires authorization, otherwise everything would break.

They don’t need verification. In theory, you are supposed to have a direct debit mandate, but that is basically just a click.

If you want to take out a direct debit you need to be registered though, the process isn’t trivial and you need to deposit a security that can be used for a dispute. That makes it rather unlikely that the system is abused - though not impossible.

Probably depends on country, but in Poland direct debit is sometimes used for recurrent payments. It requires written permission of account owner, and transactions could be reversed by owner up to almost two months.

You can reclaim every amount booked(fetched) via IBAN payment for 13 month, except when you gave an valid mandate, then it's 6weeks where you can invert the payment. If you submit(wire transfer) money via bank payment though, it is up to your bank, the bank of the reciever and the reciever to ack a refund. Failed IBAN payments costs the reciever side like 10€ if they triggered it. Also i have never seen a check beeing used except for people who won a lottery or something.

In Serbia (eastern europe) a type of direct debit is realized in cooperation with the client's bank.

The service provider (this is usually used to automatically pay utility bills, rent and mobile/Internet bills) makes a "deal" with some banks, whereby the bank can store a number identifier and the service provider can tell the bank what amount to charge.

The safety part is, however, that the bank's client must obtain the identifier (usually account ID in the service provider's system) and give it to the bank, either with a written request or on the bank's online portal. Only then will the bank process the provider's charges to the client's account.

Disputes are not common and take a lot of time because an actual investigation is done, often times it is resolved in the provider's favor because the client did knowingly consent to the terms and did enter the identifier into the bank's system or give a written statement in the bank's offices.

In general, in this system it is impossible to charge someone without them agreeing that they want to be charged. If they do want to be charged however, and agree to the terms, you can charge them an unlimited amount, which they have to then dispute and provide evidence of unwanted activity. This happens rarely though, because such charges would cause extremely high fines to the service provider, due to gross negligence or malicious intent, whichever is applicable.

I do not know of any person that was "robbed"/scammed this way.

This not kind of direct debit that exists in EU zone.

Yeah, but we don't have direct debit except in one bank for business customers (B2B). Not in EU zone or EEA.

? It sounds very similar to how we domicile bills from utilities to banks in Italy, you provide the account number a document and of they go.

You missed the part about the account holder having to pass the token issued to the merchant back to the bank.

Yes they allow debit, but the other party should acquire some sort of authorization from you, even if the requirements are not strong.

The typical use case: you want to allow recurrent payment for your electric bill. You login in with your credentials on the electric company website, then you give them your IBAN and you press a button to accept the terms and authorize them. The company then checks that the name on your bill is the same as the name linked to your bank account and that's it, they are allowed to charge you.

I know that it does not seem secure, but the rate of fraud is really low, at least in my country:

- your bank send you a notification when some company activate a recurrent debit scheme on you account;

- you can see some days in advance on your home banking what you are being debited, and you can freely cancel the charge up to 8 weeks after it happened, for any reason. The chargeback is automatic;

- you have 13 month to ask for a chargeback if you believe you did not give authorization, and is the company that must prove that you really authorize them. The chargeback is automatic;

- to enable the scheme the company has to go through their bank, and the bank is responsible for the chargeback if the company does not pay. So only big and medium business are usually enabled by their banks, because they don't want chargebacks;

I always use Direct Debit. The guarantee means it's better than paying cash yet it usually comes with a discount because it's easier for the recipient too.

A utility company screwed my billing up at the last address I rented. I'd check my own meters, call up, "This bill is wrong, fix it" they'd send an engineer, the engineer says this happens a lot with a building converted from one dwelling with one meter to many dwellings with retro-fitted meters and then gutted and replaced outright with a purpose built block. They call base "You have the wrong meter for this address. Assign this meter number to the customer account instead". Next month, new bill, same mistake, same calls, rinse & repeat.

So I said "I will not pay you until you bill me for what I actually used". I called my bank, "Undo all direct debits for that utility" and they took all the money back from the utility company and gave it to me.

The utility company sent a letter threatened to sue me, I called the lawyers. They explained that the letters threatening to sue are automatic and that they understood if they show up with knowingly bogus bills they're going to lose and it'll make the judge really unhappy and they might get sanctioned as well as eating my court costs.

Eventually I'd guess maybe six months after I first noticed the error, I got a phone call from the utility company. They'd given up trying to "fix" my account, whatever stupid IT problem they had was too much. They'd opened a fresh account with my name, my address, the correct meter and a zero balance, was that OK? So I never paid them for six months of usage basically.

FWIW If you are worried this is just the honour system, which it is, be even more afraid of credit cards. Payment card settlement is entirely on the honour system and has fewer safeguards. Any merchant can present settlement paperwork saying card #123456789 agreed to pay me $8000 and your bank will by default take $8000 from the account #123456789 corresponds to.

Another HN discussion today is about EMV ("Chip and PIN") but EMV isn't part of Settlement, it's Authorisation. A merchant doesn't need any Authorisation, they can present a settlement demand with no authorisation whatsoever and by default it will get paid.

This really happens. Big merchants are 100% trusted, if the major high street supermarket chain Tesco in the UK says that every single one of its Visa card customers decided to pay twice today, no alarms go off until finally, hours or days later one of those customers wonders where all their money went and is horrified to discover Tesco took twice as much as expected. Oops! We pressed "up" too many times on the keyboard and ran the settlement process twice. No safeguards, because it's the honour system. Check your card statements, if you miss something nobody else will lift a finger.

> FWIW If you are worried this is just the honour system, which it is, be even more afraid of credit cards. Payment card settlement is entirely on the honour system and has fewer safeguards. Any merchant can present settlement paperwork saying card #123456789 agreed to pay me $8000 and your bank will by default take $8000 from the account #123456789 corresponds to.

They won't take money out of your bank account. They'll add $8000 to your credit card bill, and if you don't pay that bill they can report you to a credit bureau, cancel the card, take you to court, but you'll still have access to your money while it's all being sorted out. That's the argument for credit cards being safer.

I have a similar issue with my utility provider in London were the previous tenant didn't pay the bill and the wouldn't allow me to open a new contract on the same address until previous contract on that meter was paid.

They even went so far to send the same bills to 'occupiers of address X' trying to let me pay the £1800 electricity bill.

An IBAN by itself is just an account number. A random person obviously can't take money out of another person's account. The fact that this is possible in the US is beyond insane. I wouldn't trust a bank(ing system?) that permitted this as far as I could throw it.

No bank in the SEPA-zone will give anyone unauthorized access based on just an account number.

There are things like SEPA Direct Debit (SDD) which are basicaly mini-contracts between a creditor and a debtor -- with the banks as intermediaries. These can be used, for instance, by your ISP to automagically take your dues out of your account. Either party can cancel just about as easily as well. With most banks, they can be set up in a few clicks. Many banks support limiting the amount (e.g. 50eur/month) on a per-SDD basis.

Bacs in the UK will alert the account holder that a debit has been set up, but to set it up just requires knowing the sort code (routing number) and bank account number. Much like ACH.

The account owner can at any time go in and cancel that mandate, but they do not have to pre-approve it have it set up.

They do, but direct debit is only allowed to “large” companies that move a lot of money in my experience. Usually you have to consent to allow direct debit, sometimes in the paper form, sometimes just by entering your account number. My startup tried to add direct debit via Stripe but our bank didn’t allows us to do because we don’t move a lot of money through our banks accounts also we’re not known. I think a lot of financial things in Europe are based on trust.

Are you sure you aren’t confusing a bank transfer with direct debit? DD in the US requires PAD/PAP between the debtor and the collector and is cleared through ACH regardless of the size of the account or the sum.

No, what GP is saying absolutely is a thing, but not terribly common. Bosch PT Service is one of not that many companies that use it. You only give them your IBAN and check a box basically saying you authorize them to debit the money from your account.

That’s how Direct Debit works all over the world, that tick is the PAD/PAP contract being signed you basically pre-approve debit requests with it.

Here in Spain small companies like my accountant do it too. You can reverse it though even for large corps. Orange the telco took some amounts but cut off service (no clue why) so I had them all reversed.

> Do IBANs allow debit without reliable authorization?

I would say yes. However, unauthorized debit will be returned for max. 13 months. So the risks for the victim account are small.

The risk for the bank could be higher. However, that is mitigated by the fact that it is no longer easy to open bank accounts. Clear documentation is needed (a big problem even for completely legal immigrants, because when you are new in a country you don't have a lot of documentation). Additionally initiating direct debit bookings is not a standard service. I'd guess only accounts with a good track record will get it. Typical risk management for a bank. It's the same as they don't lend money to everyone who might ask.

In my European country checks were phased out somewhere in the mid 90s lol.

Only time I saw checks was when some American company send me a check. I think it cost me 15euro to cash in the check and the time at the bank. So next time I asked if they could pay the royalties by bank transfer. Boy, American companies weren't ready for that in the early 2000s

IBANs even in the US can only be used for transfer a direct debit doesn’t uses IBANs.

In the US a direct debit require a PAD/PAP authorization which is a binding contract and it’s cleared via ACH.

Both instant payment / transfer and direct debit work only with IBAN(+BIC) in SEPA.

Direct debit requires an authorization that’s the PAD/PAP yes it’s a click but on the backend there is a contract signed and approved, you can initiate a transfer to anyone with just an account number no approval needed.

(Post author here.)

You're absolutely right. This was an editorial mistake on my part. Edited to acknowledge the existence of schemes like SEPA Direct Debit. Thanks for pointing it out.

SEPA Direct Debit has the advantage of being instantly revokable from the customers side for six weeks after booking date, that's usually enough for any fraudulent actors to stay away. Interestingly Banks will take some of the merchants cashflow as collateral, similar to how PayPal does this, to ensure there is actually cash available for the reverse transactions if they should be initiated.

Quarterly vuln scans don’t really make the cut in the modern world. Take CVE-2020-1350 (MS DNS vuln) as an example - it took about 48 hrs from publicizing the vuln to a working exploit to appear on Github.

If you scan per quarter, and it takes you n days or weeks (or months) to fix the critical stuff, it’s quite a window of exposure - per each vuln. Any midsize org will carry hundreds or thousands. Enterprises much more.

Obligatory:

https://www.rsync.net/resources/regulatory/pci.html

Absolutely love it!

PCI compliance helps a little.

When I was doing IOT power/temperature monitoring sometimes companies wanted us to show PCI compliance before attaching our hardware to their networks. (we weren't) which meant we had to explain to them to put us on a separate network, without credit card processing devices.

PCI compliance is extremely easy if you don’t handle PANs. Provide a SAQ that says “we don’t handle PANs” and you’re compliant.

Caveat if you are small business. Otherwise, with lots of charges it costs about $100k+ annually in validation, not including labor effort. A startup can hit this quickly, but only under certain circumstances.

If you're a startup and you need PCI DSS compliance, please contact me - mahmoud [@] verygoodsecurity.com and I'd love to help!

Definitely agree from a technical perspective. But I do think it was marginally successful in translating technical risk to business risk, which is something that hadn't been done very well previously and did drive a lot of investment into 'security'.

Unfortunately the security industry somewhat predictably responded with snake oil and bullshit that were predictably countered with overpriced Big N assessments, but that's another story.

>it took about 48 hrs from publicizing the vuln to a working exploit to appear on Github.

a real one? someone was trolling with a fake one https://blog.zsec.uk/cve-2020-1350-research/

The first two were rickrolls, but around the 48h mark both an identifier scan and a DOS exploit were pushed to GH.

This is why defense-in-depth is so important. Very few companies can test and rollout a patch in a few days, and that's not even accounting for regulatory concerns that may add additional time.

Agreed. I run a product company in this area (internal threat/exploit detection) and the lack of any kind of visibilty most orgs have is concerning.

It’s partially the security industry’s fault for promoting ineffective and expensive methods as the go-to.

The point about subjecting your external vendor to the technical audit of their security services as well is a good one.

Audits and compliance only take you so far. If your actual motivations are to truly improve security, perhaps offering code samples, libraries and reference architectures would be more helpful. Throwing compliance requirements at a technical team is an excellent way to distract them away from a truly secure architecture.

That said, there are a lot of actors out there who need babysitting and absolutely should not be allowed to participate in payment networks without some sort of initial & ongoing due diligence.

This whole thing is a delicate balancing act, but in my experience dealing with PCI-DSS, its currently an extremely heavy-handed approach. I cannot help but wonder if the primary intent of this sort of standard isn't to just keep competitors out.

Ad for Modern Treasury.

The NACHA response is missing the forest for the trees. Securing the account data is great, but it's only a small piece of the puzzle.

It doesn't: a) penalize ACH Originators responsible for submitting the fraudulent entry (beyond the recently implemented $4.50 charge) b) do anything to promote alternative account numbers for EFTs, which in theory could be better protected as they won't be on paper checks c) promote better validation tools to prevent the likes of Plaid and entities using their APIs from harvesting broad amounts of private consumer financial data

How about two-factor authentication as a baseline recommendation for online ACH? Even the infamously recently discussed SMS authentication.

ACH is a ca 24 hour duration batch process that does not include authentication. 2fa isn’t even really a possibility with the ACH system.

That was kind of done in Mexico with the CoDi system.

But yeah ACH is so old and crappy that nothing can fix it.

Reply on news.ycombinator.com