PCI DSS

06/16/2014

The payments industry is full of abbreviations and acronyms. Let’s take a look at the 5 most common ones we use and their definitions.

PCI DSS stands for Payment Card Industry Data Security Standard – A set of security requirements for all businesses that handle payment cards, including merchants and software developers of applications that handle payment card data.

P2PE is the acronym for point-to-point encryption. P2PE ensures sensitive cardholder data is protected from first card swipe or key-entry, while in transit, all the way to the payment processor. Encryption renders the credit card data so that it is unreadable and valueless should it become intercepted during the transaction life cycle.

POE, known as Point-of-Entry is the initial instance when cardholder data enters the point of sale through a payment device by swiping or manually keying a payment card.

CDE stands for cardholder data environment. A merchant’s CDE is made up of all of the components used to process, store, or transmit cardholder data.

EMV stands for Europay, MasterCard, and Visa. Named for the organizations that originally backed the initial development, EMV is the transaction protocol that uses microchips on payment cards to authenticate the card vs. traditional magstripe data.

01/31/2014

As we have seen, the Payment Card Industry Data Security Standard (PCI DSS) requires businesses to utilize alphanumeric passwords of seven or more characters. This is certainly a sound practice—but password security involves additional aspects that are also vital for maintaining PCI compliance. Let’s take a look at the various other password requirements set in place by the PCI DSS.

Requirement 8.2.4 of the PCI DSS calls for organizations to change system passwords every 90 days, if not sooner. An account-lockout policy is also an important component of a business’s overall data security strategy. This involves locking a particular account—that is, preventing further access attempts—after a certain number of failed login attempts. Requirement 8.1.6 requires organizations to lock accounts after no more than six failed log-ins. The account should remain locked until at least thirty minutes have passed or a system administrator reactivates it.

The account should also be set to require a user to reauthenticate their identity—i.e., re-enter the password and, if needed, ID name—after the session has been idle for 15 minutes. If appropriate, the system administrator can set the account to allow an even shorter idle period before demanding reauthentication.

01/29/2014

The Payment Card Industry Data Security Standard (PCI DSS) provides sound guidance on password requirements for businesses of all sizes. Requirement 8.2.3 calls for passwords to be at least seven characters long and contain a mixture of alphabetic and numeric characters. For example, a password such as b56aq8g meets the minimum PCI DSS requirement, while ones like a35r4 (too short), 394958301 (no letters), and abcdefg (no numbers) all fail to comply.

It’s worth emphasizing that the PCI DSS password guideline is the minimum standard with which an organization must comply. A business is allowed—encouraged, in fact—to go beyond the baseline requirement laid down by the PCI DSS. Passwords longer than seven characters can provide substantially more security. However, long passwords carry the disadvantage of being harder to remember. Also, not all systems can handle unusually long passwords. If this is a concern, keep in mind that adding just one or two more characters can make the password more secure.

Due to technical limitations, some businesses aren’t able to create the required seven character password for their systems. For these organizations, the PCI DSS 3.0 allows them to apply an “equivalent strength” standard to create passwords that meet the security level of a seven-character alphanumeric password. One strategy to bolster the strength of an inadequate password is to use one or more symbol characters (e.g., @, !, &) if the system supports this option.

01/07/2014

It is important to maintainin an up-to-date payment processing environment and keepkeep track of all of the various components that make up the environment. Nowadays, businesses find themselves juggling an ever-increasing number of hardware and software products, and keeping a proper system component inventory can seem like more trouble than it’s worth—but this type of inventory is an essential part of any company’s data security plan. It is also required by the PCI Data Security Standard (PCI DSS) under Requirement 2.4.

The Standard requires PCI-compliant businesses to “maintain an inventory of system components that are in scope for PCI DSS.” There are two practices that a business should follow to ensure that this happens:

The list should be checked on a regular basis to test whether it is properly maintained. It should include not just a simple listing of products, but also a description of each item and its function.

The company should regularly consult with relevant personnel to ensure that the list is continually updated.

12/09/2013

Authentication and session management is an aspect of data security relating to the regulation of user interaction within a system such as log-in procedures, session cookies, time-out policies, and similar elements. The suboptimal implementation of these elements can pose a security risk, allowing unauthorized persons to gain access to areas and systems where they do not belong. Broken authentication and session management has never been explicitly covered in the PCI Data Security Standard (PCI DSS). Version 3.0 of the PCI DSS includes the brand-new Requirement 6.5.10, which calls for organizations to regulate this aspect of their internal and external application interfaces. This requirement joins preexisting instructions that governed cross-site scripting (6.5.7), improper access control (6.5.8), and cross-site request forgery (6.5.9).

This new requirement directs businesses to interview relevant personnel and consult applicable documentation to guarantee proper authentication and session management. Version 3.0 mentions three specific examples of session management techniques that should be implemented:

Marking cookies and other session cookies as secure

Ensuring that the session ID doesn't appear in the URL

Applying session time-outs and rotating IDs

A PCI compliant organization should take steps to ensure that keys, account credentials, and session tokens cannot be exploited by unauthorized personnel. Incidentally, those who worry about this new guideline should be aware that Requirement 6.5.10 is listed as a best practice until June 30, 2015; it does not become a requirement until after this date.

12/06/2013

The release of the Payment Card Industry Data Security Standard (PCI DSS) 3.0 has brought a variety of tweaks and modifications to the established data security guidelines. One portion of that has been updated is Requirement 5, which addresses the proper procedures for maintaining anti-virus software and programs. Version 3.0 avoids making massive changes in this particular area, but the revisions to Requirement 5 are significant and worthy of note.

Among these revisions is the addition of Requirement 5.1.2. This new section calls for businesses to "perform periodic evaluations to identify and evaluate evolving malware threats" in order to ensure the continued safety of systems that are generally unaffected by Internet-based hazards. The addendum complements the preexisting Requirement 5.1, which compels organizations to use up-to-date anti-virus programs to protect systems "commonly affected by malicious software." The change is acknowledgement of the fact that hackers and other cybercriminals continually invent new and improved ways to obtain sensitive data; a system that may be reasonably secure, today, could easily be targeted for exploitation, tomorrow. Therefore, businesses are now required to monitor emerging cyber threats to ascertain whether a given system should be granted protection by an anti-virus program. Monitoring may be carried out in a number of ways, from checking Internet newsgroups, to reviewing security notices from vendors.

Requirement 5.3 is another addition to the PCI DSS; this calls for organizations to ensure that anti-virus programs cannot be changed or turned off except as a temporary measure to address technical needs, and then only by authorized personnel whose approval to do so is granted on a case-by-case basis. This expands on the previous version, which simply stated that businesses must ensure that their anti-virus programs remain "actively running."

08/30/2013

It seems as if hardly a week goes by without
hearing news of some potentially catastrophic "zero day"
vulnerability that threatens to turn our computers into playgrounds for nosy
hackers. To ensure PCI compliance, it's essential for merchants to install security
patches on a regular basis to guarantee up-to-date protection against system
weaknesses. Neglecting to carry out this operation properly can cause several
problems for businesses. An organization that ignores security updates could
not only fall victim to a data breach but fall out of PCI compliance as
well. Businesses that still utilize Windows XP are
being urged to upgrade to a more recent operating system--Microsoft will end of
life XP operating system in 2014, which means security patches will also cease.

The PCI Data Security Standard (PCI DSS) requires businesses to install
security updates within one month of release. Merchants should maintain a
written policy that ensures compliance with this requirement. Furthermore,
companies should have a list of security updates that have been applied to
their systems; this should be checked against the most recent vendor-supplied
security patch list to make sure that nothing has been overlooked.

Sometimes businesses have trouble applying these patches in a timely fashion.
Harried IT personnel may be pleased to learn that the PCI DSS acknowledges this
difficulty and allows for an optional "risk-based" approach to
installing patches. Businesses may prioritize their security updates by
arranging their various system components in a hierarchy, in which the most
critical components are scheduled to receive updates sooner than less critical
ones. Under this system, highly critical components (e.g., customer-facing
systems) will still be updated with relevant security patches within the
standard one-month period, but less critical devices can delay installing them
for up to three months. Data-security personnel who are pressed for time can
concentrate on addressing the important systems, without fear of violating the
PCI DSS.

08/14/2013

Since the release of version 1.0 in December
2004, the PCI Data Security Standard (PCI DSS) has been hugely influential in making
payment card transactions safer for everyone. Even so, some in the
business community remain a bit flummoxed by this large, frequently updated
document, with its twelve requirements that each contain a variety of
subsections. The PCI DSS is less imposing than it may seem at first
glance. In fact, it can be said that its various aspects are all designed
to achieve one specific goal: protecting cardholder data. This data -- the
(usually) 16-digit number printed across the front of a credit or debit card --
is the most important type of information associated with payment processing,
and its proper handling is the main focus of the PCI DSS. The document
governs the proper handling of payment account numbers (PANs) through every
stage of their use -- processing them, transmitting them, and storing
them.

If a business never handles PANs in any way, which is sometimes the case with
small, cash-only merchants, then it is exempt from the requirements of the PCI
DSS. Businesses of this kind are increasingly uncommon these days,
though, so it's very probable that you have to contend with the PCI DSS

The unique importance of the PAN explains why it is subject to security
requirements above and beyond those that are considered non sensitive data (e.g.,cardholder
name, card expiration date). The PCI DSS calls for PANs to be stored (if
they are to be stored at all) in a manner that renders them unreadable, which
can be achieved through tokenization.

07/01/2013

Requirement
11.2.2 of the PCI Data Security Standard (PCI DSS) compels merchants to
“perform quarterly external vulnerability scans via an Approved Scanning Vendor
(ASV).” The purpose of these scans is to ensure that a company maintains
up-to-date security measures that can protect its systems against the most
recent cyber threats. For many, these vulnerability scans are a bit of a
mystery—most people understand that the scan itself helps ferret out security
weaknesses in an organization’s system, but they’re unsure what exactly goes on
during this procedure. To clear up this confusion, we can turn to the PCI
Security Standards Council, which has helpfully provided some answers in its
“Approved Scanning Vendors Program Guide (Version 2.0).”

The ASV Guide sets forth a series of General Guidelines that ASV scans must
follow. Keep in mind that Approved Scanning Vendors get their
certification through the PCI SSC, so these guidelines must be followed if the
ASV is to remain listed on the Council’s site. According to the Council,
ASV scans must:

“Be Non-Disruptive”—ASV scans must not interfere
with the normal functioning of a company’s systems. Tests forbidden
by the PCI SSC include those that involve buffer overflow exploits,
rootkit installation, or interference with DNS servers.

“Perform Service Discovery”—The ASV must perform a scan on
all Transmission Control Protocol (TCP) ports and common User Datagram
Protocol (UDP) ports.

“Perform Host Discovery”—The ASV must attempt to ID live
systems.

“Perform OS and Service
Fingerprinting”—The
scan should ID the operating system associated with each live system and
ID the protocol and application version associated with each open port.

“Have Platform Independence”—The ASV scan must be applicable
to all common platforms.

“Account for Load Balancers”—The ASV’s report must detail the
client’s use of load balancers. If necessary, relevant documentation
should be obtained from the client.

“Be Accurate”—The ASV has a responsibility to
report all confirmed and potential vulnerabilities.

06/19/2013

The kinds of
hardware and software commonly used by merchants, such as a point-of-sale (POS)
application, generally comes with a simple default password and setting to
allow easy initial access. But many users make the grave mistake of
failing to change these default passwords and settings—this leaves devices and
applications vulnerable to hackers and other unauthorized persons. Lists
of default passwords, encryption keys, and SNMP settings used on specific
devices circulate widely among hackers; a business that retains these defaults
effectively leaves a door open for troublemakers. Furthermore, retaining
default settings means a business falls out of PCI compliance, as the Payment
Card Industry Data Security Standard (PCI DSS) calls for these to be changed
“before installing a system on the network” (PCI DSS requirement 2).
Default passwords must be updated as soon as possible, and should meet the
following requirements in order to maintain PCI compliance: