Payment Card Industry Data Security Standard, or PCI-DSS, is an information security standard that is designed to protect credit card data from being exposed and used fraudulently.
Recently, Acquia implemented a new Payment Card Industry Data Security Standard (PCI DSS)-compliant shared VPC environment as we move toward a network segmentation approach to PCI DSS compliance. This is part of our ongoing effort to ensure that we continue to meet the evolving security needs of customers with e-commerce websites. This change provides an additional layer of security for customers with commerce-oriented websites.
What kind of websites require PCI DSS compliance?
PCI DSS compliance is for websites that store, process, or transmit cardholder data on the Acquia platform or websites that use a third-party payment gateway or iframe to process credit card payments.
Does Acquia provide PCI DSS compliant hosting?
Acquia has a PCI DSS-compliant hosting shared VPC environment as part of Acquia Cloud Enterprise. Websites that require a PCI DSS compliant environment must use this environment to meet compliance requirements.
A Qualified Security Assessor (QSA) performs an annual audit to verify that the Acquia platform is compliant with PCI DSS. The Attestation of Compliance (AOC) and Report on Compliance (ROC) documents validate Acquia PCI DSS compliance, and can be provided to prospective or current customers upon request.
Acquia Cloud Enterprise and Acquia Cloud Site Factory customers with websites requiring PCI DSS compliant environments should contact their Account Manager to discuss additional infrastructure changes that may also be required for their website to meet PCI DSS requirements.
Please Replace These Missing Tokens customers with websites requiring PCI DSS compliant environments should contact Acquia Support by creating a support ticket.
How do I know if my website is PCI DSS compliant?
While Acquia provides a PCI-compliant hosting environment as part of Acquia Cloud Enterprise, only your PCI QSA or your internal security resource completing a PCI DSS self assessment questionnaire (SAQ) can confirm if the way your website processes credit card payments will meet PCI DSS compliance requirements. We encourage you to contact your QSA auditor with any additional questions that you may have. Acquia cannot determine if your website is PCI DSS compliant.
My website is hosted on Acquia Cloud, but it processes payments through a third party service (such as WorldPay, Paypal, or Authorize.net). Is my website PCI DSS compliant?
The Acquia Security team has spoken at length with our PCI-Auditors, as well as a number of PCI auditors that work with our customers. Because your website is connected to your payment gateway, it is considered in-scope for PCI DSS compliance.
This means that your main website, which is hosted with Acquia, is required to be PCI DSS compliant, even though the transaction is performed through a third party service. Consequently, your website would need to be moved into our shared VPC to meet PCI DSS compliance.
Where can I find more information about PCI DSS compliance?
For more information about e-commerce and PCI DSS compliance, see the PCI Security Standards Council's documentation for PCI DSS E-commerce Guidelines. For other information about Acquia compliance, see Compliance with standards and regulations.
Is Acquia immune to the BEAST browser exploit?
Acquia Cloud no longer supports RC4-based SSL cypher suites because of their known security vulnerabilities. This means that Acquia Cloud no longer includes server-side mitigation of the potential BEAST security vulnerability. However, we believe that existing client-side mitigation of BEAST is sufficient, and that the security vulnerability from RC4-based SSL cypher suites is a much more significant threat. For more information, we recommend reading Qualys Security Labs' discussion, Is BEAST Still a Threat?
The BEAST vulnerability will continue to be detected on the Acquia platform, and Acquia will take no further steps to resolve it, as we consider it primarily a client-side vulnerability. Note that this is not an Acquia-specific condition. Other providers need to make the same choice as to which vulnerability they choose to live with. You will need to work with your compliance tester to get a passing grade in light of the view expressed by Qualys Security Labs.
This information was included in the Acquia Cloud 1.84 release.
Is there a way for Acquia to restrict SSH access to our servers?
Acquia cannot restrict SSH access to specific servers. SSH public key-based authentication protects the servers. We do not yet have per-customer iptables firewalls. The Varnish cache can be used only for port 80 and HTTP protocol; not SSH access.
How can I disable responses to HTTP TRACE requests?
A HTTP TRACE request causes the data received by a HTTP server from the client to be sent back to the client. This request could be used by a malicious user to trick a browser into issuing a TRACE request to one website and then sending the response to the user. This is referred to as a cross-site tracing (XST) attack.
You can change your configuration to prevent the ability to respond to HTTP TRACE requests, if required:
RewriteEngine OnRewriteCond %{REQUEST_METHOD} ^TRACERewriteRule .* - [F]
We aren’t using SSL. Please disable responses on port 443 for my server.
Our hosting service is centrally managed and consistently configured across all servers on our platforms, so we cannot disable SSL (or, specifically, the port that receives SSL traffic) on any one server. All hosting servers are provisioned with SSL functionality, and we have no way to stop incoming SSL traffic or otherwise redirect it. It is possible, however, to redirect all HTTPS (port 443) traffic to HTTP (port 80) using .htaccess. For information about how to do this, see Redirecting visitor requests with the .htaccess file.
Why are reverse proxies exposed in response headers?
This question refers to the headers that are passed due to Varnish caching. We have deliberately made this information available on our platforms for two reasons:
- Our security specialists consider this information to be low-risk.
- Customers need to use these headers to determine the success of caching mechanisms which are essential to their business operations. For example, the
X-CacheandX-Varnishheaders allow customers to determine that their cache is working properly.