Tag Archives: visa

Connected Systems of PCI – Identifying; Securing; Attesting

The payment card industry standard articulates very prescriptively what should be done for all system components that are within the payment card process.  An area of usual confusion is the depth of abstraction that should be applied to the “connected system” element of the standard.  Specifically, the standard states the following:

The PCI DSS security requirements apply to all system components. In the context of PCI DSS, “system components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. ―”System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (for example, Internet) applications.

– PCI DSS 2.0 page 10

To simplify – there are the system components that are involved with the payment card process, and then there are the supporting systems (connected systems) that also are in scope of PCI DSS.  An example would be the patch server where the in-scope PCI system is receiving patches (but there are dozens).

So a rule of thumb on scope most offered in the industry is:

If you can digitally communicate with the system it is a connected system (this includes UDP, TCP, etc …) it is in scope.  

A nice write up by Jeff Lowder referring to specifically the security system components can be found here written in 2010.

A Korzybski abstraction problem:

How many levels of abstraction should one undertake?  Meaning – should that same patch server then be examined to see what systems are connecting to it and thus also be included in the ‘connected system’ web?

The answer here is generally no – the abstraction is only one level deep.  That doesn’t mean best practice risk and security practices evaporate, so no leaving that server unpatched on the internet or anything.

What Requirements of PCI DSS should be applied to these ‘connected systems’?

The standard makes it clear in the beginning “The PCI DSS security requirements apply to all…”  So, every PCI control applies to the connected system under discussion and identified through the abstraction of the services supporting the CHD environment itself.  Limitations can be applied to the core system components that make up this “connected system”.  Such as in the virtualization space, the hypervisor risks and controls are differentially applied from the entire standard.  These exceptions from fully applying the PCI standard directly to the connected system must be limited and done with clear awareness.  [Updated: All requirements should be considered … each QSA is different but addressing the risk with an eye towards compliance is the best and safest bet.  Shopping for someone to accept a state of controls is a painful road]

An “Open PCI DSS Scoping Toolkit“(pdf)  published on August 24, 2012 is available that provides an excellent structure in methodically determining scope and the controls that would be applicable.  While not a product of the PCI SSC or a technical group – there is good content here that should be carefully considered as part of every security and compliance strategy.  Thanks to Eric Brothers for the note! [Updated 12/5/2012]

Another good write up is offered here where a good articulation on the two factor authentication exception; file integrity monitoring exception, and a few other practices are nicely elaborated by Andrew Plato (Plus check out the comment threads.. very informative though proceed with caution as this is one QSA interpretation).  Definitely worth a review, though sadly after a review there appears no other elaborations within the PCI SSC on this topic.

This write-up is an exploratory effort to seek clarity by consolidating thoughts of leading individuals in the payment card space and client environment realities.  Any additional insights or perspectives you have are welcomed and requested in the comments below!  I’ll update as anything is shared.

Best,

James DeLuccia

Having a ROC does not make an organization secure or compliant – a view into the risks of PCI and periphery events

Why should an organization address and comply at least with industry supported practices?  A question of compliance versus driving business value, and one often raised in the Payment Card space is important to understand and convey at every level of an organization.  The importance is building an organization’s security and compliance program in a manner that cohesively manages the demands of client requirements, government cares, and general competitiveness.  In an era where competitiveness includes thwarting attackers focused on poisoning your supply chains with misinformation or directly seeking to “acquire” the Intellectual Property that makes the business competitive.  The executive and board of directors within an organization are acutely seeking demonstration of focus and effectiveness.

So what are the risks to an organization not managing the risks of an industry standard?

To answer that below I will speak directly to PCI (to eliminate the obnoxious “it depends” statements) and about a Fortune 500 company that has other intellectual property.

Ultimate risk to an organization out of compliance with PCI is well documented (on the Card Brand sites themselves and breach news sites), but stems from a violation of contractual agreements with the business’ banks and ultimately the card brands.  This contractual obligation (and violation) can be determined without a breach.  The violation (profiled in a public court case out West) can be identified when a QSA / Forensics team from the Card Brands / or any of their team members conduct an assessment of compliance to the organization.  The court case referenced is of a restaurant that had been suspected of a Common Point of Fraud; proven to not have been breached, but in violation of PCI DSS based on forensics report issued to Bank & Card Brands).  So, the risk and associated damages can result from a breach (classic) or simply by confirmation that the business violated the contract established with the Card Brands.

The highlight here is being compliant means addressing the threat vectors to the business and the assets requiring protection.  Failure to achieve those results from either path can result in a number of business and financial negative events.  These, in part, are described below:

  • Financial punitive fines by the Card Brands ($500k is a number published by the Card Brands)
  • Per account # breached associated costs & fines – this number is a hard figure to lock down .. $100-$170 per card in some cases
  • Higher interchange fees per card transaction for the entire legal entity – this is very costly and most damaging
  • FTC and public government actions, that may include recurring privacy audits (such as 20 years of third party audits)
  • Automatic level 1 status for the company (which requires annual onsite attestation)
  • If you look at TJX and the other public breaches they have published hose expenses around $130M+
  • Civil / class action lawsuits likely

There are also reputation and periphery risks to the business:

  • The company possesses additional data protected and considered sensitive by industry and governments around the world, PCI Data is one element but it is likely that these systems share networks, applications, and permissions.  The breach of one could inadvertently result in the breach of the other (PII)
  • Not at least complying / deploying operational security controls broadly considered baseline practice would be damaging in an era when security of data and confidence is so important

The highlight here is that the risk is not addressed by the issuance of a ROC by a QSA or having run assessments, but that the security and risk programs are operational and effective.  These ROC and assessments are simply attestations of a program that is mature and functioning.  Compliance is not deemed by a ROC nor does it provide safe-harbor in the common sense of the term.  A long standing statement by the PCI SSC is that “no compliant organization has had a breach” <– including TJX, Heartland Payments, and Global Payments all breached with current ROCs signed by TrustWave.

The success of the PCI program is the ultimate reduction of risk and adequate security controls of the organization.  The risks addressed through a cohesive integration with the operational elements of the business are the critical success factors.

Other thoughts?

James DeLuccia IV

Visa allows international Merchants to not demonstrate PCI DSS compliance

On February 11, 2011 Visa announced an interesting program that promotes and demonstrates the fraud deterrence strength of the Europay, MasterCard and Visa (EMV) smartcard standard and are also equipped to accept both contact-based and contactless transactions.  Those organizations that have at least 75% of their transactions originating from smartcard-enabled terminals will not have to demonstrate compliance.  This is perhaps a reflection of Visa weighing the risks and benefits of technology from a risk management point of view.  A win for merchants certainly, as this technology is widely adopted in many parts of the world.

As a reminder, all organizations within the Payment Card Industry must be compliant with the data security standard, but the nuance of demonstration / attestation is based on the channel and volume of each individual card.  This program of Visa does not impact the other Card brands, so international Merchants will still need to consider these within their global compliance and security programs.

An interesting writeup on the article is available at Computerworld here.  The press release is here.

The deployment in the U.S. requires both adoption at the Merchant level, and the consumers too.  It would be interesting to compare the costs of the EMV architecture vs. the compliance costs of organizations.  I also wonder if the net benefit of requiring security controls to be meaningfully applied to sensitive data (in this case PCI) does not raise all the “boats” (read: other sensitive data types), as it is more likely that security safeguards are applied broadly.  Is this demonstrated by 28% reduction in identity thefts in 2010?

See you in San Francisco at RSA 2011,

James DeLuccia

Payment Application Best Practices – Top 10, by Visa

Visa has been phenomenal on providing clarification, tools, guidance, and clarity to secure CHD sensitive data and the payment networks.  Visa released on 8/24/2010 the Visa Best Practices document “Visa Top 10 Best Practices for Payment Application Companies, Version 1.o”.  The PDF is available here and is a concise 5 pages.  While directed towards application providers there are interesting and applicable practices described that all operators should consider.

The Best Practices are broken across several domains that go beyond simple software coding checks, but include:

  • Organizational Security (Background Checks, Training, Certifications)
  • Mature Software Development (SDLC, upgrade cycles in line with PA-DSS)
  • Product Vulnerability Management (App detection tests and Code reviews against common vuln & weaknesses)
  • Secure Implementation (Contractual PA-DSS requirements, Enforcement of secure installations)
  • Emerging Payment Technologies (Adhere to field encryption, token, and PAN elimination, support future dynamic solutions)

The press release provides a nice breakdown of the document from Visa, and can be found here.  In addition, SANS has launched a training series that aligns with the training aspects highlighted in this Best Practice (note this is Best Practice, not a mandate).  Finally two sections that should be carefully considered by all operators is section 8 and 10.

Section 8 states, “Implement an installer, integrator and reseller training and certification program that enforces adequate data security processes when supporting customers” – loosely meaning that these technologies should deploy out-of-the-box secure/compliant.  This is places the onus on the provider of the technology to address the challenges of security, and appears to set an expectation on the user of such.

Section 10 highlights the need to “Support capability of dynamic data solutions across payment applications”, and suggests that fundamental changes in how the payment transaction environment exists today will flex in the future.  Not a severe interpretation given the velocity of changes in this market, but again the imperative is for these providers to be flexible.

A nice set of practices for a specific challenge.  Thoughts?  Concerns?

James DeLuccia

Do ISO entities need to be PCI DSS Compliant?

Who needs to be compliant with the Payment Card Industry Security Standards Council standards?  Well, the default response is usually – anyone who stores, process, and transmits card holder data.  There is constant discussion on pre-auth / post-auth / banking partners / etc..

A recent question I received was … Do ISO (Independent Sales Organizations) need to be compliant with PCI DSS?

This is a great question because it brings into the forefront the Third Party Providers.  While the classic response – “it depends” applies generically, let me elaborate and provide where it DOES exist.

According to Visa’s website, an ISO for this definition is also more broadly classified as a “Third Party Agent”.  Specifically here are the various functions that can be performed (This is key for eliminating the it depends statement from your situation):

A TPA can perform any or all of the functions of an: Independent Sales Organization (ISO), Third Party Servicer (TPS), Encryption Support Organization (ESO) and Merchant Servicer (MS). Each function performed by the TPA must be registered by each Visa client that is utilizing those services. TPA functions that require registration include but are not limited to:

  • Merchant or cardholder solicitation activities and / or customer service — these are performed by an ISO
  • Prepaid program solicitation activities and / or customer service — these are performed by an ISO
  • Loading or injecting encryption keys into ATMs, terminals or PIN pads — these are performed by an ESO
  • Loading software into an ATM or terminal — these are performed by an ESO
  • Storing, processing or transmitting Visa account numbers — these are performed by either a TPS or a MS
  • Deploying and / or servicing ATMs – these are performed by an ISO

Beyond registration requirements, all service providers – need to be compliant, as it is the acquiring banks liability if they are not.

Both issuers and acquirers must use, and are responsible for ensuring that their merchants use, service providers that are properly registered with Visa. Where applicable they must also ensure that all such entities are compliant with the PCI DSS and PCI PIN. Although there may not be a direct contractual relationship between merchant service providers and acquirers, Visa acquirers are responsible for any liability that may occur as a result of non-compliance.

In addition, Visa has provided enhanced clarification in their list of ISOs (published 7/15/2010) that lists registered organizations.  The document states that “entities utilizing this list should perform their own additional due diligence to ensure that the service prover is also compliant with any additional requirements that the entity may have in place.”… “Entities that store, process or transmit cardholder data must be registered with Visa and validate PCI DSS compliance.”

There are certainly relationships that may provide exceptions, but the process above shows that if you store, process, or transmit card holder data – proper security and compliance (and Validation where appropriate) with PCI DSS is necessary.

Thoughts?
James DeLuccia IV

Global Best Practices for Tokenization, Visa

On July 14, 2010 Visa released version 1.0 of their Tokenization best practices document.  This follows up previous publications on data field encryption.  The release is brief, but provides several interesting data points that Merchants, Providers, and Practitioners should consider.

Visa breaks down Token systems into 4 Unique Components:

  1. Token Generation
  2. Token Mapping
  3. Card Data Vault
  4. Crytographic key Management

A broad set of best practices are highlighted throughout the rest of the document and well worth a review (Here is the direct link to the PDF).  A few specific items that were interesting:

  • The Tokenization system must be segmented and “be subject to a full PCI DSS assessment” – note this does not say QSA audit, but rather implies a confirmatory action by the owner of the system.
  • Monitoring suggests a need to “detect malfunctions or anomalies and suspicious activities”, which are far more fraud focused.  In addition there is mention of rate limiting functions, which would be beneficial beyond the token-PAN mapping environment
  • The Token must be so designed to “not be computationally feasible” to recover original PAN.  A token may be created using EITHER a “known strong cryptographic algorithm” or a “one-way irreversible function”

This publication is meant to provide high level guidance, and Visa is seeking any comments by August 31, 2010 (send messages to inforisk@visa.com w/ “Best Practices for Tokenization” in the subject).  In previous publications Visa has issued more granular publications following these high level documents, so feedback and comment is important.

Best,

James DeLuccia IV

Visa Europe on Data Field Encryption, PCI DSS

This month (March 2010) Visa Europe released a full guidance document on Data Field Encryption: Device and Key Management Guidance.  This relates directly to “end-to-end” encryption, “point-to-point” encryption or “account data” encryption and the process of securing transaction data in transit and in storage.  This has been a critical focus of the payment card community.  A nice article highlighting the benefits of this guidance document and endorsements by major organizations in Europe can be found here.

Simply put though, the guidance provides 71 pages of excellent specific data on what these technologies should be doing at minimum.  This provides operators and auditors with a tool to compare equally the unique solutions being deployed globally, and a common baseline of control safeguards.

The full guidance document may be downloaded here.  A direct link to the PDF is here.

Please note this is focused on Visa Europe.

Thoughts and concerns with this guidance and / or the technology?

James DeLuccia