New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement a PCI self-assessment program #214

Closed
chadwhitacre opened this Issue May 29, 2015 · 31 comments

Comments

Projects
None yet
1 participant
@chadwhitacre
Contributor

chadwhitacre commented May 29, 2015

We don't store credit card numbers, but we are planning to store bank account information as well as identity verification information. We should implement a PCI self-assessment program. We would have to do this in order to receive bank info from Balanced (gratipay/gratipay.com#3379), and we should do this anyway because, while not perfect, it's an industry best practice and a good starting point for us.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 29, 2015

Contributor

This should include:

  • SAQ A for our systems that interface with Braintree for credit card processing
  • SAQ D for our systems that transmit and store bank account and identity information

Here are the PCI SAQ Instructions and Guidelines.

Contributor

chadwhitacre commented May 29, 2015

This should include:

  • SAQ A for our systems that interface with Braintree for credit card processing
  • SAQ D for our systems that transmit and store bank account and identity information

Here are the PCI SAQ Instructions and Guidelines.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

The first step of a PCI DSS assessment is to accurately determine the scope of the review.

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

Contributor

chadwhitacre commented Jun 1, 2015

The first step of a PCI DSS assessment is to accurately determine the scope of the review.

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.

Contributor

chadwhitacre commented Jun 1, 2015

To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

CDE = cardholder data environment

Contributor

chadwhitacre commented Jun 1, 2015

CDE = cardholder data environment

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

Is my laptop part of the CDE?

Contributor

chadwhitacre commented Jun 1, 2015

Is my laptop part of the CDE?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

Re: AWS, Heroku, DO:

There are two options for third-party service providers to validate compliance:

  1. They can undergo a PCI DSS assessment on their own and provide evidence to their customers to demonstrate their compliance; or
  2. If they do not undergo their own PCI DSS assessment, they will need to have their services reviewed during the course of each of their customers’ PCI DSS assessments.

If the third party undergoes their own PCI DSS assessment, they should provide sufficient evidence to their customers to verify that the scope of the service provider’s PCI DSS assessment covered the services applicable to the customer and that the relevant PCI DSS requirements were examined and determined to be in place.

Contributor

chadwhitacre commented Jun 1, 2015

Re: AWS, Heroku, DO:

There are two options for third-party service providers to validate compliance:

  1. They can undergo a PCI DSS assessment on their own and provide evidence to their customers to demonstrate their compliance; or
  2. If they do not undergo their own PCI DSS assessment, they will need to have their services reviewed during the course of each of their customers’ PCI DSS assessments.

If the third party undergoes their own PCI DSS assessment, they should provide sufficient evidence to their customers to verify that the scope of the service provider’s PCI DSS assessment covered the services applicable to the customer and that the relevant PCI DSS requirements were examined and determined to be in place.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor
PCI DSS Assessment Process
  1. Confirm the scope of the PCI DSS assessment.
  2. Perform the PCI DSS assessment of the environment, following the testing procedures for each requirement.
  3. If required, perform remediation for any not-in-place items.
  4. Complete the applicable report for the assessment (i.e., Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)[)], including documentation of all compensating controls, according to the applicable PCI guidance and instructions.
  5. Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Attestations of Compliance are available on the PCI SSC website.
  6. Submit the SAQ or ROC, and the Attestation of Compliance, along with any other requested documentation—such as ASV scan reports— to the acquirer (for merchants) or to the payment brand or other requester (for service providers).
Contributor

chadwhitacre commented Jun 1, 2015

PCI DSS Assessment Process
  1. Confirm the scope of the PCI DSS assessment.
  2. Perform the PCI DSS assessment of the environment, following the testing procedures for each requirement.
  3. If required, perform remediation for any not-in-place items.
  4. Complete the applicable report for the assessment (i.e., Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)[)], including documentation of all compensating controls, according to the applicable PCI guidance and instructions.
  5. Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Attestations of Compliance are available on the PCI SSC website.
  6. Submit the SAQ or ROC, and the Attestation of Compliance, along with any other requested documentation—such as ASV scan reports— to the acquirer (for merchants) or to the payment brand or other requester (for service providers).
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

I requested a quote for quarterly scanning from 403 Labs, whom I discovered from https://spreedly.com/files/asv-scan-aoc.pdf.

Contributor

chadwhitacre commented Jun 1, 2015

I requested a quote for quarterly scanning from 403 Labs, whom I discovered from https://spreedly.com/files/asv-scan-aoc.pdf.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

_Note:_ PCI DSS requirements are not considered to be in place if controls are not yet implemented or are scheduled to be completed at a future date.

Contributor

chadwhitacre commented Jun 1, 2015

_Note:_ PCI DSS requirements are not considered to be in place if controls are not yet implemented or are scheduled to be completed at a future date.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

Re: AWS, Heroku, DO:

Oooooooh ... MaxCDN? 😞

Contributor

chadwhitacre commented Jun 1, 2015

Re: AWS, Heroku, DO:

Oooooooh ... MaxCDN? 😞

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

Is my laptop part of the CDE?

Here we go:

1.4 Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network.

And:

Portable computing devices that are allowed to connect to the Internet from outside the corporate firewall are more vulnerable to Internet-based threats. Use of a personal firewall helps to protect devices from Internet-based attacks, which could use the device to gain access the organization’s systems and data once the device is re-connected to the network.

The specific firewall configuration settings are determined by the organization.

_Note:_ The intent of this requirement applies to employee-owned and company-owned computers. Systems that cannot be managed by corporate policy introduce weaknesses to the perimeter and provide opportunities that malicious individuals may exploit. Allowing untrusted systems to connect to an organization’s network could result in access being granted to attackers and other malicious users.

Contributor

chadwhitacre commented Jun 1, 2015

Is my laptop part of the CDE?

Here we go:

1.4 Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network.

And:

Portable computing devices that are allowed to connect to the Internet from outside the corporate firewall are more vulnerable to Internet-based threats. Use of a personal firewall helps to protect devices from Internet-based attacks, which could use the device to gain access the organization’s systems and data once the device is re-connected to the network.

The specific firewall configuration settings are determined by the organization.

_Note:_ The intent of this requirement applies to employee-owned and company-owned computers. Systems that cannot be managed by corporate policy introduce weaknesses to the perimeter and provide opportunities that malicious individuals may exploit. Allowing untrusted systems to connect to an organization’s network could result in access being granted to attackers and other malicious users.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

Code-review results are reviewed and approved by management prior to release.

6.3.2

Contributor

chadwhitacre commented Jun 1, 2015

Code-review results are reviewed and approved by management prior to release.

6.3.2

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

_Note:_ The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

Contributor

chadwhitacre commented Jun 1, 2015

_Note:_ The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:

  • Something you know, such as a password or passphrase
  • Something you have, such as a token device or smart card
  • Something you are, such as a biometric.

Aaaaaaaaaaand scope may have just creeped to include gratipay/gratipay.com#1052. 😩

Contributor

chadwhitacre commented Jun 1, 2015

8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:

  • Something you know, such as a password or passphrase
  • Something you have, such as a token device or smart card
  • Something you are, such as a biometric.

Aaaaaaaaaaand scope may have just creeped to include gratipay/gratipay.com#1052. 😩

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

  • All user access to, user queries of, and user actions on databases are through programmatic methods.
  • Only database administrators have the ability to directly access or query databases.
  • Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
Contributor

chadwhitacre commented Jun 1, 2015

8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

  • All user access to, user queries of, and user actions on databases are through programmatic methods.
  • Only database administrators have the ability to directly access or query databases.
  • Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

12.3 Develop usage policies for critical technologies and define proper use of these technologies.

_Note:_ Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.

Contributor

chadwhitacre commented Jun 1, 2015

12.3 Develop usage policies for critical technologies and define proper use of these technologies.

_Note:_ Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

Guidance on 12.8.4, re: third-party providers (e.g., Heroku, AWS, etc.):

The intent is for the assessed entity to understand which PCI DSS requirements their providers have agreed to meet.

Contributor

chadwhitacre commented Jun 1, 2015

Guidance on 12.8.4, re: third-party providers (e.g., Heroku, AWS, etc.):

The intent is for the assessed entity to understand which PCI DSS requirements their providers have agreed to meet.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

_Note:_ Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.

Contributor

chadwhitacre commented Jun 1, 2015

_Note:_ Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 1, 2015

Contributor

Okay! Finished a first pass through the spec. 🏊

Contributor

chadwhitacre commented Jun 1, 2015

Okay! Finished a first pass through the spec. 🏊

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 2, 2015

Contributor

From: 403 Labs

Thank you for your interest in 403 Labs. I have included some pricing below as well as some information on our scanning engine. Of course, if you have any questions I would be happy to answer them.

[snip]

To: 403 Labs

Thanks for getting back to me, []. We'd probably go with the [] option.

One odd requirement in our case: we publish our finances. Is 403lab's pricing something we can publish on that spreadsheet?

https://gratipay.freshdesk.com/helpdesk/tickets/2253

Contributor

chadwhitacre commented Jun 2, 2015

From: 403 Labs

Thank you for your interest in 403 Labs. I have included some pricing below as well as some information on our scanning engine. Of course, if you have any questions I would be happy to answer them.

[snip]

To: 403 Labs

Thanks for getting back to me, []. We'd probably go with the [] option.

One odd requirement in our case: we publish our finances. Is 403lab's pricing something we can publish on that spreadsheet?

https://gratipay.freshdesk.com/helpdesk/tickets/2253

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 2, 2015

Contributor

We always strive to be transparent in the pricing of all our services. You can publish the pricing of our scanning subscription as part of your spreadsheet.

Contributor

chadwhitacre commented Jun 2, 2015

We always strive to be transparent in the pricing of all our services. You can publish the pricing of our scanning subscription as part of your spreadsheet.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 2, 2015

Contributor

The vulnerability scanning is priced based on annual subscriptions. The subscription includes the required external vulnerability scanning, access to our enhanced online PCI Self-Assessment Questionnaire and support through our toll free number and email ticketing system.

For quarterly vulnerability scans (4 scans a year plus free ad hoc scans if you have a vulnerability that you need to prove has been corrected), the cost for up to 6 IP’s is $499/year. Quarterly scanning is the minimum to meet PCI compliance requirements.

For a minimal amount more, ($599/year) we'd recommend scanning on a monthly basis which allows you 8 more scans for the small increase in price. Quarterly scanning can present too much elapsed time between vulnerability tests. An estimated 8,000 new vulnerabilities were discovered in 2014, an average of over 20 each day! For either option, should you encounter problems that need fixing in order to become compliant, additional scans to check those problems are free of charge.

You can also save 20% off either of the above prices by signing up for a 3-year subscription. Since PCI compliance will be an ongoing cost for your business moving forward, this gives you the opportunity to save some of that cost. It also allows you to “lock-in” today’s rates for the next three years.

About Our Vulnerability Management:

All of our scanning is done remotely from our testing system. You will be able to use our self-service web interface to define the IP addresses to be tested and when the testing will be performed. Our scanning engine then checks each host for over 65,000 different potential security vulnerabilities. This number is constantly growing as we check for new vulnerabilities on a daily basis.

When each test is complete you can log on to our system to review the results and print reports of your compliance status. Our reporting allows you to run trending analyses on individual IPs as well as specific vulnerabilities. You also have the ability to add comments for each vulnerability which are included in the final report. The reports will outline each vulnerability in detail including remedies on how to fix the vulnerability as well as links to external sources where you can gather even more information on that specific vulnerability. In the event there are vulnerabilities that need to be addressed, we offer the ability to retest systems, at no additional cost, until they are in compliance with the PCI standards.

By using our web interface you may also complete the PCI Self-Assessment Questionnaire that is required as part of the PCI Data Security Standard compliance verification. Our system is a single portal that enables you to quickly view your PCI compliance status. The interface also allows you to schedule scans, monitor their progress in real time and even pause or stop them completely with the click of a button should a crisis arise on your end and you need the full bandwidth of your systems.

The next step would be for you to let me know the frequency of scans that you would like as well as the single or three-year agreement. Once I have that information, I will then prepare a registration link for you to sign up online. You can pay by credit card right online or we can invoice you, whatever is easier for you. Your scans can then begin the same day that you register if you would like. If you have any questions, please don’t hesitate to contact me.

Contributor

chadwhitacre commented Jun 2, 2015

The vulnerability scanning is priced based on annual subscriptions. The subscription includes the required external vulnerability scanning, access to our enhanced online PCI Self-Assessment Questionnaire and support through our toll free number and email ticketing system.

For quarterly vulnerability scans (4 scans a year plus free ad hoc scans if you have a vulnerability that you need to prove has been corrected), the cost for up to 6 IP’s is $499/year. Quarterly scanning is the minimum to meet PCI compliance requirements.

For a minimal amount more, ($599/year) we'd recommend scanning on a monthly basis which allows you 8 more scans for the small increase in price. Quarterly scanning can present too much elapsed time between vulnerability tests. An estimated 8,000 new vulnerabilities were discovered in 2014, an average of over 20 each day! For either option, should you encounter problems that need fixing in order to become compliant, additional scans to check those problems are free of charge.

You can also save 20% off either of the above prices by signing up for a 3-year subscription. Since PCI compliance will be an ongoing cost for your business moving forward, this gives you the opportunity to save some of that cost. It also allows you to “lock-in” today’s rates for the next three years.

About Our Vulnerability Management:

All of our scanning is done remotely from our testing system. You will be able to use our self-service web interface to define the IP addresses to be tested and when the testing will be performed. Our scanning engine then checks each host for over 65,000 different potential security vulnerabilities. This number is constantly growing as we check for new vulnerabilities on a daily basis.

When each test is complete you can log on to our system to review the results and print reports of your compliance status. Our reporting allows you to run trending analyses on individual IPs as well as specific vulnerabilities. You also have the ability to add comments for each vulnerability which are included in the final report. The reports will outline each vulnerability in detail including remedies on how to fix the vulnerability as well as links to external sources where you can gather even more information on that specific vulnerability. In the event there are vulnerabilities that need to be addressed, we offer the ability to retest systems, at no additional cost, until they are in compliance with the PCI standards.

By using our web interface you may also complete the PCI Self-Assessment Questionnaire that is required as part of the PCI Data Security Standard compliance verification. Our system is a single portal that enables you to quickly view your PCI compliance status. The interface also allows you to schedule scans, monitor their progress in real time and even pause or stop them completely with the click of a button should a crisis arise on your end and you need the full bandwidth of your systems.

The next step would be for you to let me know the frequency of scans that you would like as well as the single or three-year agreement. Once I have that information, I will then prepare a registration link for you to sign up online. You can pay by credit card right online or we can invoice you, whatever is easier for you. Your scans can then begin the same day that you register if you would like. If you have any questions, please don’t hesitate to contact me.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 3, 2015

Contributor

From: 403 Labs

There is no additional charge for access to the online SAQ. I have included a link below which will take you to our registration portal for the scanning subscription. It is structured for quarterly scanning of up to six hosts for PCI compliance.

To: 403 Labs

Thanks, []. One big question we have is defining our compliance scope. Any chance you'd be up for a call to help us understand how to architect our application to keep scope to a minimum? That's actually a pretty significant consideration for the feasibility of this project for us, so ideally it's a question we could answer before we commit financially.

Do any of these times work for you for a call?

Wednesday, June 3 (today) at 10am US/Eastern
Thursday, June 4 at 10am
Thursday, June 4 at 2pm

Contributor

chadwhitacre commented Jun 3, 2015

From: 403 Labs

There is no additional charge for access to the online SAQ. I have included a link below which will take you to our registration portal for the scanning subscription. It is structured for quarterly scanning of up to six hosts for PCI compliance.

To: 403 Labs

Thanks, []. One big question we have is defining our compliance scope. Any chance you'd be up for a call to help us understand how to architect our application to keep scope to a minimum? That's actually a pretty significant consideration for the feasibility of this project for us, so ideally it's a question we could answer before we commit financially.

Do any of these times work for you for a call?

Wednesday, June 3 (today) at 10am US/Eastern
Thursday, June 4 at 10am
Thursday, June 4 at 2pm

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 3, 2015

Contributor

To: press@pcisecuritystandards.org (per)
Subject: add to press release list?

May I ask if you would add this email address [security@gratipay.com] to the PCI Security Standards Council's press release mailing list? We are a company newly implementing PCI DSS and would like to stay up to date with news, especially changes to the standards.

Thanks!

Contributor

chadwhitacre commented Jun 3, 2015

To: press@pcisecuritystandards.org (per)
Subject: add to press release list?

May I ask if you would add this email address [security@gratipay.com] to the PCI Security Standards Council's press release mailing list? We are a company newly implementing PCI DSS and would like to stay up to date with news, especially changes to the standards.

Thanks!

@chadwhitacre chadwhitacre referenced this issue Jun 4, 2015

Closed

Radar 9 #224

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 4, 2015

Contributor

One of the major changes in PCI DSS 3.0 is that applications that host payment detail forms are subject to more stringent requirements, even if they never POST to their own server. This is significant, because it erodes the value proposition—"no-fuss PCI compliance!"—of all of the third-party payments APIs, including Balanced, Braintree, Stripe, etc. The only way to qualify for the easiest SAQ, SAQ A, is to collect payment details on an off-site page (whether in an iframe or as a redirect). There is no more easy white-labeling.

<sidebar>

Incidentally, while Braintree seems to be honoring these new rules, it turns out that Stripe is bending the rules to the point of breaking: they've convinced their qualified security assessor [QSA] "and others" to let them get away with simply building an iframe in JavaScript:

We’ve been working with our Qualified Security Assessor and others to update Stripe.js to meet the new requirements and security constraints, while still keeping it simple to use. The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe. This in turn allows our customers to continue to be eligible for SAQ-A (the older questionnaire) in most cases.

That's baloney-noodles. "To be eligible for PCI DSS v3 SAQ-A, the e-commerce environment must be fully outsourced such that: 'The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).'" Yet Stripe instructs their users to collect payment details on a form of their own construction:

Before we get to the first step, let's take a quick look at a typical payment form. This is the part you can build with your web framework, or by hand in HTML — however you're used to building forms on the web.

Stripe clearly is advising their customers to violate PCI DSS v3, by using Stripe.js without submitting to SAQ A-EP.

Now, on the other side, PCI SSC's reasoning for allowing iframes while disallowing direct POST is suspect: any attacker that could silently siphon off credit cards from a POST flow could also silently siphon off cards from an iframe flow, by doing what Stripe is doing: programmatically constructing an iframe and submitting it to the third-party payments provider.

</sidebar>

The implication for us is that, quite apart from our intention to start storing bank account numbers, it turns out that we're already responsible for SAQ A-EP, because we're hosting our own payments form. In fact, we never even discovered (and Balanced never emphasized) that we should have at least been self-assessing under SAQ A all along.

Contributor

chadwhitacre commented Jun 4, 2015

One of the major changes in PCI DSS 3.0 is that applications that host payment detail forms are subject to more stringent requirements, even if they never POST to their own server. This is significant, because it erodes the value proposition—"no-fuss PCI compliance!"—of all of the third-party payments APIs, including Balanced, Braintree, Stripe, etc. The only way to qualify for the easiest SAQ, SAQ A, is to collect payment details on an off-site page (whether in an iframe or as a redirect). There is no more easy white-labeling.

<sidebar>

Incidentally, while Braintree seems to be honoring these new rules, it turns out that Stripe is bending the rules to the point of breaking: they've convinced their qualified security assessor [QSA] "and others" to let them get away with simply building an iframe in JavaScript:

We’ve been working with our Qualified Security Assessor and others to update Stripe.js to meet the new requirements and security constraints, while still keeping it simple to use. The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe. This in turn allows our customers to continue to be eligible for SAQ-A (the older questionnaire) in most cases.

That's baloney-noodles. "To be eligible for PCI DSS v3 SAQ-A, the e-commerce environment must be fully outsourced such that: 'The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).'" Yet Stripe instructs their users to collect payment details on a form of their own construction:

Before we get to the first step, let's take a quick look at a typical payment form. This is the part you can build with your web framework, or by hand in HTML — however you're used to building forms on the web.

Stripe clearly is advising their customers to violate PCI DSS v3, by using Stripe.js without submitting to SAQ A-EP.

Now, on the other side, PCI SSC's reasoning for allowing iframes while disallowing direct POST is suspect: any attacker that could silently siphon off credit cards from a POST flow could also silently siphon off cards from an iframe flow, by doing what Stripe is doing: programmatically constructing an iframe and submitting it to the third-party payments provider.

</sidebar>

The implication for us is that, quite apart from our intention to start storing bank account numbers, it turns out that we're already responsible for SAQ A-EP, because we're hosting our own payments form. In fact, we never even discovered (and Balanced never emphasized) that we should have at least been self-assessing under SAQ A all along.

@chadwhitacre chadwhitacre referenced this issue Jun 6, 2015

Closed

review new teams for Gratipay 158 #234

16 of 21 tasks complete
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 15, 2015

Contributor

Just wanted to follow up and let you know that at this time we've decided not to attempt the PCI compliance program as you and I discussed it. Thank you for the call, which was very helpful. We will definitely keep Sikich / 403 Labs in mind in the future!

Contributor

chadwhitacre commented Jun 15, 2015

Just wanted to follow up and let you know that at this time we've decided not to attempt the PCI compliance program as you and I discussed it. Thank you for the call, which was very helpful. We will definitely keep Sikich / 403 Labs in mind in the future!

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 15, 2015

Contributor

SAQ-D requires two penetration tests (internal and external), roughly $5,000 to $7,000 each.

Third-party attestation is ~$50,000 and 6 months.

Contributor

chadwhitacre commented Jun 15, 2015

SAQ-D requires two penetration tests (internal and external), roughly $5,000 to $7,000 each.

Third-party attestation is ~$50,000 and 6 months.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Mar 7, 2016

Contributor

See gratipay/gratipay.com#3870 (comment) for a security program description that is probably parallel to PCI DSS.

Contributor

chadwhitacre commented Mar 7, 2016

See gratipay/gratipay.com#3870 (comment) for a security program description that is probably parallel to PCI DSS.

@chadwhitacre chadwhitacre added this to the Payroll milestone Mar 11, 2016

@chadwhitacre chadwhitacre referenced this issue Mar 11, 2016

Closed

bring back take-what-you-want #3433

3 of 13 tasks complete
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Mar 14, 2016

Contributor

Third-party audits

A good security practice is to audit not only your own code and infrastructure, but also try to assess the security risk of various third-party companies you integrate with. I mentioned in my post The Great Graph the dangers of having to integrate and trust so many entities. If you provide confidential information to SaaS company that get's hacked, that data could be exposed. If you receive software updates from an entity that get's hacked (such as Transmission above), you'll be compromised. It is therefore important to audit these other entities.

Google released their Vendor Security Assessment Questionnaire (VSAQ) this week to help companies determine the risk of other businesses being hacked. However, over a year ago, LinkedIn released a much more extensive guide in their post A security policy framework to help companies unlock the power of the cloud. Whereas Google's doc helps you assess if a business will be hacked, LinkedIn's doc helps you to actually make the decision of whether to still trust them or not, and also digs into other security related concerns. For example, LinkedIn's doc asks if the vendor provides an API to revoke user accounts (important for account compromises or departing employees), and if the business has a disaster recovery plan and provides breach notifications (in case they are actually hacked).

Facebook's CSO, Alex Stamos, discussed in the WSJ this week the need for a common platform for businesses to share their auditing of vendors, because companies are doing these same audits on dozens if not hundreds of vendors every year, and it makes sense that some of this information should be shared to reduce such duplication of work.

https://summitroute.com/blog/2016/03/13/downclimb/#third-party-audits

Contributor

chadwhitacre commented Mar 14, 2016

Third-party audits

A good security practice is to audit not only your own code and infrastructure, but also try to assess the security risk of various third-party companies you integrate with. I mentioned in my post The Great Graph the dangers of having to integrate and trust so many entities. If you provide confidential information to SaaS company that get's hacked, that data could be exposed. If you receive software updates from an entity that get's hacked (such as Transmission above), you'll be compromised. It is therefore important to audit these other entities.

Google released their Vendor Security Assessment Questionnaire (VSAQ) this week to help companies determine the risk of other businesses being hacked. However, over a year ago, LinkedIn released a much more extensive guide in their post A security policy framework to help companies unlock the power of the cloud. Whereas Google's doc helps you assess if a business will be hacked, LinkedIn's doc helps you to actually make the decision of whether to still trust them or not, and also digs into other security related concerns. For example, LinkedIn's doc asks if the vendor provides an API to revoke user accounts (important for account compromises or departing employees), and if the business has a disaster recovery plan and provides breach notifications (in case they are actually hacked).

Facebook's CSO, Alex Stamos, discussed in the WSJ this week the need for a common platform for businesses to share their auditing of vendors, because companies are doing these same audits on dozens if not hundreds of vendors every year, and it makes sense that some of this information should be shared to reduce such duplication of work.

https://summitroute.com/blog/2016/03/13/downclimb/#third-party-audits

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Mar 17, 2016

Contributor

Out-of-date components should be updated immediately and a patch/update management should be implemented and followed.

https://hackerone.com/reports/123742

Contributor

chadwhitacre commented Mar 17, 2016

Out-of-date components should be updated immediately and a patch/update management should be implemented and followed.

https://hackerone.com/reports/123742

@chadwhitacre chadwhitacre referenced this issue Mar 17, 2016

Closed

Radar 50 #539

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 14, 2016

Contributor

With gratipay/gratipay.com#3504 (comment), I'm bumping this from the "Bring Back Payroll" milestone.

Contributor

chadwhitacre commented Apr 14, 2016

With gratipay/gratipay.com#3504 (comment), I'm bumping this from the "Bring Back Payroll" milestone.

@chadwhitacre chadwhitacre removed this from the Bring Back Payroll milestone Apr 14, 2016

@chadwhitacre chadwhitacre referenced this issue May 7, 2016

Merged

implement symmetric encryption #3998

8 of 8 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment