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.

Planning for and Implementing ISO 27001 .. a review and ideas

Below are my highlights and comments on the ISACA article ‘Planning for and Implementing ISO 27001” by Charu Pelnekar was published recently and is available in its full detail on ISACA’s website.  Definitely worth a full read.  Below are a few highlights that leaped from the page that I wanted to highlight.

Benefits of establishing an ISMS:
  – “Enable enterprises to benchmark against peers” <– Highlights a good question, how are YOU benchmarking your information security efforts?  Are you basing it on staying out of the WSJ and riding the media wagon, or are you doing something different.  Industry surveys, publicly traded company statements, and industry sector considerations are excellent perspectives.  Considering the maturity and benchmarking that program against comparable peers – based on revenue, complexity, locations, sector, what is sensitive, customer base, and legislation are equally valuable (and seldom considered completely)

  – “Provide relevant information about IT security to vendors and customers” <– Responding to multiple client and partner information security verification audits is a necessity today.  A trend that will continue until the use of standards and their adoption is consistent and proven.  Further highlighted by the author when considering the benefit of gaining a “Comfort level of interoperability due to common set of guidelines followed by the partner organization”.

  – “Enable management to demonstrate due diligence” <– There is legal precedence that the existence, operation, and proven maturity of an iSMS to be a significant factor in determining a business proving due diligence with regard to safeguarding information.

  – “Assist in determining the status of information security and degree of compliance” <– A worthwhile pursuit and consideration for the risk management and internal teams within every organization.  Pivoting / Agility / Adaptable / (insert latest phrase here) organizations need to constantly adapt how they innovate, similarly they should evaluate the adequacy of their current information security programs (the actual program) and the effectiveness of the program.  This is not a commitment to grow, but instead to shift left and right as needed at the current time.

Costs of implementation depend on numerous factors, but a highly sensitive variable is the health of the IT organization and sophistication of the enterprise information security program.  Within the ISMS is the process of risk assessments designed to identify risks – the greater the number of risks and necessary remediation costs can be significant (with respect – this is not the cost of implementing the program, but instead of raising the operating state of the organization in line with the risk tolerance of the business.  Regardless, these must be managed appropriately in order for the ISO 27001 to be considered effective and certifiable.

The complexity to managing and operating a mature information security program that adheres to ISO 27001:2005 is dependent upon several factors, but one s standout is the scale of operations – that can be defined as “# of employees, business processes, work locations, products and or services offered”

Implementing an ISMS for an organization begins with several key and required efforts.  The sequence, thought, and support applied to each ensures that the business has an enhanced information security posture that is both sustainable and meaningful.  These include:

  1. Defining the ISMS Policy
  2. Defining the scope of the ISMS
  3. Performing a security risk assessment (on the in-scope environment)
  4. Managing the identified risks with consideration of the risk tolerance and risk criteria
  5. Selecting controls to be implemented and applied, and finally preparing the SOA.

The article published by ISACA in Volume 4 2011, available for free to all members, and the author provide a nice high level breakdown on what is required for an enterprise to reach ISO 27001 certification.  I would add that linkages is the only major high level component absent in the article.  Linkage throughout the program is essential to ensuring a cost effective and business appropriate program is established and maintained.

For those serious about maturing their organization, ISO 27001:2005 is a good objective.  For deeper understanding on what is required I would encourage purchasing a copy of the entire 2700X standard family to have full understanding on implementation; safeguard controls; and risk assessment programs.  A nice article on SANS on implementing an ISMS is available here (pdf).

Another way of considering the benefits of a mature security program…is will an organization be compliant with PCI DSS or other legislative requirements as a result of implementing ISO 27001.  Simple answer, yes. Longer answer another day.

Thoughts and challenges?

– James DeLuccia

PCI DSS 2.0, the update and you…

A tremendous amount of focus has been upon today when the PCI Council released publicly the latest standard for the payment card industry.  There undoubtedly will be an incredible amount of discussion on the varied points, and I will try to identify the most valuable over the next several days.  To that point, though I wanted to highlight a few nuances that enterprises must consider with regards to this new standard.  Most importantly, how the payment card industry is evolving.

The new standard, available for download today, has numerous points of clarification and expansion on security controls – all designed to secure the highly trade-able data.  Interesting highlights:

  • Further clarification that businesses cannot outsource their compliance to a third party, nor can a contract satisfy third party compliance agreements.  This has been very clearly stated for a long time within the Card Brands (Visa in particular) operating regulations, but is now stated absolutely in page 16 and again under requirement 12.8.  A nice post available here goes into greater detail.
  • The new standard focuses more on ensuring actual controls are effective and operational and less about simple paper verifications.  This is a change as it approaches the intent of the standard, and will provide better ability for organizations to protect their card holder data. (i.e., 12.9 ‘Be prepared to respond immediately to a system breach.”)
  • The usage of ‘All’ is more frequent in the new standard.  This covers areas of policy consideration and technical solutions.  Careful awareness of the scope of the payment environment will ensure lower risk, and greater ability to weave the PCI DSS 2.0 into enterprise security programs.
  • Greater updates also were focused on the Compensating Controls section, and should be carefully reviewed going forward.

Branden Williams’ always has valuable data points, and his article related to the new release can be found here.

More to come in the very near future, but in the meantime – read the standard yourself; consider your organization’s moving forward strategy; develop a comprehensive data security program that includes PCI controls and risk considerations, and of course consider the business objectives from all angles.


James DeLuccia