PCI Compliant Hosting

PCI (DSS) is an acronym which stands for Payment Card Industry Data Security Standard, and is a recent industry set of requirements which must be achieved and maintained in order to take credit card payments via your website. These security standards are for the most part, technical and operational requirements with the aim of enhancing and maintaining the integrity of any sensitive data, with particularly concern to credit card and other payment details.

Contents

PCI Compliant Hosting

Overview

Without wanting to delve into the actual value of this standard this page is here purely to discuss what is necessary to meet PCI Compliance. There is effectively three aspects which need to be given some consideration:

Requirements of your web hosting provider. Speaking generally, most aspects of PCI compliance are considered best practice from a hosting prospective. Assuming your hosting provider is aiming to do everything "the right way" then you can rest assured that you will be meeting PCI requirements. All Anchor web hosting services meet PCI compliance requirements.
Web application design considerations that are the responsibility of the web developer. A large portion of this standard come down to the design of your website, this is something which can only be the responsibility of your web developer.
Use and accessibility of credit card details. This is largely the responsibility of the company who is processing the payments, ensuring that there are sensible controls and business rules in place to maintain data security.

Achieving Compliance

In order to achieve compliance there are effectively two processes which need to be completed on a periodic basis:

An automated scan of your website and the server that your website is hosted on by an authorised scanning vendor (ASV) every quarter. This is done to ensure that your website meets any requirements.
Yearly self assessment questionnaire

PCI Requirements

This section will discuss each of the PCI requirements and discusses which party is responsible for meeting the requirement (Web hosting provider or Web developer), in addition to this, where the web hosting provider is responsible we we will provide comprehensive notes as to how Anchor is meeting these requirements.

Build and Maintain a secure network

The PCI DSS requirement breaks this down into two aspects.

Install and mantain a firewall configuration to protect card holder data

This is something which the web hosting provider is entirely responsible for. All Anchor web hosting use a host based firewall which employs stateful packet inspection configured using a strict firewall ruleset only allowing necessary data. For all intents and purposes this meets the PCI standard, however, we can also offer two additional firewall services on any dedicated server or virtual private server.

Shared secure port - this provides an additional layer of firewalling which is done at a network level by our pair of high availability firewall devices. This basically restricts data to and from your machine at the Anchor border and significantly reduces the amount of traffic capable of getting through to your server. This should be used in conjunction with a host based firewall effectively providing an additional layer of support.
Private secure port - In addition to all the benefits provided by using a shared secure port a private secure port also places your machine within its own VLAN. Effectively meaning that you are also not only shielded traffic entering the Anchor network but also from other physical hosts on the local Anchor network.

If you are a dedicated server or virtual private server customer and feel that you require the additional layers of security I would recommend contacting us on 1300 883 979 to discuss your requirements in more detail.

Do not use vendor-supplied defaults for system passwords and other security parameters

Once again this is something which your web hosting provide is entirely responsible for completing. This is built into our standard server build processes and is completed by default on all new server deployments. In addition to this, we employ a defense in depth approach which uses the method of adding multiple layers of security ensuring that no single breech in a security system will result in compromise.

Some of these methods we use include:

PAM (per user-based) restrictions on FTP/SSH access to all Anchor managed machines (see permitting remote access for more information
Encourage the use of secure transmission methods (SSH instead of FTP) and use of private/public key authentication vs. password authentication where ever possible as documented in Securing remote access using SSH
Use of automated processes such as sshd_sentry and password policies to lock out accounts after multiple failed authentication attempts to combat brute force password attacks.

Protect cardholder data

This is one of the particularly vague aspects of PCI compliance.

Some guidelines which can be followed here:

Only storing credit card details if absolutely necessary, Eg. for recurring charges.
Ensure that sensitive data is stored in an encrypted format
Ensuring that each entity only has access to their own cardholder data
Implementing and maintaining access control
Maintaining audit trails of changes
Allowing for timely investigation in the event of a compromise

Encrypt transmission of cardholder data across open, public networks

There is really two aspects that needs to be considered here.
The point in time when the credit card is entered into the system by the end user as part of the purchase process and;
Getting the information back out of the system by the client for order fulfillment.

From our point of view, solving aspect number 1 is relatively simply. Any SSL certificate would be installed to be used in conjunction with the webserver allowing all communications to happen over HTTPS, which utilises secure socket layer. Effectively, this encrypts all data between the webserver and the end users browser. The second aspect which would need to be considered is to ensure that the pages where credit card details are supplied can ONLY be accessed when using a secure (HTTPS) connection. Ensuring that the application behaves in this fashion is the responsibility of the web developer. Comprehensive testing should be part of the development process.

The second aspect deals with order fulfillment. Obviously once an order is placed, you need to deliver the product or service as well as charge the credit card. It is crucial that whilst this is completed any time credit card details are transmitted across a public network the details are encrypted. This is really the realm of the developer, however, some practical methods which would accomplish this:

Orders are processed via a web based interface using HTTPS
Orders are submitted to an off-site system via a secure tunnel. Eg, IPSEC (or equivalent) VPN connection, SSH tunnel, XMP-RPC over HTTPS
Details are captured, encrypted using something similar to PGP then sent via email.

Implement Strong Access Control Measures

Restrict access to cardholder data by business need-to-know

This aspect is entirely the responsibility of designed of the application working in conjunction with the company processing the orders and payments.

Consideration needs to be given the the following aspects:
Ensuring that credit card details can only be accessed via authenticated users
Having sufficient business rules in place to determine which staff "need-to-know" credit card details in their entirety.
- Eg, often the vast majority of staff do not need to know the entirety of a credit card number, obfuscation of all but the first and last 4 digits is often enough to determine both the type of card and provide a unique identifier.

Assign a unique ID to each person with computer access

Once again, this responsibility for this is largely the responsibility of the web developer and the company using the credit card data. Worthwhile considerations:

Web application must support multiple concurrent authenticated users
Must provide a way of differentiating access control on a per user basis
Responsibility of the client to ensure that each user has unique log in details which only that individual can use (consider authentication methods, password resets etc)

Restrict physical access to cardholder data

This aspect remains our responsibility assuming that the data stays on server located in the data centre.

The facility we use is Global Switch which is the largest data centre in the southern hemisphere and arguable one of the best of its kind in Australia which includes the following:

24x7 on-site security guards and technical staff
180+ 24/7 CCTV monitoring
Man traps and full electronic access control
Individual client suite with electronic controller access
Locked equipment racks

Access to the Anchor racks are only available for Anchor staff who are permanent pass-holders.

Regularly Monitor and Test Networks

Track and monitor all access to network resources and cardholder data

This is largely the responsibility of the web developer to ensure that the web application has an appropriate level of auditing built in.

In addition to this, on our shared web hosting services and dedicated server or virtual private server which is offered under our fully managed support pack then this is Anchor's responsibility.

Alternatively this will be need to be completed by your local system administrator.

Regularly test security systems and processes

Whilst it is one thing to have access levels defined and configured, unless the configuration is periodically audited and tested then there is no guarantee that the systems in place actually work.

Completing this aspect is really up to the web developer and the company processing the payments to come up with some suitable test cases and confirming that the system does what it is designed to do.

Maintain an Information Security Policy

Maintain a policy that addresses information security

This is the responsibility of both the web developer and the hosting provider. Anchor publishes our security policy online at http://www.anchor.com.au/security-policy.py.