Category Archives: PCI DSS

State of compliance vs. compliant, re: New PCI Compliance Study | PCI Guru

A new study was released by Branden Williams and the Merchants Acquirer Committee (MAC), and it is worth a read. One aspect that jumped to me is the percentage of compliance vs compliant rates shared in the study. The difference here is those who have represented being PCI Compliant through Attestations of Compliance (AOC) vs. those who have had their programs pressure tested by the criminals of the world, and been found wanting.

Here is the snippet from PCI GURU that highlights this state of discrepancy:

The biggest finding of the study and what most people are pointing to is the low compliance percentages across the MAC members’ merchants.  Level 1, 2 and 3 merchants are only compliant around 67% to 69% of the time during their assessments.  However, most troubling is that Level 4 merchants are only 39% compliant.

Depending on the merchant level, these figures are not even close to what Visa last reported back in 2011.  Back then, Visa was stating that 98% of Level 1 merchants were reported as compliant.  Level 2 merchants were reported to be at 91% compliance.  Level 3 merchants were reported at 57% compliance.  As is Visa’s practice, it only reported that Level 4 merchants were at a “moderate” level of compliance.

via New PCI Compliance Study | PCI Guru.

Here is the link to the report from Branden & MAC

Board of Directors, CISO, and legal should all care deeply that PCI (and of course and certainly other contractual agreements) security is achieved honestly. To often organizations view this like registering a car with the government. This is far to complex and impactful to people within and outside a given business. The cyber economic connections between proper, efficient, and effective security all lend to better products in the market and more focus on what the business is driving towards.

Is your program honestly secure and fully addressing these least practice principles?



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.


James DeLuccia

Synergy and specificity, a review of Forrester’s Simplify Cybersecurity w/ PCI

The recently published, Simplify Cybersecurity With PCI, by Heidi Shey and John Kindervag is an interesting and valuable read.  The premise is that the government regulations (any really) are generally obtuse and ideal focused without prescriptive how-to descriptions.  While the payment card industry standard (PCI DSS v2.0 in this case) is direct on what and how technology controls should be deployed.  The authors present a synergy that exists that can help an organization establish a security program.

I would definitely recommend businesses struggling to establish a security program to review the concept.  I would challenge those involved in establishing security programs and enhancing such programs to focus on their core business strategies and focus on an iterative cycle, and not simply a controls exercise.  Ultimately I agree there are synergies as described by the authors, and I feel the mappings is quite insightful, but I would pair this with the cyclical nature of an ISMS to round out the edges and make it a more pragmatic and ultimately effective program.

One note also, is that the authors intend that the PCI DSS standard is appropriate for mapping, but I would caution readers and all who utilize PCI DSS.  The standard is specifically articulated for a set of risks and typically bounded by scope of the card data environment.  When utilizing these standards it is important to eliminate and or address these pre conditional weaknesses first, prior to establishing a proper security, and ultimately compliance program.

Other thoughts?  I have personally done many mappings (most recent 134 global regulations and guidances) and can appreciate the value of such alignments, but also with each standard carries assumptions that must be managed at the program level.


James DeLuccia

Release of Symantec source code leads to ‘uninstall’ recommendation

Symantec was the victim of an attack where its source code for most major products protecting consumers and enterprises around the world was breached.  This attack occurred in 2006 and the source code has been available to parties to leverage for attacking businesses, individuals, and governments since that time.  Recently, by the accounts recorded so far, Anonymous gained access to this stolen source code and is now threatening to release it – either generally or for a fee to those who would find value in it.

The result of this has lead Symantec to state in their Security recommendations whitepaper to uninstall or disable the PC Anywhere application.  This is a critical application for most, so such a recommendation is quite difficult.

There are a number of issues and risks that arise here that will likely be an ongoing list:

  • The source code was lost in 2006, so one can infer that this attack vector and every install was at risk to this attack for the past 6 years
  • The presence of source code being released does not in itself create an attack vector – example is how public cryptography is tested openly and the immense use of Open Source software.  In this case though, the release progressively escalated the risk from “increased risk” to “uninstall” now risk
  • Other major enterprise security applications were also stolen, do the same risks exist and are forth coming?

Symantec is an important security provider, as their systems are installed on a 100+ million end points globally and their PC Anywhere solution provides direct access to global companies.

Given the velocity of updates related to Symantec’s breach, I would offer for discussion the following takeaways:

  • There is no silver bullet to be secure and solve this single breach issue in the customer’s of Symantec, so a process must be established
  • Review the activity of your firewalls, behavioral analysis systems, and such systems to determine if you have been attacked through this attack vector … over the past 6 years (deep analysis of the Symantec application is in order – the “authorized and approved” connections activities, not just the failed attempts)
  • Focus on your programs of complicating the intruder to your system – a great case here … if a malicious user had access to your network what could be done.  This question should provide a substantial return in minimizing this type of breach of trust in the security model.  Similar cases should include Microsoft remote tools, operating system, and other infrastructure high install base applications.

Below are references to the article, paper, and Symantec’s update page.

This impacts all secure environments – PCI and other systems that are depended upon.  Perhaps the attack is not intended to modify or damage a system, but for corporate espionage and such.  Strong practices and a aggressive risk assessment review cycle is in order – such as ISO 27001 ISMS (done correctly and maturely).

Thoughts?  Corrections?

James DeLuccia

Implications of Data Breaches on OOW, beyond the PCI equation

Over the years I have been expressing the implications of out of wallet authentication information and “personally unique” data of individuals.  My journey led me to write the book, IT Compliance and Controls, where I sought to humbly draft operational activities for businesses to defend their intellectual property (and customer data, of course).  I launched multiple businesses with partners; created technology; filed patents, and even helped elevate the risk related to publicly available data used by data analysis companies (unfortunately still not able to disclose details here).

Despite this journey, the data that makes up information identifying individuals is still not operationally or industry-wise protected.  To be clear, the information I refer to here (a limited list) includes that which is a fact about a person.  The value of that fact is directly related to the frequency of change.  So as an example:

  • Last name = Only changes rarely (not very valuable on could argue though)
  • First pet = Never changes (very valuable for OOW authentication questions)
  • Last 4 digits of Social = Never changes (very valuable)
  • Last 4 digits of fav credit card = Changes maybe every 3 years (somewhat valuable)

Other data is also valuable but requires a bit of Google hacking / FB / LinkedIN skimming …  Simply enough .. code is executed to create a full database of personally relevant data of a target person and that is used to construct targeted phishing emails and password generation attack databases.  Needless to say, public information and those used when setting up accounts are VERY vital to information security moving forward.

The most recent breach that hit a good company is Zappos.  I as a customer received the regular breach email stating what data was lost.  They setup the site to orchestrate the password reset process and made it extremely simple.  (There are challenges here but to be discussed shortly).  The communication did state though that such details as full name; email; billing and shipping address.  All vital and still sensitive, but not yet protected as mentioned above.

The process of the password reset and refreshing of customer data is a challenge post breach.  What to protect and what not to protect?  A prime question when setting up the post-breach authentication and refresh process.  I would posit that the email link is not sufficient to protect the consumer, as that information could easily be leveraged as a secondary attack against the user.  I would also state I manually went to the Zappos website to see if it was a real notification or trick.  It was real, but the simplicity of their process drew into question the validity still – I actually began checking registries to determine if DNS poisoning / redirection was occurring.

The takeaway of this post is … consider the value of the data on hand and the implications of security safeguards – both regulated and as proper custodians of such information.  Second, how would you recover from a breach and what data would you rely upon?  Have you secured that data in a manner representative of the dependence you place upon that information?

Simply enough .. consider the types of data you are custodian; today, historically, and in the future .. and how could that information be leveraged – for and against you, the customer, and society.  I draw this distinction out as businesses and the data they rely upon is interrelated.  An example is the email software as a service company that was breached, and suddenly vendor third party arrangements became strikingly naked when the tide went out.

Don’t be left standing naked my dear security industry.


James DeLuccia IV

*Join me in RSA SFO for security forward discussions, and at the IIA GAM 2012 Conference in March on Social Media Technology Risks.