Policy-other pdf containing action key download detected

If you’ve been contacted by your bank or financial institution lately only to discover that your credit card information has been compromised, then you’ve felt the growing frustration many consumers face today.

Indeed, the situation with respect to credit card fraud is only getting worse.

Dealing with a compromise is a time-consuming hassle from a consumer’s perspective.

This is particularly because many of us maintain large numbers of (supposedly secure) personal online profiles that afford us a convenient way to deal with recurring monthly or annual payments.

This is the purpose of PCI DSS — and every retailer is required to comply.

Depending on the ecommerce technology and backend a retailer uses, PCI compliance can be an easy check on a long list of things retailers need to do to ensure their customers are transacting securely.

Or it can be a big pain — costing ample time, resources and money.

In this guide, you’ll learn:

• What PCI DSS is.
• How to achieve it for your business.
• How your ecommerce backend plays a large role in your required effort.

Below are the 12 High-Level Requirements Mandated by the PCI DSS.

What is the PCI DSS?

PCI DSS are standards all businesses that transact via credit card must abide by.

Originally created by Visa, MasterCard, Discover, and American Express in , the PCI DSS has evolved over the years to ensure that online sellers have the systems and processes in place to prevent a data breach.

The most recent version is PCI DSS Version was introduced in April and officially replaced version on February 1, as the standard all companies must follow.

The PCI Security Standards Council (PCI SSC) defines a series of specific Data Security Standards (DSS) that are relevant to all merchants, regardless of revenue and credit card transaction volumes.

The SSC defines and manages the standards, while compliance to them is enforced by the credit card companies themselves.

Again, these standards apply to all organizations that deal with cardholder data.

Cardholder data refers specifically to the credit card number, along with cardholder name, expiration date and security code (CSC).

In total, PCI DSS outlines 12 requirements for compliance.

Twelve requirements may not sound like much. In fact, a quick scan for PCI compliance documentation online will lead you to believe that PCI compliance is easy.

In reality, maintaining PCI compliance is extremely complex — especially for large enterprises.

Why Credit Card Security is Often a Neglected Subject

Jasper Studios provides ecommerce development services to omnichannel retailers both large and small.

We’ve witnessed cardholder data stored in plain text files without any encryption or basic obfuscation residing under the CFO’s desk in a dusty PC dating back to the late ’s — all freshly captured from an insecure payment gateway in a homegrown ecommerce platform.

• Could my credit card number have been stored in that dusty old PC?
• Was yours?

This sort of practice is plain negligence.

Fortunately, however, this isn’t a practice undertaken by most organizations, and when done so, it’s typically caused by unintentional ignorance on the subject.

But, these sorts of horror stories still persist today.

It’s not just smaller organizations that can have deplorable standards for data security.

If this can happen to some of the world’s largest retailers, it can certainly happen to smaller ones, too.

Do I need to ensure PCI Compliance for my organization?

If you operate your own on-premise or self-hosted cloud commerce solution, then the short answer is, yes.

Ecommerce PCI compliance is important whether you run a single brick-and-mortar retail location or you are a large organization selling goods across multiple stores and ecommerce sites, anywhere that your credit card merchant account has been connected and integrated requires attention.

All credit card transaction volumes your organization processes are aggregated across multiple channels (i.e. in store retail point-of-sale terminals and online payment gateways) and summed up to determine an appropriate PCI compliance level.

Fortunately, if you operate a SaaS-based ecommerce store and do not have any access to any credit cardholder data (which is the case for most modern SaaS commerce platforms), your need for PCI compliance is greatly mitigated.

The heavy lifting has vested expertly and wonderfully in the hands of the technology experts working for the SaaS companies, which in our professional opinion is exactly where it belongs.

Ecommerce PCI Compliance Requirements

If you host and manage your own ecommerce platform (i.e. a custom solution), you will need to ensure PCI compliance for your organization.

The first step is to determine the required compliance level.

All merchants fall into one of four levels based upon credit or debit card transaction volume over a month period.

Level 1 is the most strict in terms of DSS requirements, where Level 4 is the least strict:

Almost all small and medium sized businesses (SMBs) classify as the lower Level 3 or Level 4 merchant, however, this does not preclude the necessity to maintain compliance with the same diligence as larger organizations.

In fact, it’s a costly misconception encountered amongst SMBs who believe they do not need to worry about compliance at all because they don’t do a significant enough volume of online or in-store sales.

Penalties for Non-Compliance

PCI is not, in itself, a law.

It’s a standard that was created by the major card brands including Visa, MasterCard, Discover, AMEX and JCB.

The credit card companies typically do not directly handle payment processing functions themselves, but rely on third party processors (such as Chase Paymentech or Moneris Solutions) to handle the transactional services.

The credit card companies, at their discretion, are the ones who administer fines to the merchant’s bank (or similar financial institution, known as the acquirer) and can range between $5, – $, per month for PCI compliance violations or breaches.

The bank/acquirer in turn passes the fines downstream until it eventually hits the merchant.

On top of fines that originate from the credit card companies, merchants may be subject to additional penalties from their bank as well.

What’s arguably even worse is that the bank or processor may require the merchant to move up a level in compliance if they are breached, making the adherence requirements all the more onerous on the merchant moving forward.

Penalties are not openly discussed nor widely publicized, but they can be catastrophic to a business.

It is important to be familiar with your credit card merchant account agreement(s), which should fully outline your exposure.

What the PCI Data Security Standards Involve

It’s a pretty technical subject to cover as well, which is summarized in the next chapter.

Most of the topics found in the PCI DSS deal with maintaining a professional data storage solution.

It includes information on securing an internal hosting network, adequately protecting cardholder data, implementing strong user access control measures, managing data security policies, executing a vulnerability management program and performing an external security audit.

It also provides detailed instructions on how to complete your own PCI Self-Assessment Questionnaire.

In all, if you’re a pure play (i.e. online-only) merchant that does not have a physical retail store but you accept, retain or transmit credit card data through your own self-hosted ecommerce store (via open source platforms such as: OpenCart, ZenCart, Magento, etc.) you should positively familiarize yourself with the PCI Security DSS and understand your required compliance level.

Consider hiring a qualified external party who is well versed in PCI subject matter and can provide an objective opinion on how to specifically achieve compliance for your organization.

We also recommend obtaining an independent adoption consultant along with a Qualified Security Assessor (or QSA). PSC is one such QSA partner who can provide detailed guidance as to how to obtain compliance and also act as an independent auditor to test your internal security.

Ecommerce PCI Compliance on Open Source Platforms

The topic of PCI compliance is immensely important to any online retailer that transmits or stores cardholder data (i.e. credit card or debit card information) in their own, physical on-site servers or remote data farms.

Cardholder data that is processed through an online store and retail point-of-sale system combine to form a single transaction volume used to determine an organization’s merchant compliance level.

For those not utilizing a SaaS or cloud-based ecommerce technology, the following information outlines the steps you must take in order to ensure that your online business is PCI compliant.

Your compliance level determines the amount of work you need to do, and the levels are as such:

• Levels 1 and 2 are for merchants processing 1,, transactions or more per year
• Level 3 applies to an organization that processes greater than 20, credit or debit card transactions per year
• Level 4 applies to an organization that processes less than 20, transactions per year

In the interest of brevity, as this subject is vastly complex, we’ll concentrate on a Level 3 or Level 4 organization.

Self Assessment for PCI Merchant Levels 3 and 4

If you are a Level 3 or Level 4 merchant, the PCI DSS provides you the option of doing an internal assessment, whereby a qualified staff member or corporate officer from your organization can perform his or her own audit and sign-off to produce a formal PCI DSS Attestation of Compliance package indicating such.

The first steps are to determine your required compliance level and then download and review the appropriate Self-Assessment Questionnaire (SAQ) found on the PCI SSC Website.

There are different SAQs for each merchant level and also different related DSS Attestation of Compliance forms for each level as well.

Before you venture down this path and attempt to download your SAQ and get started, you’ll need to first digest a six page document just to figure out which SAQ form to use in the first place.

And, if you aren’t thoroughly bored and confused after doing that, you almost certainly will be after referring to the lengthy PCI glossary of acronyms and technical jargon related to the subject.

This is an essential step, as they will often point out deviances in the standard PCI DSS they feel may apply in your case.

Level 3 merchants require quarterly external vulnerability scans by an ASV (Approved Scan Vendor).

A list of ASV’s can be found here and include such companies as Cisco Systems Inc, Alert Logic, Inc and Backbone Security, Inc to name a few.

Completing a self-assessment questionnaire for Level 3 and Level 4 merchants is based upon the honor system, much like completing your income tax return.

Many frankly don’t understand some of the items on the SAQ to be begin with.

That said, don’t be dishonest or misrepresent information on the SAQ. If you have a data security breach and your documents come under scrutiny, you can be fined heavily and, in the worst case, your merchant account(s) can be dropped by your bank/financial institution.

Achieving PCI Compliance: Getting Started

The PCI DSS contains what are actually common-sense general data security best practices for any system administration team that is used to hosting sensitive corporate information in a modern network environment.

The trouble in reaching compliance begins when an organization does not have experienced enough internal IT/IS departments and can unfortunately discover that their internal hosting environment is wildly insecure and susceptible to both internal snooping by their own staff or they are wide open to outside intrusion.

Every organization aiming to achieve PCI compliance begins in the same place.

There are three steps in the journey to adhering to the PCI DSS and becoming compliant:

• First, Assess — Perform your own audit to identify the cardholder data you are responsible for, take an inventory of your IT assets and business processes for payment card processing and analyze them for vulnerabilities that could expose sensitive cardholder data.
• Next, Remediate — Fix the vulnerabilities you discover in priority sequence. Ideally move away from storing cardholder data at all unless you absolutely need to. Many organizations store cardholder data within their own homegrown ecommerce platforms after taking a one-off guest checkout order with no intention of using the information again. In this case, why hold onto it at all? Only a merchant looking to set up recurring billing may actually need to retain cardholder data themselves and we’ve often found that B2C ecommerce merchants typically don’t need to support recurring billing profiles.
  • Wherever and whenever cardholder data can be stored by an external qualified body instead of your own organization is ideal, because nothing will help reach immediate PCI compliance more quickly than not storing or transmitting cardholder data at all.
• Finally, Report — Compile and submit required remediation validation records (if applicable), and submit compliance reports to the acquiring bank and card brands (i.e. Visa, Mastercard, Amex, etc.) with which you do business.

Completing the Self Assessment Questionnaire (SAQ).

The SAQ is a relatively short document (i.e. five or six pages long) and can itself be completed in a number of hours by someone qualified within your organization.

The work getting to that point, though, comes into play when attempting to answer the SAQ questions truthfully and thoroughly, and in a manner that will actually result in achieving compliance.

In so doing, an organization will doubtlessly encounter some significant technical challenges.

Below is a quick outline of what you can expect based on my own experience is seeking compliance for clients.

1. Technical Challenges to Satisfying the SAQ.

Even if credit card data passes through your self-hosted (i.e. non-SaaS) ecommerce platform, you are still on the hook for ensuring that any related servers you control (be it your database server, PoS system software, credit card processing terminal, utility server or internet application server) are sufficiently secure and compliant.

Each server that cardholder data is stored inside or transmitted through is termed a CDE (cardholder data environment) and requires:

• Tripwire software with a notification escalation profile to alert administrators that someone may have gained unauthorized access to the server and/or tampered with the files/permissions on the server. A tripwire is software that detects the presence of a code change or file structure profile change on a server. A notification escalation profile is a series of automated email or SMS messages. dispatched to key systems personnel in the event that intrusion is detected or an unexpected change to the file structure profile has occurred.
• Virus scanning software installed and running daily.
• Its operating system to be kept up-to-date with the latest security patches.
• The containing room or server rack (i.e. the physical environment containing the computer systems running commerce related servers) be kept under lock-and-key with limited authorized administrative access only.
• Entrance to/from the room by administrative personnel (including date/time and purpose of access) needs to be logged. These logs need to be archived and migrated off of the primary servers and housed securely elsewhere so that auditors can readily access them if required by the bank or credit card company.
• All cardholder data that is retained for local storage be done so using what the PCI DSS refers to as strong encryption (see the PCI SSC Glossary of Terms for more info). Encryption protects the data from easily being read and utilized by attackers if stolen during a breach event.
• The underlying strong encryption architecture must be fully documented and kept up to date.
• Personnel with remote access (or non-console administrative access) to the server environment must connect via multi-factor authentication only.
• External penetration testing be performed every six months to ensure the environment is secure.

2. Ongoing Maintenance: Mitigating Common Data Security Exploits.

Physical servers need to be continually patched against newly discovered security vulnerabilities.

Consider various security exploits that have arisen recently such as HEARTBLEED, POODLE and Logjam.

Your web application or ecommerce platform that is processing credit or debit cards also needs to be secured against client side (i.e. web browser) code exploits such as XSS and SQL Injection Attacks, to name a few.

PCI Breakdown: Time and Costs to Reach Compliance

On average, our experienced systems administration team will spend three to four business days securing a single server and preparing the appropriate documentation for a Level 3 or Level 4 merchant.

Merchants attempting to reach PCI compliance themselves however, without support from an outside partner, and who are already themselves adept at dealing with data security subject matter, can expect to spend upward of weeks of time performing the following tasks:

• Researching the PCI Data Security Standards (DSS)
• Determining which level of compliance and which PCI SAQ is required
• Securing their physical servers (often the largest and most costly aspect of the project)
• Examining any third party plugins or software components on the servers that cardholder data passes through and ensuring they, too, are PCI compliant and can produce external documentation that proves such
• Completing the PCI SAQ and Attestation of Compliance (ROC)

The above estimate factors some time for multiple staff within your organization that usually involves a multidisciplinary group of:

• Business analysts.
• System administrators.
• Ecommerce platform developers.
• Project managers.
• Legal teams.
• Resource protection staff.

It also takes into account some budget for outside consultant/auditor fees, and provision to hire a third party Qualified Security Assessor.

How Your Ecommerce Platform Affects Your PCI Compliance

You can acquire ecommerce software in different ways:

• Buying commercial software to run on your on-premise hardware
• Using open source software on your on-premise hardware (the Do-It-Yourself approach)
• Signing up for hosted software delivered as a service (SaaS)

Each approach strikes a different balance between your costs, benefits and ecommerce PCI risks and workload. The table sums up the highlights, and the following sections discuss each option in more detail.

#1: Commercial Software: The Costly Option

This requires you to buy and maintain your own hardware, plus shell out for a commercial software license and annual support.

The ecommerce software might be PCI-compliant out of the box, or you could have lots of work getting there. But any extra support you require from the vendor for PCI will likely cost extra.

This option could work for you, if your company chooses to:

• Buy and maintain on-premise hardware
• Pay for an on-premise software license and support
• Maintain in-house expertise to install, customize and maintain an ecommerce platform
• Keep someone on call 24/7 to troubleshoot any problem and get the platform back up fast if it ever goes down

If that doesn’t sound appealing, skip this approach and read on.

#2: On-Premise, Open Source Software: Lower Cost, Higher Risk

This option is a lot like writing your own code.

You have to assemble, compile, install and tweak your own software. And, as for PCI, this can turn into a money-pit. Open source is a black box where no one really knows what’s going on.

“The problem with open source is that you’re not buying from any vendor,” says Beckett. “So there’s no one to fall back on for help. You might not get any support, or no phone number you can call. Or maybe the PCI auditor might not like something about the platform.”

In that case, you’re stuck.

The DIY option could work, if your company can afford to:

• Buy and maintain on-premise hardware
• Maintain in-house expertise to link, tweak and maintain ecommerce software
• Take staff time to hold many meetings and create PCI-related documents

Using open source software means you are responsible for % of your PCI compliance — not to mention your store’s uptime.

If you don’t want to take on those burdens, skip this approach and read on.

#3: Hosted Software-as-a-Service (SaaS): Low Cost, Low Risk

Software running as a service is accessed through the web, running on hardware maintained in a secure data center by your service provider.

If you want to save money, and can’t spare a lot of staff to develop PCI policies and write reports, consider using a hosted ecommerce service such as BigCommerce.

An important consideration when selecting this option, however, is that you will still be required to complete an SAQ (self-assessment questionnaire) as a Level merchant and an ROC (i.e. report on compliance, also synonymous with Attestation of Compliance) if you are a Level 1 merchant.

Therefore, the work in documenting and reporting on a quality SaaS ecommerce platform regardless of your compliance level is much less involved in terms of cost and risk than the other two options presented.

The SaaS option will work for you if your company:

• Wants to save money on hardware, software licenses and support
• Doesn’t have people to fiddle with hardware and software
• Prefers to pay one monthly fee to cover your ecommerce platform
• Wants to remain PCI-compliant with a minimum of effort

With lower costs, less risk, and fewer PCI hassles, this option is the chosen path for many online stores.

Here is how a few popular ecommerce platforms breakdown:

PCI Compliance Checklist

Again, this is only applicable to your IT team if you choose not to go with a SaaS solution.

If you use a open source or custom built ecommerce platform, your IT team will need to go through the following checklist annually.

We’ve broken the checklist down below based on the PCI requirement.

1. Safeguard cardholder data by implementing and maintaining a firewall.

Maintaining requirement for 1:

1. Positioning firewalls to only allow necessary traffic to enter your CDE
2. Having a “deny all” rule for all other inbound and outbound traffic
3. Dynamic packet filtering
4. Creating a secure zone for any card data storage
5. Ensuring all outbound connections from your CDE are explicitly authorized
6. Installing a firewall between wireless networks and your CDE
7. Documenting all firewall policies and procedures, including business justification for each port or protocol allowed through firewalls

2. Create custom passwords and other unique security measures rather than using the default setting from your vendor-supplied systems.

Maintaining requirement for 2:

1. Maintaining an inventory of all hardware and software used in the CDE
2. Assigning a system administrator to be responsible for configuring system components
3. Implementing a system configuration and hardening guide that covers all components of the CDE
4. Disabling or uninstalling any unnecessary services, programs, accounts, drivers, scripts, features, systems, and web servers, and documenting which ones are allowed
5. Changing vendor-supplied default usernames and passwords
6. Documenting security policies and operation procedures for managing vendor defaults and other security settings
7. Using technologies such as VPN for web-based management and ensuring all traffic is encrypted following current standards. There are both paid and free VPNs available.
8. Enabling only one primary function per server

3. Safeguard stored cardholder data.

Maintaining requirement for 3:

1. Documenting a data retention policy
2. Having employees acknowledge their training and understanding of the policy
3. Eliminating storage of sensitive authentication data after card authorization
4. Masking the primary account number on customer receipts
5. Understanding guidelines for handling and storing cardholder data
6. Making sure primary account number storage is accessible by as few employees as possible, including limiting access to cryptographic keys, removable media, or hardcopies of data

4. Encrypt cardholder data that is transmitted across open, public networks.

Maintaining requirement for 4:

1. Reviewing all locations, systems, and devices where cardholder data is transmitted to ensure you’re using appropriate encryption to safeguard data over open, public networks
2. Verifying that encryption keys/certificates are valid and trusted
3. Continually checking the latest encryption vulnerabilities and updating as needed
4. Having a policy to ensure you don’t send unprotected cardholder data via end-user messaging technologies
5. Checking with vendors to ensure supplied POS devices are appropriately encrypting data
6. Reviewing and implementing best practices, policies, and procedures for sending and receiving payment card data
7. Ensuring TLS is enabled whenever cardholder data is transmitted or received through web- based services
8. Prohibiting the use of WEP, an unsecure wireless encryption standard

5. Anti-virus software needs to implemented and actively updated.

Maintaining requirement for 5:

1. Deploying anti-virus programs on commonly affected systems
2. Setting anti-virus to scan automatically to detect and remove malicious software
3. Maintaining audit logs for review
4. Ensuring the anti-virus system is updated automatically
5. Setting up administrative access to ensure anti-virus can’t be disabled or altered by users
6. Documenting malware procedures and reviewing with necessary staff
7. Examining system configurations and periodically evaluating malware threats to your system

6. Create and sustain secure systems and applications.

Maintaining requirement for 6:

1. Having a change management process
2. Having an update server
3. Having a process in place to keep up-to-date with the latest identified security vulnerabilities and their threat level
4. Installing vendor-supplied security patches on all system components
5. Ensuring all security updates are installed within one month of release
6. Setting up a manual or automatic schedule to install the latest security patches for all system Components

7. Keep cardholder access limited by need-to-know.

Maintaining requirement for 7:

1. Implementing access controls on any systems where cardholder data is stored and handled
2. Having a written policy that details access to cardholder data based on defined job roles and privilege levels
3. Training employees on their specific access level
4. Configuring access controls to only allow authorized parties and denying all others without prior approval or access

8. Users with digital access to cardholder data need unique identifiers.

Maintaining requirement for 8:

1. Monitoring all remote access accounts used by vendors, business partners, IT support personnel, etc. when the account is in use
2. Disabling all remote access accounts when not in use
3. Enabling accounts used for remote access only when they are needed
4. Implementing a multi-factor authentication solution for all remote access sessions

9. Physical access to cardholder data needs to be restricted.

Maintaining requirement for 9:

1. Restricting access to any publicly accessible network jacks in the business
2. Keeping physical media secure and maintaining strict control over any media being moved within the building and outside of it
3. Keeping media in a secure area with limited access and requiring management approval before the media is moved from its secure location
4. Using a secure courier when sending media through the mail so the location of the media can be tracked
5. Destroying media in a way that it cannot be reconstructed
6. Maintaining a list of all devices used for processing and training all employees to inspect devices for evidence of tampering
7. Having training processes for verifying the identity of outside vendors wanting access to devices and processes for reporting suspicious behavior around devices

Network resources and cardholder data access needs to be logged and reported.

Maintaining requirement for

1. Having audit logs that track every action taken by someone with administrative privileges, failed log in attempts, and changes to accounts
2. The ability to identify a user, the date and time of the event, the type of event, whether the event was a success or failure, where the event originated from, and the name of the impacted data or system component
3. Having processes and procedures to review logs and security events daily, as well as review system components defined by your risk management strategy
4. Having a process to respond to anomalies or exceptions in logs
5. Keeping all audit log records for at least one year and keeping logs for the most recent three months readily available for analysis

Run frequent security systems and processes tests.

Maintaining requirement for

1. Running quarterly internal vulnerability scans using a qualified internal resource or external third-party
2. Running quarterly external vulnerability scans using a PCI-approved scanning vendor (ASV)
3. Using a qualified resource to run internal and external scans after any major change to your network
4. Configuring the change-detection tools to alert you to unauthorized modification of critical content files, system files, or configuration files, and to configure the tools to perform critical file comparisons at least once a week
5. Having a process to respond to alerts generated by the change-detection tool
6. Running a quarterly scan on wireless access points, and developing a plan to respond to the detection of unauthorized wireless access points
7. Performing penetration tests to confirm segmentation is operational and isolates systems in the CDE from all other systems

Address information security throughout your business by creating a policy.

Maintaining requirement for

1. Developing written compliance and security policies
2. Ensuring every employee working in the CDE completes annual security awareness training
3. Creating a company policy documenting all critical devices and services within the CDE, including laptops, tablets, remote access, wireless access, and email/Internet usage
4. Developing a comprehensive description of each employee’s role in the CDE, and documenting acceptable uses and storage of all technologies
5. Creating an incident response plan in the event cardholder data is compromised
6. Creating and updating a current list of third-party service providers
7. Annually documenting a policy for engaging with third-party providers, obtaining a written agreement acknowledging responsibility for the cardholder data they possess, and having a  process for engaging new providers

We’ve Successfully Achieved PCI Compliance: What’s Next?

As if achieving PCI compliance wasn’t complex enough on its own, maintaining compliance year-over-year and keeping up with ever-evolving nuances to PCS data security standards (DSS) has proven itself a perpetual expense and burden to any organization.

The latest PCI DSS standard (version ) released in April of , for example, defines a number of changes to previously accepted rules and regulations on a variety of PCI subjects, touching upon both documentation requirements and technical adjustments to the physical hosting environment (CDE) itself.

This means as a self-hosted merchant you’ll need to concern yourself not only with getting all these requirements perfected the first time around, but you’ll also be expected to manage lists of future change requests and down-the-road migration plans that will keep your technical teams very busy ad infinitum (i.e. forever).

Let’s face it, they often have more than enough to do as it is.

In short, maintaining compliance is an ongoing process, involving all of the above as well as quarterly vulnerability scans and completing a new SAQ and Attestation of Compliance each year.

In this manner, your team won’t be flanked by a last minute crunch to get it done which will result in overstatements, omissions and increased third party auditing costs.

You’ll also proactively position your organization for an easy transition upward to a higher compliance level at a later time.