Answers.Body: <p>Here are the short answers:</p>
  <ol>
  <li>Yes, that's how the (legacy) iATS payment processor included in the iATS extension works.</li>
  <li>Security enhancement - not really something that can be answered responsibly with a short answer.</li>
  <li>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 &quot;PCI Compliant&quot;.</li>
  </ol>
  <p>And of course, since your title is &quot;is the iATS payment extension secure&quot;, I'd claim that it is, since I'm responsible for it. But that's a tiny piece of the real question.</p>
  <p>The last one in particular does not do justice to the questions, so here are the longer versions.</p>
  <ol>
  <li>iATS payments and cardholder data on your server</li>
  </ol>
  <p>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.</p>
  <p>iATS Payments is in the process of rolling out a new system that is expected to be &quot;better&quot; than either of these two options, where better is expected to be more secure and easier to use. What would you expect?</p>
  <ol start="2">
  <li>Generic practical steps to enhance your security</li>
  </ol>
  <p>.. 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.</p>
  <p>A few minimal things that you should do are:</p>
  <ul>
  <li>make sure you are set up to monitor and react to security releases all the way up your stack (OS and applications).</li>
  <li>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.</li>
  <li>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)</li>
  <li>monitor the site in lots of ways</li>
  </ul>
  <p>Here's the civicrm handbook's wisdom on the topic: <a href="https://docs.civicrm.org/sysadmin/en/latest/setup/security/" rel="nofollow noreferrer">https://docs.civicrm.org/sysadmin/en/latest/setup/security/</a></p>
  <ol start="3">
  <li>PCI DSS</li>
  </ol>
  <p>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 &quot;security&quot; requirements. Those requirements cover not just your website, but every aspect of your organization that is involved with handling cardholder data.</p>
  <p>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.</p>
  <p>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.</p>
  <p>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.</p>
  <p>In theory, at this time, using the iATS legacy processor means you &quot;should&quot; 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.</p>
  <p>I do recommend regular automated &quot;scans&quot;, which prod all your open ports for known &quot;weaknesses&quot;. 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.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-12-14T22:37:28.700Z
Answers.Text: Thank you for the comprehensive answer, Alan. The original question wasn't meant to throw anyone under the bus but rather to get more information about what is happening behind the scenes. Thank you. Here are some follow-up questions:
  1) Is FAPS the same as the 1st Pay system that I've heard iATS talk about? If so...
  2) We've been informed by iATS that 1st Pay isn't a good option to migrate towards because it isn't going to be supported going forward. Do you have any insights into this?
  3) Do you have any insights as to when iATS may be rolling out the new system?
Answers.UserDisplayName: J. Rolfs
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-12-15T14:49:47.167Z
Answers.Text: Yes, FAPS (our internal acronym) is the same as 1st Pay (official branded label). 1st Pay was part of the company that bought iATS Payments and they tried to use it with iATS, but it didn't integrate well with their systems (though the extension bit we added works well enough, and I use it on my site). They're claiming the new system is almost ready for prime time, so realistically, I'd say we're looking at 3 months until our first live testing and maybe 6 months before they're ready to migrate existing iATS legacy clients.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-12-15T14:52:58.040Z
Answers.Text: re: buses - no worries, I was happy to have the opportunity to answer it! Definitely a topic close to my heart. If you mark this answer as "accepted", I get my green check mark.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-12-13T22:48:36.743Z
Answers.LastActivityDate: 2023-12-13T22:48:36.743Z
Answers.UserDisplayName: Alan Dixon
Body: <p>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.</p>
  
Tags: <iats><iatspayments>
Title: Is the iATS payment extension secure?
ThreadText: # Is the iATS payment extension secure?
  
  (Asked by: username_0 on 2023-12-12)
  
  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.
  
  **Tags:** iats, iatspayments
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-12-13. Score: 1 | Accepted answer
  
  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.
  
  > **Comments:**
  > **username_0**: Thank you for the comprehensive answer, Alan. The original question wasn't meant to throw anyone under the bus but rather to get more information about what is happening behind the scenes. Thank you. Here are some follow-up questions: 1) Is FAPS the same as the 1st Pay system that I've heard iATS talk about? If so... 2) We've been informed by iATS that 1st Pay isn't a good option to migrate towards because it isn't going to be supported going forward. Do you have any insights into this? 3) Do you have any insights as to when iATS may be rolling out the new system?  
  > **username_1**: Yes, FAPS (our internal acronym) is the same as 1st Pay (official branded label). 1st Pay was part of the company that bought iATS Payments and they tried to use it with iATS, but it didn't integrate well with their systems (though the extension bit we added works well enough, and I use it on my site). They're claiming the new system is almost ready for prime time, so realistically, I'd say we're looking at 3 months until our first live testing and maybe 6 months before they're ready to migrate existing iATS legacy clients.  
  > **username_1**: re: buses - no worries, I was happy to have the opportunity to answer it! Definitely a topic close to my heart. If you mark this answer as "accepted", I get my green check mark.  
  
  ---
  
  