PCI-DSS Compliance Commitment

ITPDX is not willing to join the list of service vendors that use fear to sell their services. So please be aware that the information we provide here is not designed to scare you but in fact make you aware of the subject matter. It is unfortunate that most of the hot topics at the start of the 21st century have to do with protecting yourself from cyber-attack and hacker techniques... most of us at ITPDX remember the days when the potential of new technologies still had a golden hue of hope for better life on earth.

This document is about PCI DSS Compliance. Is a voluntary participation rules set created by the bank card industry leaders (American Express, Visa, Mastercard) and is discussed with authentic authority ONLY at this web site: https://www.pcisecuritystandards.org. There are dozens of organizations selling PCI Compliance services on-line that have built their own informational sites. In our initial research we found quite a few who contradicted the information from the source either through human error or on purpose. It's become quite a confusing concern for anyone planning on launching a new commerce shop and every year the PCI Standards Committees release more detailed lists of requirements. But rest assured most of them are just good practice and you'll probably be doing them as a matter of course rather than making special efforts. ITPDX has.

PCI DSS are acronyms for: Payment Card Industry Data Security Standards (PCI DSS).

1. WHO IS PCI-DSS FOR?

Compliance with PCI DSS is the responsibility of the Merchant. In this context the Merchant is the Company who will own and operate the commerce shop and interact/interface with customers as representation of that Corporation. Example: If Acme Corporation wishes to sell T-Shirts on-line, Acme Corporation is the one PCI DSS is written for and Acme Corporation is being asked to voluntarily perform a SAQ (Self-Assessment Questionnaire). The SAQ is not just about their on-line web shop but it's about their entire business. It could include Acme Corporation's internal operational policies and processes from the bookkeeper to the actual furniture (File Cabinet) in your office.

For your convenience (at this writing) you can use this URL to dive directly to the definition of a merchant.

The ISP (Internet Service Provider) or hosting service provider may be included in the Merchant definition IF it actually stores payment card data for any purpose on behalf of the Merchant. ITPDX builds e-commerce sites so that no payment card data is stored on any servers. All payment card data is transmitted from the servers directly to the Payment Gateway Interface (PGI) via secure protocols, a token or transaction response is received and the data is wiped from memory of the server at that point (whether or not the transaction was a success).

Any vendor/shop-owner that wishes to hold customer payment card data on file is not a welcome customer of ITPDX anyway UNLESS we're helping you build systems to stop storing the data of course.

Further clarification can be found at this URL.

Just in case you need a more thorough definition on the scope of the "encryption" policy, you can read more here.

2. MERCHANTS MUST PROTECT CUSTOMER DATA

Part of the SAQ forms include questions about any Internet exposure of the Merchant's Customer Confidential data. Which at a minimum is the complete "PAN", yet another definition acronym which is: “primary account number” and also referred to as “account number” (committees do love acronyms). It's the unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account. If you are noticing there's a trend here. Bureaucratic definitions and layers are being invented to put some "guidelines" and scope around the process but without the ability to legally enforce any of the guidelines it only becomes a great task for any company's legal department to spend time working through every nuance of the definitions. Here are the definitions provided by the PCI Security Council.

It has ALWAYS been a concern of merchants that laws would be invented that would enforce these rules. But due to the conflict of interest... it becomes a particular challenge to get it all the way to a Bill form. The other drawback to their effort is that they are trying to encompass technology and protocol, a FAST moving target.

So as quickly as they can come up with rules about Internet commerce, the technology has left them behind and so have the ne'er-do-well criminals who exploit them. A case in point: Thumb driven smart-phone shopping activity actually surpassed online web-based shopping on Black Friday Shopping for 2015.

There are some guidelines in the PCI docs for smart-phones... but they must still catch up. All these guidelines are beginning to cross the gray areas into legal liability zones and cyber-security zones as well. It's a seemingly monumental challenge to keep up with this so make sure you have good people working for you.

3. IT'S NOT LAW. DO I CARE?

The REASON that the Council of Payment Card brands exist to set up this guidance. It is because they cannot lean on any laws to force compliance data security standards that they exist at all. They were forced to band together to push and pull Merchants into compliance by offering "discounted" transaction processing rates for those who comply when handling financial transactions and simultaneously using strong verbiage in their guidelines. Push the fear, pull with the discounts. This all started clear back in the 1990's and was badly needed. Lacking east integration to Payment Gateway Interfaces (PGI) for commerce and easy secure protocols... credit card data was flying all over the Internet and getting stored on 3x5 cards in Merchant's file cabinets for later use.... it was very bad.

If you love reading long documents about rules and policies, the entire document can be found here for your to download.

4. ITPDX'S APPROACH?

The ITPDX approach to all questions about hosting services follows these simple rules which make it very easy for you to fill out your Self-Assessment Questionnaire questions regarding your web commerce activities:

Rule ONE: ALL protocols regarding cardholder data are SECURE protocols. Ideally, your entire site will be built on an HTTPS protocol from the top down and we will promote this to you.

Rule TWO: Cardholder data is NEVER stored anywhere on the servers encrypted or otherwise. It is handled in RAM, transmitted using secure protocols to/from the Payment Gateway Interface vendor (such as Authorize.net) and THEY are the top-level PCIDSS compliant service provider that may or may not be used to store cardholder data. In fact, they provide this as a feature if you subscribe to their CIM Service as part of your Payment Gateway Service.

Rule THREE: All transactional activity with regards to an order, invoice, shipment are logged and stored so that you have an accountability record of the transaction without actually holding any of the Cardholder Data.

Rule FOUR: Any inter-server communication that could be required in the future will always be via secured protocols. It is a standard ITPDX has been using since 2001.

Rule FIVE: Only ITPDX staff are allowed direct access to the operating system of any servers involved in ITPDX hosted environments. No exceptions. And ALWAYS using encrypted secure protocols.

These five rules established. You simply need to tick a couple of boxes in the Self-Assessment Questionnaire on PCI-DSS and skip pages of detail questions.

5. THE TWELVE REQUIREMENTS

Additionally, as a matter of policy and practice, ITPDX already meets the PCI DSS 12 big rules for service providers.

#1: Install and maintain a firewall configuration to protect cardholder data
#2: Do not use vendor-supplied defaults for system passwords and other security parameters
#3: Protect stored cardholder data
#4: Encrypt transmission of cardholder data across open, public networks
#5: Protect all systems against malware and regularly update anti-virus software or programs
#6: Develop and maintain secure systems and applications
#7: Restrict access to cardholder data by business need to know
#8: Identify and authenticate access to system components
#9: Restrict physical access to cardholder data
#10: Track and monitor all access to network resources and cardholder data
#11: Regularly test security systems and processes.
#12: Maintain a policy that addresses information security for all personnel

If your eyes have not glazed over already, please read on and we'll address each requirement specifically:

REQUIREMENT #1: Install and maintain a firewall configuration to protect cardholder data - ITPDX uses a combination of hardware and software firewall configurations. We have proprietary tools which allow us to monitor network traffic in real-time, block attackers manually (and aggressively) and also automatically depending on the techniques they are using to attack your web site. We man the walls for you and walk the perimeter in person. We see ourselves as your on-duty security guards. We do not just respond to emergencies that indicate your site is down or failed. We respond to performance degradation that precedes downtime which indicates an attack may be beginning and we fight for you against attackers in real-time if necessary to protect you, your customers, and your site.

REQUIREMENT #2: Do not use vendor-supplied defaults for system passwords and other security parameters - ITPDX prefers and works almost entirely with Open-Source software. We do not work with black-box style software if we can avoid it. We perform due-diligence on all code that we put on our hosted servers or build/customize for our clients. Any defaults that can be changed are changed on live installations of software. Further because we can change the code we perform a security hardening of any software code that we will be maintaining. We can do this because we control the entire environment from the hardware level to the Internet access. Our expertise spans every layer of operation from hardware and networks all the way to application software.

REQUIREMENT #3: Protect stored cardholder data - We do not hold it as a policy. It passes through temporarily in RAM of our servers and is wiped out and disappears just as quickly as the response comes back from the Payment Gateway Interface (PGI) provider you use.

REQUIREMENT #4: Encrypt transmission of cardholder data across open, public networks - Data transmission to/from external payment gateway interfaces and 3rd party systems is always https for programmatic integration on our platforms. All our servers use encrypted data between themselves as well. And we do not hold cardholder data as a policy after the transmissions are concluded.

REQUIREMENT #5: Protect all systems against malware and regularly update anti-virus software or programs - Our servers are under constant review for housekeeping maintenance. Any files that are changed or out-of-place in the hosting environments are discovered by automation reports on a weekly basis and manually cleaned up. Further, all our sites employ a built-in virus protection process chain so that when you upload an image to your web site through our managed CMS systems on our managed servers we scan it as it comes through. If it passes virus scanning it's allowed into your site directory structure. The virus protection is updated nightly. This is very important for you to protect your customers from accidentally downloading a malware that may have snaked it's way into your own network. Trojans typically spread across the Internet because innocent web sites are compromised with Trojans hidden in image files and such. They are then downloaded by unaware visitors to the site. So the protection starts with you, but we build a layer of protection at the web server Content Management level as well.

REQUIREMENT #6: Develop and maintain secure systems and applications - See above. No external access is allowed. All protocols for direct access other than web access are secured. All internal server-to-server communications are via secure protocols.

REQUIREMENT #7: Restrict access to cardholder data by business need to know - We do not hold it as a policy. See #3 above. Customer information beyond credit card data is made available via secured Administrative interfaces for your staff.

REQUIREMENT #8: Identify and authenticate access to system components - As a matter of policy, every individual user both ITPDX staff and yours have unique identities on the admin components of your web site/store.

REQUIREMENT #9: Restrict physical access to cardholder data - We do not hold it as a policy. See #3 above.

REQUIREMENT #10: Track and monitor all access to network resources and cardholder data - All access to the ITPDX hosted servers at the operating system level trigger access alerts to ITPDX staff. All access is also logged and analyzed in scheduled exploit attack vector analyses. Since only ITPDX staff are allowed to access operating system level shells this is an internal warning and tracking system that allows staff to be more aware of each other's activities. Odd behavior would be recognized immediately.

REQUIREMENT #11: Regularly test security systems and processes. - Server physical access is protected by two levels of physical security. Physical access to the hosting facility is logged electronically. No wireless protocols are exposed or even exist in the ITPDX hosting facility.

All systems are under constant remote monitoring. Not just the network activity but the system level hardware processes as well. We can watch in real-time as the CPU works on your web traffic requests and we do. Abnormally large network traffic, CPU workload, or disk usage triggers audible alerts to staff and is sampled every 5-10 seconds. We KNOW what's going on in our hosting server environment.

REQUIREMENT #12: Maintain a policy that addresses information security for all personnel. - Our Service Level Agreement and our Terms of Service agreement are written for both clients and internal ITPDX staff to follow. We are VERY strict and make NO exceptions. You can review them here.

###