Online_Transactions_PCI

ONLINE PAYMENT TRANSACTION 1
Online Payment Transactions:
PCI DSS and the Major Card Companies
Kelly Lam
Harrisburg University Science and Technology

Online Payment Transactions: PCI DSS and Major Card Companies
The world is becoming more technologically savvy and with that comes convenience.
The way customers shop has changed and evolved over the years. No longer needing to
physically go out and purchase good, they can now shop on their own time in the comfort of
their home. With the growing ecommerce market, the use of credit/debit cards is increasing
and so are the risks that come with it. There’s constant news about how this company’s
sensitive information was compromised or that company got hacked into resulting in
customer’s information being compromised. The question raised is, what protocols are in place
to prevent this? What is put in place that would keep customer information safe even during an
attack? No matter what type of transaction, whether online or in person, the actual transaction
process happens online and that’s what needs protecting. There is a system that companies
need to be compliant when dealing with card payment, the Payment Card Industry Security
Standards. The following will discuss the types of PCI standards that are in place and that need
to be abide by to ensure customer’s information security as well as major card companies’
actions when dealing with the PCI Security Standards.
The Payment Card Industry, better known by its acronym PCI, is the industry that deals
with credit, debit, prepaid, e-purse, ATM, and POS cards, as defined by Wikipedia. The
management of security of the PCI is dealt by the PCI Security Standards Council, LLC, or its
acronym PCI SSC. They are responsible for the development, management, education, and
awareness of the PCI security standards (PCI SSC, “About us…”). The council, as well at the
security practices, was founded by the five major card companies: American Express, Discover

Financial Services, JCB International, MasterCard, and Visa Inc. There are three standards, or
parts, to PCI Security Standards: PCI Pin Transaction Security (PTS), PCI Payment Application
Data Security Standard (PA-DSS), and PCI Data Security Standard (DSS). PCI PTS requirements
are a set of security requirements that focus on the characteristics and managements of
devices to protect the cardholder’s pins and other payment process related activities (PCI SSC,
2010). PCI PA-DSS is geared more towards software vendors and developers that handle the
payment applications that store, process, or transmit cardholder data and sensitive
authentication data (PCI SSC, 2010). PCI DSS covers the technical and operational system
components that deal with the cardholder’s data. For merchants or businesses that accepts and
process payment cards, they must comply with at PCI DSS since they store, process, and/or
transmit cardholder data (PCI SSC, 2010). Since PCI DSS correlates with online payment
transaction and is the larger aspect of PCI Security Standards, the next few paragraphs will
divulger deeper to on this standard. All information in the following is referenced from the PCI
SSC website and papers published by the Council.
If a merchant or business decides it want to start accepting and processing any type of
payment card, whether it is debit, credit, pre-paid, or what have you, he or she must be
compliant with PCI DSS. It is currently on version 3.0 as of November 2013 (PCI SSC, 2013). The
purpose of PCI DSS is to protect cardholder data. This data can include data printed on a card,
card’s magnetic stripe or chip, and identification numbers entered by cardholder (PCI SSC,
2010). There are essentially five goals on dealing with payment cards and a correlating twelve
requirements of PCI DSS that need to be met before being compliant, which can be seen in
figure 1. These requirements were designed for compliant assessments to ensure the

merchant’s validation process. Merchants are tested to see if their system is up-to-snuff and
follows the outline of the PCI DSS requirements. Only then will they be considered compliant
and able to accept and process payment cards. These twelve requirements correlates to the PCI
DSS Compliance steps: assess, remediate, and report.
Figure 1 - PCI Data Security Standard Overview (PCI SSC, 2010)
Being compliant is a constant process and the three steps must be continuously
maintained. According to PCI SSC’s Getting started with PCI Data Security Standard (n.d.), assess
deals with analyzing the IT assets and payment card process for vulnerabilities that could lead
to cardholder data exposure; Remediate is fixing the found vulnerabilities from the previous
step; Report is compiling the records required by PCI DSS to validate remediation and
submitting compliance reports. Each step flows into the other and should be done frequently to
ensure that any payment transaction done are security and no data exposure can occur. To
elaborate, the assess step is to find any possible vulnerabilities in network of systems that
handles the cardholder data in terms of transmitted, processed, or stored. This also includes

any third party involved with the transaction flow. There are three ways in helping the
assessment of a merchant or business: Self-Assessment Questionnaire (SAQ) is a validation tool
for those not required to do on-site assessments for PCI DSS compliance; Qualified Security
Assessor (QSA) is a council provided program where a trained personnel and processes assess
and prove compliance with the PCI DSS; Approved Scanning Vendor (ASV) is another council
provided program that uses commercial software tools to perform vulnerability scans. Step two
is remediate or fixing the vulnerabilities. After finding the vulnerabilities in the assess step, next
is to rank the vulnerabilities and classify themfor priority purposes, most serious to least
serious. Next is the start the remediation process by patching, fixing, finding workarounds,
and/or changing the processes and workflow. Once the fixes are in place, it’s best to re-scan
the system to verify the vulnerabilities have been fixed. The last step in this three step
compliancy is report. Regular reports are required to be PCI compliant and should be submitted
to the banks and payment brands the business deals with; the PCI SSC is not responsible for PCI
compliance but handling the security standards. Reports are filed by PCI SSC and approved
using ASV. Depending on the size of the business will depend on how many reports are sent out,
as well as the type. Small business may only need to report using SAQ where larger business
may need the on-site QSA.
Going back to the twelve requirements, these are mirrored to the security best practices
and should be followed by businesses who want to accept payment card. The first two
requirements correlates to the goal Build and Maintain a Secure Network. The requirements
are to install and maintain a firewall and router configuration to protect cardholder data and do
not use vendor-supplied defaults for systempasswords and other security parameters. To

summarize what the Council is requiring of merchants, they are to ensure that the network that
deals with cardholder data is secured and monitored, by way of firewall, and change the default
configurations on their devices, like a router for example. By adding a firewall to the network,
the traffic flow is regulated to allow for only certain communications, or connections, to travel
on the network. That would eliminate any unwanted and untrusted connections to the network
where sensitive data is being transferred. Changing the default configurations will make the
network hard to break into, adding another layer of security. Having default configurations that
can be found in a manual of the device is just asking for a hacker to attack the network and gain
access to the sensitive information.
Next goal is Protecting Cardholder Data with two requirements that follow: protect
stored cardholder data and encrypt transmission of cardholder data across open public
networks. PCI SSC recommends to never store cardholder data unless it meets the needs of the
business but especially the magnetic stripe or chip should never be stored. If the any
information needs to be stored, ensure that it’s unreadable or encrypted. Also have a time line
for how long the data is stored and delete it when time’s due so the sensitive information isn’t
just sitting there and possibly be used for malicious actions. Encrypt all stored and transmission
of cardholder data and protect the keys from disclosed or misused. Never leave sensitive data
unprotected and readable. Figure 2 shows a good rule of thumb when dealing with cardholder
data.

Figure 2 - Guildlines for Cardholder Data Elements (PCI SSC, 2010)
Goal three, according to PCI SSC, is to Maintain a Vulnerability Management Program
with three correlating requirements: use and regularly update anti-virus software or programs
and develop and maintain secure systems and applications. These requirements are set so the
PCI system of the business is systematically and continuously finding weaknesses, or
vulnerabilities. To achieve that, using anti-virus software and securing systems and applications
would help to find vulnerabilities to be remediated. Keeping up to date with the software and
maintenance is crucial in preventing an attack, hacking or malware, on the system. “All critical
systems must have the most recently released software patches to prevent exploitation (PCI
DSS, 2010).”If there’s a possible opening for something, or someone, to get through to gain
access to the system, cardholder data could be compromised.
Implement Strong Access Control Measures is the fourth goal in PCI DSS. The
requirements for this goal are restrict access to cardholder data by business need to know,
assign a unique ID to each person with computer access, and restrict physical access to
cardholder data. This goal pretty much states the business should use the principle of least

privileged. Give personnel and systems the access they need to function and nothing more.
Limit the amount of authorized personnel, systems, and processes to cardholder data to avoid
unintentional discloser of the data, and any leaks or breeches. As well, those who have access
should all have unique ID for tracking user action and because shared ID, especially concerning
passwords, poses a huge vulnerability to the data. As with cardholder data transmission and
storage, passwords too should be unreadable and encrypted when being transmitted and
stored. Digital information is just a half of what needs protecting; the physical devices need
protection as well. Ensure that all devices on the network systemare secured and if there are
hardcopies of any sensitive data that, that too, gets some sort of physical protection, like a
guarded locked room. Depending on the size of the business, there may be “outsiders” or other
personnel on the premises. Distinguishing them, their purpose for being in the facility, will add
an extra layer of security to know who’s allowed where and such.
The fifth goal in PCI DSS is Regularly Monitor and Test Networks. The two requirements
are track and monitor all access to network resources and cardholder data and regularly test
security systems and processes. PCI SSC (2010) considers “physical and wireless networks… the
glue connecting all endpoints and servers in the payment infrastructure.” They should be
monitored regularly and tested to find and fix any vulnerabilities detected. Tracking user
activities and logging them would help if anything goes wrong. For a forensics investigation
and/or vulnerability management, logs can act like a trail of crumbs leading back to where the
attack or incident originated from within the network. These logs should be monitored daily
which could help in detecting possible incidents before anything grander occurs to the network.
Since vulnerabilities are constantly being discovered and ever-changing, the security systems

and software should be frequently tested to confirm security is maintained. This is extremely
important when deploy new software/hardware or when any changes are made to the system.
Some tests that should be done are network scans, inspecting the network’s components and
infrastructure, internal and external network vulnerability scans, penetration testing, and
intrusion detection systems. There is a score, what the Council calls the Common Vulnerability
Scoring System (CVSS), on what is considered compliant; the levels can be seen in figure 3. Any
CVSS base score equal to or higher than 4.0 is considered not compliant (PCI SSC, 2010).
Figure 3 - Severity Levels for Vulnerability Scanning (PCI SSC, 2010)
Last goal is to maintain an information security policy, with the requirement to maintain
policy that addresses information security for all personnel. Setting a strong security policy
creates a tone and framework for the business’s environment. The security policy for all
employees to abide by should address all PCI DSS requirements and a yearly review with
environment changes. This would keep all employees on the same page. Since people pose
more of a risk to the integrity of the security, training personnel would lower that risk. A few
suggested methods to take are, screening potential employees before hiring and train them

after hiring, administers should understand the security framework and have the responsibility
to alter certain aspects of the system, ensure that all employees understand the policy regularly,
and monitor users actions and access to data. It’s also good to create an incident response plan
to keep the individual or team in charge of the response in order and not flustered if an incident
occurs on the network. Having policies and guidelines will create a smoother workflow for the
business as well as give it a feeling of a sensitive environment.
Though these are the specifics that PCI SSC outlines in order to be compliant with PCI
DSS, these are actually good practices the follow for any aspect of the business involving the
network. The Council just tailored the best security standards to fit and relate more towards PCI.
The test listed previously, SAQ and QSA, would use these goals and requirements to check
against the business’ current network infrastructure to determine if the business complies with
the stated requirements. If not met, the business must fix and alter the network before being
compliant. Of course these requirements do not need to be met to a t since the level of security
would vary depending on the size, environment, and purpose of the business. For example,
certain aspects should be test regularly or frequently. The exact definition of time solely relies
on the business and what makes sense to its operations.
Since being PCI compliance is a big ordeal, how do the major card companies view it?
According to MasterCard (n.d.), they have their own program called the Site Data Protection
(SDP) Program that’s core foundation is PCI DSS. It requires the merchant to follow the security
and compliance validation requirements before allowing their cardholder’s data to be
transmitted. For American Express, a merchant must comply with their Data Security Operating

Policy, which encompasses PCI DSS as well as their own requirements, before the merchant can
accept American Express cards (American Express, 2014). There are different sets of
requirements, American Express related, depending on the merchant’s level, or volume of
transactions. Discover (n.d.) states that they require merchants to be PCI DSS compliance by
using their own program, Discover Information Security & Compliance (DISC). Besides being PCI
DSS compliance, Discover also requires the merchants to be compliant with PCI PA-DSS. Visa,
following in suite with the other card companies, has its own program developed around PCI
DSS; Cardholder Information Security Program (CISP). This was the original premise for what
turned into PCI DSS and the PCI SSC (Visa, n.d). JCB, a Japanese-based card company, also
follows the PCI DSS compliance heavily. Their program for merchants to ensure compliance is
the JCB Data Security Program. This program doesn’t sway too far from the PCI DSS guidelines,
in terms of adding their own requirements, and gives a simplistic outline and guidance on how
to become compliant (JCB Brand, n.d). The five major card companies, the founders, heavily
stress on being PCI DSS compliant and offer their own customized compliances a merchant
must accept before any transactions can occur.
This just grazed the surface of PCI DSS. The requirements are much more detailed in
goes into more specific suggestions of what should be done that could not be covered in this
paper. As well, there is a portion on how to assess the business’ systemand how to apply for
compliance; finding the scope of the assessment, report on findings, and so on. Not Just PCI DSS,
but PCI as a whole is a grander topic than could be explained in such a short paper. The
Payment Card Industry is a growing one and security is of utmost importance. PCI DSS is a
portion of PCI that deals with the business transaction side. Any business that wants to accept

any form of payment card must be PCI DSS compliant. Major card companies, who also founded
PCI SSC, will not allow transactions of their users for business who are not compliant. No
customer wants to buy a product or service if there’s a high probability of their information
being compromised or blasted out for the world to hear. Before starting a business, or even
expanding, having an understanding of PCI DSS, or even PCI in general will greatly help to make
it successful; at least on the security side.

Reference
American Express. (2014, October). Data Security Operating Policy – United States. Retrieved
from https://icm.aexp-
static.com/Internet/NGMS/US_en/Images/DSOP_Merchant_US_Oct14.pdf#pagemode=
bookmarks&page=1
Discover. (n.d.). Discover Information Security & Compliance (DISC). Retrieved from
http://www.discovernetwork.com/merchants/data-security/disc.html
JCB Brand. (n.d.). JCB Data Security Program. Retrieved from
http://partner.jcbcard.com/security/jcbprogram/index.html
Master Card. (n.d.). Site Data Protection and PCI. Retrieved from
http://www.mastercard.com/us/company/en/whatwedo/site_data_protection.html
PCI SSC. (n.d.). About Us About the PCI Security Standards Council. Retrieved from
https://www.pcisecuritystandards.org/organization_info/index.php
PCI SSC. (n.d.). Getting Started Getting Started with the PCI Data Security Standard. Retrieved
from https://www.pcisecuritystandards.org/documents/PCI SSC Quick Reference
Guide.pdf
PCI SSC. (2013, November). Payment Card Industry (PCI) Data Security Standard. Retrieved from
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

PCI SSC. (2010, October). PCI DSS Quick Reference Guide Understanding the Payment Card
Industry. Retrieved from https://www.pcisecuritystandards.org/documents/PCI SSC
Quick Reference Guide.pdf
Visa. (n.d.). CISP Overview. Retrieved from http://usa.visa.com/merchants/protect-your-
business/cisp/index.jsp?ep=v_sym_cisp

Online_Transactions_PCI

More Related Content

What's hot

Viewers also liked

Similar to Online_Transactions_PCI

Online_Transactions_PCI