07
Jan
15

SAQ A And SAQ A-EP Clarification

With the advent of SAQ A and A-EP, there seems to be confusion as to what meets what for each SAQ.  I thought I covered this rather well in my post titled ‘Of Redirects And Reposts’.  But apparently that was not clear enough.

For outsourced eCommerce solutions, the criteria from SAQ A states it can be used if and only if:

“The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).”

For some service providers it appears that there seems to be a lot of misunderstandings as to what constitutes “originates directly from a third party”.  A lot of processors believe that if their customers’ Web sites are not storing cardholder data (CHD) or sensitive authentication data (SAD) then they are out of scope regardless of the method used to process a customer’s payment.  What they seem to forget is that applications that process and/or transmit CHD/SAD are in-scope for PCI compliance just as those that store CHD/SAD.

For SAQ A and A-EP, the Council took their lead from Visa Europe as to what is meant by “originates directly”.  Visa Europe’s Processing eCommerce Payments guide has a great matrix that explains the difference between SAQ A and A-EP by payment processing type and merchant level.

Visa Europe SAQ A SAQ A-EP ROC Matrix

With redirects and iFrames, the merchant’s Web server never comes into contact with the CHD or SAD because the customer is communicating directly with the transaction processor’s server.  PayPal is a prime example of a redirect and meets the criteria of SAQ A.  With a direct post, JavaScript, XML or any other techniques, the merchant’s eCommerce server is at least processing and/or transmitting the CHD/SAD to the processor’s servers.  That is because there is some form of code/executable/script/etc. that is running on the merchant’s eCommerce server thus placing it directly in-scope.

Where things seem to get confusing is with processors that offer multiple methods of completing payments.  Unfortunately, it also appears to be just as confusing to the processors’ sales personnel as well.  We have encountered numerous instances where the processor’s sales people believe all of their solutions make the merchant out of scope when only the redirect/iFrame solution they have provides such a scope reduction.  All of their other solutions place the merchant directly in-scope.

The bottom line is that it is extremely important to get the transaction processor to explain how a payment is processed to determine whether your server is or is not out of scope.  Even if the sales person says the solution is an iFrame or a redirect, make sure to quiz them enough to ensure that they truly are delivering you an iFrame or redirect solution.

But a word to the wise.  Security professionals will question a merchant’s decision to not worry about the security of their eCommerce Web server because there still is a risk even with the redirect or iFrame approaches.  That risk is that the code/executable/script/etc. that invokes the redirect or iFrame on the merchant’s server gets tampered with or changed and now invokes a Web site that is not the transaction processor’s Web site.  As a result, a merchant’s customers’ CHD/SAD could be sent to Timbuktu and no one would be the wiser until goods/services are not provided due to non-payment.

As a result, security conscious merchants will, at a minimum, ensure their eCommerce servers are properly security hardened, patched current and will monitor the code/executable/script/etc. for changes.  Should a change be detected, the server would then be brought offline and fixed to ensure that transactions are properly processed.

Hopefully this provides everyone with clarity on how to use these SAQs peroperly.

One additional thing I would like to point out.  If you look at the Level 1 merchant line of the Visa Europe matrix, it shows ROC subscripted with either an ‘A’ or an ‘A-EP’.  I point this out because if you meet the criteria of either of the SAQs but are a Level 1 merchant, you can mark all of the ROC requirements not in the respective SAQ as ‘Not Applicable’ and only provide testing evidence for those requirements in the relevant SAQ.

Advertisements

26 Responses to “SAQ A And SAQ A-EP Clarification”


  1. 1 Bryan Ray
    April 8, 2016 at 8:19 AM

    Hi, very good article. I have a quick question. We are currently using checklist A. Our setup is our 3rd party processor delivers the payment page to the customer’s browser via iframe and all processing, transmitting and storage is between the customer’s browser and the 3rd party processor and it never touches our network. My question is: We also display an iframe from that 3rd party within our accounting department in case a customer calls us with a card number update or expiration update (no payment processing… just card updates). Our accountants (from our network) enter that update on the iframe from the 3rd party. Does this exclude us from using checklist A now?

    • April 11, 2016 at 7:31 PM

      As a merchant, you have an additional payment channel which is that you have phone payments. SAQ A is only for merchants that have totally outsourced everything and you no longer qualify for that distinction.

      The accounting PCs are now in-scope because they are used for data entry of payment information. The risk is that a keyboard logger or memory scraper ends up on those systems. I would say that an SAQ C is more appropriate but you will need to confirm that with your acquiring bank.

  2. 3 Raul Ramos
    August 10, 2015 at 9:38 AM

    Is the table (above) from the Visa Europe can be implemented or use as reference in North America?

    • August 17, 2015 at 6:21 AM

      That table is the basis for the Council’s information supplement on the subject.

  3. 5 cilynx
    April 7, 2015 at 6:50 PM

    In the article, you say: “With a direct post, JavaScript, XML or any other techniques, the merchant’s eCommerce server is at least processing and/or transmitting the CHD/SAD to the processor’s servers. That is because there is some form of code/executable/script/etc. that is running on the merchant’s eCommerce server thus placing it directly in-scope.”

    This is not how direct post works. In a direct post JavaScript transaction, the payment processor hosts a chunk of JavaScript in their CDN that is referenced by the merchant’s website. When the merchant’s website loads in the customer’s browser, the JavaScript is downloaded directly from the payment processor to the customer’s browser. The JavaScript executes in the customer’s browser — renders the payment form, collects the CHD, and ships it to the payment processor — all in the customer’s browser without ever touching the merchant’s server. The payment processor then calls back to a JavaScript handler function served by the merchant server (but still executed in the customer’s browser) with the response and a token.

    I agree that this still feels like SAQ A-EP because the merchant’s server controls the link to the service provider’s JavaScript, but I want to make sure people aren’t getting the wrong idea about how the dataflow works.

    Ref:
    https://developer.authorize.net/api/howitworks/dpm/
    https://stripe.com/docs/stripe.js

    Just as an interesting discussion point, Stripe is working on an update that will stick their whole solution into an iFrame as a method to get their customers back to SAQ A. I’m not sure that I feel that’s a better solution than what they’re doing now — something the merchant controls still has to point to a URL to populate that iFrame — but that’s a discussion for another day.

    https://support.stripe.com/questions/what-about-pci-dss-3-0

    • April 8, 2015 at 5:10 AM

      I agree with your analysis. JavaScript at the service provider is different from JavaScript running on the merchant’s Web site. I was just repeating the matrix from the Visa Europe document. The key is when the code/executable/script/etc. runs on the merchant’s server, it is at a minimum processing and transmitting cardholder data (CHD) and that Web server is in-scope.

      Where things get sticky and argued over is when the JavaScript comes from the merchant’s server, executes on the customer’s browser and communicates directly with the service provider. In the opinion of Visa and the Council (and mine as well), if such a JavaScript comes from the merchant’s server, then the merchant has a responsibility to secure/monitor the JavaScript so that it is not corrupted and customer payment information not only goes to the service provider, but is collected surreptitiously and sent to who knows where.

      • 7 cilynx
        April 8, 2015 at 11:00 AM

        I’d like to avoid the phrase “runs on the … server” because it makes it sound like the JavaScript which handles CHD is executing/interpreted on the server (merchant or service provider) that it is hosted on, which is not the case. So far as the server hosting the JavaScript is concerned, the JavaScript code is just text that is sent to a browser, not an executable/script to be executed/interpreted.

        I agree that it’s messier when the JavaScript is hosted on the merchant’s server, but I think fundamental responsibility and the CHD flow are the same.

        In this scenario, the merchant website includes the JavaScript that knows how to render the payment form and connect to the payment processor. The merchant server sends this JavaScript to the customer’s browser where it is executed. The customer’s browser is still doing all of the collection and transmission of CHD directly to the payment processor without any CHD every touching the merchant’s server.

        While the merchant’s server is not storing, processing, or transmitting CHD, what makes it messy is that the merchant’s server _is_ storing and transmitting JavaScript code that when executed in the customer’s browser will process and transmit CHD. Since the customer’s browser doesn’t have any way to validate what the JavaScript is supposed to be doing, this puts the onus back on the merchant to make sure that chunk of JavaScript isn’t evil.

        My concern is around the differentiation between using an iFrame and using JavaScript / Direct Post. I’ll try to explain by walking through the scenarios:

        iFrame:

        The HTML hosted by the merchant server holds a reference that looks like:

        iframe src=”https://www.paymentprocessor.com/iframe_generator/merchant_id/”

        If the merchant’s server is compromised, the attacker can change the reference to be their own server which presents altered payment iFrame content which submits the CHD first to an evil server and then to the payment processor

        Attack surface: Merchant Server
        Skills required: Modify HTML, Create a web app to generate evil iFrame content including some new JaveScript to skim the CHD before submission, Create a web app to accept CHD from added JavaScript
        Impact: CHD is skimmed and transaciton UX looks the same

        Direct Post without JavaScript:

        The HTML hosted by the merchant server holds a reference that looks like:

        form action=”https://www.paymentprocessor.com/payment_gateway.asp” method=”post”

        If the merchant’s server is compromised, the attacker can add some JavaScript to intercept the form post and send the CHD to their evil server before posting to the payment processor.

        Attack surface: Merchant Server
        Skills required: Modify HTML, Add JavaScript (to intercept the form submission), Create a web app to accept CHD from added JavaScript
        Impact: CHD is skimmed and transaciton UX looks the same

        Direct Post with JavaScript hosted by the payment processor:

        The HTML hosted by the merchant has a reference that looks like this:

        script type=”text/javascript” src=”https://www.paymentprocessor.com/js/payment_app.js”

        If the merchant’s server is compromised, the attacker can change the reference to point to their own JavaScript which does whatever they want, including skimming the CHD and sending it off to another evil server before sending the transaction to the payment processor.

        Attack surface: Merchant Server
        Skills required: Modify HTML, Modify JavaScript, Create a web app to accept CHD from JavaScript
        Impact: CHD is skimmed and transaciton UX looks the same

        Direct Post with JavaScript hosted by the merchant:

        Being the scenario under dispute, we’d expect this to look different, but it doesn’t.

        Just like in the previous cases, if the merchant server is compromised, the attacker can alter the JavaScript to send the CHD to their evil server in addition to the payment processor.

        Attack surface: Merchant Server
        Skills required: Modify JavaScript, Create a web app to accept CHD from JavaScript
        Impact: CHD is skimmed and transaciton UX looks the same

        Given that the attack surface and impact is the same in all four scenarios and all four attacks can be carried out by breaking into the merchant server, modifying some HTML and JavaScript, and propping up an evil web app to accept the skimmed CHD, why is an iFrame considerd to be more secure? Don’t get me wrong, I’m not necessarily arguing that Direct Post and JavaScript should be SAQ A, but that if Direct Post and JavaScript are SAQ A-EP then iFrame should be as well. Not saying that the Council agrees with me, just looking at the attacks and outcomes and I don’t see much of a difference.

        Most of the arguments for iFrames that I’m finding out there boil down to “The Council is aware that a MITM attack against a redirect or iFrame is viable, but in the payment brands’ experience these are detected before significant volumes of cardholder data are lost.” My hope is that this is true because most payment processors who implement iFrame solutions are doing some sort of sanity checking — “I received a post from $IP including $magic_token. Did I recently serve a payment form to $IP and is $magic_token what I’m expecting from them?” — as opposed to because the card brands havent figured out yet how to detect well-architected MITM attacks against iFrame solutions.

        IMO, it’s a question of implementation. How is the iFrame implemented and the data sent to its endpoint validated? How does the Direct Post endpoint validate that the HTML form or JavaScript that sent data to it wasn’t tampered with? It all comes down to hard implementation details that are not guaranteed by any given technology. I would love for someone to prove me wrong and provide a technological reason (not “because the payment brands have detected less fraud on iFrame solutions”) why iFrames are more secure.

      • April 9, 2015 at 5:46 AM

        Your analysis of your examples are absolutely dead on.

        This is why a lot of us in the security business do not like SAQ A allowing redirects and iFrames. It’s why smart merchants that use redirects and iFrames are using SAQ A-EP as their template, not SAQ A. It is why good QSAs tell their clients to only use SAQ A if their eCommerce is truly and totally outsourced with no redirect/iFrame.

        In my very humble opinion, what drove the Council to allow SAQ A to be used with redirects and iFrames were the hosting providers. They whined and lobbied for that decision because they had sold (some would say lied to) their customer bases on the fact that they had minimized their PCI scope by using their redirect/iFrame solutions. If that had not been the case, then those hosting providers would have had to eat crow and admit their mistake and possibly lost their hosting businesses. So this was all about protecting unscrupulous hosting providers, not securing eCommerce and protecting merchants’ customers’ cardholder data (CHD).

      • 9 Robert MacKinnon
        June 10, 2015 at 9:48 AM

        You are correct in your analysis that all four techniques have similar vulnerability to attack given weak controls on the merchant’s server that can be exploited. The only difference seems to be that those merchants who choose a Javascript-based solution are obligated to validate and report PCI compliance; those that choose iframe/redirect are not so obligated. In all cases, the merchant has a requirement to its clients to exercise due diligence and protect the information on the web server. All merchants who use any of these methods should be compelled to ensure controls commensurate with those outlined in SAQ-A-EP are in-place and are functioning. For merchants who utilize iframe/redirect they most probably will not exercise good risk management and carry out corporate due diligence, because they are not obligated to do so as part of their annual PCI DSS assessment.

  4. January 12, 2015 at 2:04 PM

    Where does this http://en.wikipedia.org/wiki/Cross-origin_resource_sharing fall in the chart?

    • January 12, 2015 at 2:09 PM

      I’m not positive. But the Wikipedia page you pointed me to speaks about XML all over, so that is the column I would look to for guidance.

  5. 12 JLH
    January 8, 2015 at 4:17 AM

    Hello,

    I have a doubt about the inclusion of the web server in scope whenever a redirection or an iframe to the payment gateway is used in a call center environment. If the web page used to select a product is used in a call center environment, it is usual that an event is triggered (and received in the record system) when the payment has to be performed and at this moment, the record of the conversation is stopped in order to not record the payment data.

    In this case, I believe that you have to control the code including the redirection of the payment gateway and the code including the event triggered to stop the record of the phone call. So, do you think that controlling these parts of the code and patching the web server is enough? Should the secure development methodology be audited?

    • January 8, 2015 at 5:32 AM

      Call centers are unique not only because how they work, but also how they interact with cardholder (CHD) and sensitive authentication data (SAD).

      Call centers typically use voice over IP (VoIP) which creates its own unique PCI compliance issues outside of call recordings. Then there are the call recordings. The PCI SSC has issued an FAQ on how those need to be secured or dealt with if CHD/SAD is not recorded.

      But then you have how the call center operators interact with their client applications to handle orders and payments. Some are Web sites but some are also virtual desktop. While the Web site solutions are typically hosted by the client, the virtual desktop solutions may or may not be hosted by the client, which means the QSA must ensure they truly understand how the virtual desktop solutions work.

      As to developing such Web-based solutions, I would recommend that you follow the PA-DSS guidelines for developing secure applications if that application is going to process, store or transmit CHD/SAD. If you are redirecting or using an iFrame solution, then you want to make sure that the code/script/executable/etc. that invokes the redirect/iFrame is secure and only changes when you expect it to change.

      Secure coding techniques and training is a must for any developers as you no longer have any guarantees of where or how an application will be implemented.

      • 14 JLH
        January 8, 2015 at 5:46 AM

        But secure coding techniques are not included in SAQ A because the redirection to the payment gateway is performed. So, if an application included in the requirements of SAQ A is used by a call center operator, is it the same case where a customer uses a SAQ A application? (I mean in relation with the application requirements, not the call center and operators and desktop machines requirements)

      • January 8, 2015 at 6:23 AM

        If you are relying on the PCI standards to be your complete security guidance, then you are looking at the wrong documents. Frameworks such as the PCI standards, ISO 27K, HIPAA, etc. are merely baselines for basic security, not guides for proper and complete security (however, always remember that security is NOT perfect). There is no detailed road map because every organization is different, has a different architecture, has different applications, has different risks, has different threats, etc. The PCI SSC, QSAs and security professionals have always stated that to be secure, organizations must go beyond the published standards.

        Just because something is not explicitly called out in any standard, does not mean it is not something you need to do.

        How far and where you need to go beyond depends on the results of your risk assessment. The threats to a merchant are different from the threats to a manufacturer, different from the threats to a financial institution. The threats also differ based on industry such as the threats to a defense contractor versus a health care firm or a law firm. And finally, size does matter when it comes to security. However, large firms typically have stepped up their security measures. As a result, the attackers are moving downstream to small and mid-sized organizations that do not have as robust a security program either to gather their data or to use them to gain access to the larger organizations.

        A risk assessment is what will provide your road map for your organization.

      • 16 GGP
        January 8, 2015 at 8:07 AM

        Most call centers use CTI solutions to manage recording.
        A CTI application are usually configured to work over one or more different forms, and it is able to detect the fields where the recording server must to stop the record. I think that in this scenario, it is possible to use a SAQ A and you should add the configuration and protection of these agents to the requirements for the personal desktops, in conjunction with the antivirus and personal firewall.

        In the cases where is the own web application who notifies to the recording server that must to stop/resume the recording with an API (CTI server), it is possible only when you have control over the payment form, so the web-application does not qualify for SAQ A requirements.

        Apart from that, call centers typically report SAQ C or SAQ C-VT.

      • January 9, 2015 at 7:09 AM

        In my experience, Computer-Telephony Integration (CTI) is very hit or miss in call centers. My experience with about a dozen outsourced call centers, none of them invested in CTI with their call recording systems because they are constantly moving from client to client and CTI cannot be quickly reconfigured for the new client. Where I have encountered CTI solutions is with call centers that use their own technology and have integrated the call recording system with their applications.

        Whether you can use SAQ A, C or C-VT for the situations you describe is up to the acquiring bank to determine and endorse. QSAs and others can build a business case for reporting PCI compliance using a particular SAQ. But the ultimate decision as to whether or not you can use a particular SAQ is the acquiring bank’s.

        Most of the call centers I deal with conduct a full Report On Compliance (ROC) because they want to be listed on the Visa and MasterCard service provider lists for marketing purposes.

  6. 18 Fackler
    January 7, 2015 at 10:54 AM

    The Man in the Middle (MITM) attack you describe in your third to last paragraph has a more insidious, and likely, bent. The Silent MITM attack is where the iframe or redirect code is hijacked to add an additional iframe wrapper that allows the transaction to process as normal and silently copies the transaction data to the Bad Guys’ server. This attack would cause much less disruption and therefore could take much longer to even notice. Also, if the silent wrapper is programmed to execute from the end user’s machine, then the CHD wouldn’t touch the merchant’s environment and would have no hope of being caught by exit firewalls or traffic monitors.

    That sort of silent attack is a big reason why production code should be reviewed and compared against canonical code even when nothing appears to be wrong.

    • January 7, 2015 at 11:14 AM

      Agreed on the code reviews even when something is supposedly not wrong.

      What I describe is not a true man-in-the-middle (MITM) attack when the code/script/executable/etc. is changed on the server.

      However, as you point out, there are many ways that a redirect/iFrame could be successfully manipulated to end up with customers going to the wrong payment site.

  7. 20 Louis
    January 7, 2015 at 10:52 AM

    Good day,

    I find I am more confused that ever before.

    My understanding of the redirect page was that because of the web site compromise risk and ensuing card data illicit capture, redirect eCommerce merchants (or their outsourcers, for that matter) had to comply to the SAQ A-EP subset.

    Your referenced article even mentions it rather clearly to me: “… An e-Commerce solution using the redirect approach is in scope for PCI compliance…”

    So here are two scenarios I am dealing with on a daily basis, and any light shedding on your part will be bliss

    Merchant A

    Purchased and hosts a software kit, that incorporate shopping cart functionalities and those redirect the customer browser to our hosted payment page. No card data is ever sent, either by the customer or us, to the merchant.

    My assessment, thus far: Merchant falls under A-EP and we are PSP (RoC L1)

    Main risk scenario is the shopping cart web site being compromised and card data sent to Timbuktu, affecting Merchant A

    Merchant B

    Hosts an informational web site which redirects the customer browser to a hosted shopping cart service. This provider’s solution is very similar to the merchant A solution, only they provide this service to many merchant B’s.

    Customer browser completes selection and is redirected to our hosted payment page. In essence, the customer browser was redirected twice and in neither of those cases, is card data returned. Only transaction result.

    My assessment, thus far: Merchant falls under A, Provider is RoC A-EP and we are PSP (RoC L1)

    Main risk scenario is the shopping cart web site being compromised and card data sent to Timbuktu, thus affecting many merchant B’s

    • January 7, 2015 at 11:26 AM

      First, service providers can only do either a Report On Compliance (ROC) or an SAQ D as defined by the card brands.

      The first matrix in the Visa Europe PDF is very, very poorly worded as is the written guidance from the PCI SSC. Based on Visa’s and the Council’s public comments (particularly those at the 2014 Community Meeting), the second matrix that I published with the post accurately reflects the position that the Council has backed.

      As a result, in both of your examples, the merchants would do an SAQ A.

      • 22 Louis
        January 7, 2015 at 12:19 PM

        Ok, got it for the merchants

        But how would you bring about (rationale behind) PCI applicability to a service provider that only provides shopping cart services, and handles no card data whatsoever ?

        That has been the bane of my existence, recently…

        (Much appreciated is your time spent here, btw)

      • January 7, 2015 at 1:07 PM

        You end up with an SAQ D that only responds to the requirements listed in SAQ A and marks the rest of the requirements in SAQ D as ‘Not Applicable’ with the reason being that the service provider redirects the payment process to a third party service provider.

      • 24 M
        June 23, 2015 at 4:04 PM

        OK, so I have been trying to determine scope for one my service providers and whether I have to require an SOC from them or not.
        We, the merchant, have contracted with a service provider that only provides shopping cart services (Similar to Louis above) and they are redirecting the payment process to a third party service provider via an iframe. The Service provider is based out of Europe and does not currently have nor have they ever had a SOC. They do not want to have to be “PCI Compliant” and have bulked at the mention of PCI.
        Also, we are going to be required to do an SAQ D since we have other places that we store PAD/SAD in the CDE and therefore are not eligible to do an SAQ A or SAQ A-EP.

      • June 24, 2015 at 5:05 AM

        First, let us clear up the service provider issues you describe. Your service provider is contracting with a third party to provide payment services. They are still YOUR service provider and are indirectly providing your organization with payment services. If they are truly out of scope, then they should convey you the payment service provider’s AOC for their payment service(s) along with a letter signed by an officer of the shopping cart service provider describing why they themselves are out of scope.

        By SOC, I am assuming you mean an SSAE 16 SOC 1 Type II report from your service provider. I would assume since this third party is providing shopping cart services to your organization that they are material to your organization’s financial statements. If true, then your organization will need a SOC 1 report from that service provider. However, a SOC 1 is a report used by your accountants to prove they can rely on the service provider’s financial numbers that are included in your organization’s financial reports. If you want something for your PCI and other security needs, you will have to work with the service provider’s SOC reporting provider to develop testing that will meet your needs under the SSAE 16 SOC 2 framework. Since the service provider is based in Europe, you may also have the additional issue of reconciling the ISAE 3402 SOC 2 standard to SSAE 16 SOC 2 since the likelihood is that the auditor will be European-based.

        FYI Storage of SAD is not allowed after a transaction is complete, so I hope that your statement in that regard is a typo. However, being you are from an airline, you are potentially referring to storage of SAD similar to what hotels do. That said, I would highly recommend that you avoid storing SAD and look at tokenization solutions that will get the SAD storage out of your systems.

        Not sure what you meant by PAD other than you mean cardholder data (CHD).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

January 2015
M T W T F S S
« Dec   Feb »
 1234
567891011
12131415161718
19202122232425
262728293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,800 other followers


%d bloggers like this: