Tag Archives: pci

Who will be the Jamaica Ginger of Information Security?

I read a short section in Bruce Schneier’s book Liars and Outliers that tells the tale of Jamaica Ginger:

“an epidemic of paralysis occurred as a result of Jamaica Ginger… it was laced with a nerve poison… and the company was vilified”, but not until 10s of thousands were victims, this resulted in the creation of the FDA.

To date, throughout most industries there is no absolute requirement with meaningful incentives to introduce and sustain operational information technology safeguards. There are isolated elements focused on particular threats and fraud (such as, PCI for the credit card industry, CIP for the Energy sector, etc…). So what will result in the Jamaica Ginger of information security?

Some portend that a cyber-war (a real one) that creates such societal disruption; a long enough sustained negative impact to survive the policy development process, and driven enough motivation to be complete. OSHA, FDA, and other such entities exist as a result of such events.

The best action enterprises can follow is to mature and engage sufficient operations that address their information technology concerns in the marketplace. As a means of self preservation; selfish (perhaps) demonstration of a need to NOT have legislation or a body established (such as the Federal Security Bureau), and ultimately preparedness should such a requirement be introduced the changes to your business would be incremental at best.

Other thoughts?

James DeLuccia

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

How to improve the maturity of your security program – Learn from mistakes made others!

Organizations struggle with a complex information security compliance program needs placed upon the organization.  Mature organizations participate in regular self review and improvement activities on an annual basis, and in some organizations as regular as monthly.  These organizations are fortunate to have larger security teams that reflect the global (think Fortune 500) deployment of assets.  This network provides an immensely valuable feedback loop on the following, among many others:

  • What are effective practices
  • What policies are great for the business, and where are exceptions being raised frequently that may indicate unknown business requirements
  • Attack patterns and weaknesses in the security program based on statistical review of events within the business
  • Where are programs meeting customer / client requirements – based on sales attributions and audit findings, respectively.

For organizations of this sophistication and those of all other sizes there is an additional input that raises the overall efficiency and effectiveness of the security compliance program.  That is through a self comparison against public data.  Specifically data released by government audits, intelligence committee reports, and guidances / complaints issued by government enforcement agencies.  These are immensely helpful in providing businesses across all sectors insights into security threats, trends, shifting perceptions of “due care”, and areas where risks are ebbing and flowing.

A simple set that an organization may consider includes:

The takeaway here is that every organization should regularly identify these sources, consolidate them in a manner that can be analyzed, and develop an intelligence report on any gaps in practice and security controls as documented by these organizations.  These apply to every organization and not simply those in the government space.  The process of careful analysis against the organization’s strategy combined with the rote knowledge of the practitioners internally can support realizing these benefits.

The genesis of this article was inspired through close workings with Fortune 50 organizations and developing leading global security programs.  A nice article illuminating this and other opportunities for improvements to security compliance programs is by Adam Shostack, in “The evolution of information security“.  A very good read.

Thoughts .. and expansions of idea are always welcome!

James DeLuccia IV


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

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

Compliance mandates do not make up your enterprise security program (PCI, SOX, GLBA, etc.. included)

A challenge for large businesses is addressing their own information security needs to manage their operations in a manner that allows them to be resilient and adaptable in an ever competitive market place.  Each organization is different – the risks and the needs to mitigate.  A painful evolution of the past decade has been the mistaken direction organizations have taken to build / address singular compliance instances.  Meaning, organizations develop programs to address single compliance requirements – vendors, SEC, industry, etc …  Not that these are not important, but a natural effect of this is the perception that the security “controls” (even the word doesn’t lend itself in the right non-audit light) are there to achieve compliance.

The mistake is achieving compliance to compliance requirements alone.  There is a gap in the business’ OWN needs.  Over the past year I have spoken on this topic publicly at conferences and my book  has a huge focus on aligning and establishing business requirements cohesively.

To elaborate on the graphic … the CxO office must be aware and share their strategy – typically easy to find, as I generally begin building these programs from the 10-k reports over last two years.  These feed the information security program elements and form the decision framework against all technology, security controls, risk frameworks, sourcing considerations, recovery timelines, etc…  In addition, the compliance elements must be addressed – but with the understanding these are risk transfer activities by third parties.  Not to be the basis of the enterprise program, but a singular consideration.

The capability of the organization to address market competitive requirements is based upon the proper balance.  Here you can see the target is 85% of the program is made up by the business’ own innovative and market driving / supporting activities.  15% of the program to meeting these ‘license to operate’.

The takeaway is to challenge your organization’s singular managed compliance initiatives and a deep dive on budget alignment to business revenue generation.  There must be rationalization to the safeguards to make the business efficient and effective – that includes safeguarding and enabling the business to conduct business, everywhere.

Thoughts?  Challenges?


NSA chief endorses the cloud for classified military cyber program, considerations

Perhaps old news given the NSA chief made the below comments in 2011 presenting to Congress asking for support of the projects (basically a budget justification meeting).  What is interesting is how he frames the current state weaknesses versus the benefits of the future state of leveraging Cloud architectures.  He is also referring to several key programs that are deployed and seeing active participation.

As this relates to information security professionals, control safeguards, and ultimately PCI DSS is for the eye of the beholder.  A striking point is to fundamentally challenge your risk assumptions and the benefits of moving to the cloud.  A key consideration here is the concept of redeploying, rearchitecting, and I would say restart managing access and security anew.  Cloud provides an inflection point to businesses, and governments to start fresh to meet the current threats.

As I have often have CxO discussions, the framing of these technology changes provides a mechanism to reach a stability and integrity of technology supported operations (hard to find one that is not).  Consider the NSA Chief points below and perhaps consider that he is speaking of highly sensitive data that has human life risks directly associated.  That type of data is highest sensitivity, and if such can be secured in a collaborative, cloud, integrated, and mobile enabled environment – why not other data elements and industries.

This is in line with the OCR NIST HIPAA guidance and recent clarification (June 2012) regarding how Cloud environments are subject to the BA agreement and security elements.  Clouds are permitted, but the expected controls must exist along with the proper risk management factors.

NSA Chief: “The idea is to reduce vulnerabilities inherent in the current architecture and to exploit the advantages of cloud computing and thin-client networks, moving the programs and the data that users need away from the thousands of desktops we now use — each of which has to be individually secured for just one of our three major architectures — up to a centralized configuration that will give us wider availability of applications and data combined with tighter control over accesses and vulnerabilities and more timely mitigation of the latter,” he testified before a House subcommittee in March 2011.

via NSA chief endorses the cloud for classified military cyber program – Cybersecurity – Nextgov.com.

Kind regards,

James DeLuccia IV