Is the iATS payment extension secure?

Question

We recently went through a security audit and one finding was that credit card information touches our web server before being routed to iATS. Is this how the iATS extension should work? If so, what are some practical steps that we can take to enhance our security? Do we need to be PCI compliant? Thanks.

Answer 1

Here are the short answers:

1. Yes, that's how the (legacy) iATS payment processor included in the iATS extension works.
2. Security enhancement - not really something that can be answered responsibly with a short answer.
3. Any organization that accepts credit cards (i.e. has a merchant account) has to comply with the PCI DSS (Payment Card Industry Data Security Standard). You will have agreed to that as a condition of getting your account with them. In other words, yes, you need to be "PCI Compliant".

And of course, since your title is "is the iATS payment extension secure", I'd claim that it is, since I'm responsible for it. But that's a tiny piece of the real question.

The last one in particular does not do justice to the questions, so here are the longer versions.

1. iATS payments and cardholder data on your server

The iATS CiviCRM extension provides code for 5 different 'payment processors'. Three of them are for a legacy system that accepts the card credentials to the civicrm server and then has a conversation with the payment processing server in the background. The other two use a newer system (FAPS = First American Payment System) that has a clever way of generating an iframe via javascript so that the card credentials do not actually go through your civicrm server, but instead generate a token that is passed to your server and that is used a reference to the card data that only ever lives on the payment processor server. In none of these cases does the cardholder data get written in to CiviCRM, that's a core design of CiviCRM.

iATS Payments is in the process of rolling out a new system that is expected to be "better" than either of these two options, where better is expected to be more secure and easier to use. What would you expect?

2. Generic practical steps to enhance your security

.. abound on the internet, and some of them are useful, and some of them are not, and some of them are downright terrible. I prefer to be specific and look at your current setup and see where the greatest risks are and how they can be minimized.

A few minimal things that you should do are:

• make sure you are set up to monitor and react to security releases all the way up your stack (OS and applications).
• maintain a set of minimal permissions for all authenticated users, and make sure anyone who has any kind of administrative permission (i.e. one that would enable arbitrary code execution) understands the risks associated with their account.
• no shared logins, strong passwords, using 2FA where appropriate. only install code that you reasonably expect is safe (i.e. don't install dodgy plugins)
• monitor the site in lots of ways

Here's the civicrm handbook's wisdom on the topic: https://docs.civicrm.org/sysadmin/en/latest/setup/security/

3. PCI DSS

is a very big document that covers all kinds of things, and is IMHO a way of minimizing the risks of the card mafia by pushing those risks to the merchant with a huge collection of "security" requirements. Those requirements cover not just your website, but every aspect of your organization that is involved with handling cardholder data.

Many of the requirements are reasonable, some of them are incoherent, and some of them really seem pointless to me, and e.g. appear to be based on trying to mitigate past Microsoft Windows breaches.

For smaller organizations handling not too many transactions, your process is to fill out some version of an SAQ (self-assessment questionnaire), e.g. SAQ-A, SAQ-EP, SAQ-D. The version is dependent on the role of your website in handling the cardholder data, roughly a measure of your exposure to risk.

For fully off-site processing, you can use the easiest/shortest one, SAQ-A. If you are handling and storing credit card data on your own server, you have to fill in SAQ-D.

In theory, at this time, using the iATS legacy processor means you "should" be doing the SAQ-D (this changed from the current version 3 of the standard from the previous one, I believe). But ultimately, that's a matter between you and your payment processor. In general, because iATS is specific to non-profits, they seem to bring a more practical approach to the issue.

I do recommend regular automated "scans", which prod all your open ports for known "weaknesses". They'll usually find things that aren't actually risks, but that might be advertisements to bad actors that your systems aren't being kept up to date.