implement a PCI self-assessment program

[chadwhitacre]

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 (https://github.com/gratipay/gratipay.com/issues/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 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]

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]

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]

CDE = cardholder data environment

[chadwhitacre]

Is my laptop part of the CDE?

[chadwhitacre]

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]

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]

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

[chadwhitacre]

_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]

Re: AWS, Heroku, DO:

Oooooooh ... MaxCDN? :disappointed:

[chadwhitacre]

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]

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

6.3.2

[chadwhitacre]

_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]

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 https://github.com/gratipay/gratipay.com/issues/1052. :weary:

[chadwhitacre]

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]

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]

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]

_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]

Okay! Finished a first pass through the spec. :swimmer:

[chadwhitacre]

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]

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]

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]

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]

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]

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]

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]

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]

See https://github.com/gratipay/gratipay.com/issues/3870#issuecomment-187718272 for a security program description that is probably parallel to PCI DSS.

[chadwhitacre]

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]

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

https://hackerone.com/reports/123742

[chadwhitacre]

With https://github.com/gratipay/gratipay.com/issues/3504#issuecomment-210168086, I'm bumping this from the "Bring Back Payroll" milestone.