Tag Archives: 2010

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.

Best,

James DeLuccia

Advertisements

A basket of interesting security articles

A few things that have crossed my desk:

Social engineering framework

An wiki site that has a host of details around social engineering.  The site is certainly a worthwhile bookmark as it has great details on each category (such as pretexting) and common vectors of attack.  This would be a useful site to leverage when considering training and communication materials within corporations.

Direct Link to the Social Engineering Framework

FireSheep

This tool is an installable Firefox plugin that allows users to ‘sniff’ an open network and capture / hijack in-secure web site connections.  The proof is demonstrated with such popular sites as Facebook and Flickr.  Certainly worthwhile checking out the author’s site, slides from ToorCon 12.  This is not a vulnerability in encryption, but one of deployment decisions.  The attack vector and ability to execute this attack has always existed, the author simply has created an elegant piece of code to show it in a simple form.

Check out the site from the author here.

Hoff’s write up on Too Much Security .. Cloud

Hoff wrote a post on October 17th that has had me thinking intently on the concept that Cloud infrastructures and ecosystems are layered with a multitude of security technologies, and this can be both good and bad.  Good as in the old onion defense, and bad in the natural result of too many buttons to hit and gears to move with few hands and eyes.  Check out his article and continue the discussion on his site – exceptional perspective and has plenty of impact to those trying to attest to an environment’s security and the operator’s ability to balance security / agility.

Link to Hoff’s article

Cheers to all, and apologies for the sabbatical.  I launched a new adventure with a new firm and the worldwide whirlwind has been all absorbing.  I have landed now, and with feet on the ground back to posting practical thoughts and useful snippets as they come across my screen.  To that point, I will still have a heavy focus on all things information technology security and controls – PCI, NERC 4.0, ISO 27002, etc…  I will also aim to publish non-technical writings.  So with that… Looking forward to hearing your opinions and continuing the dialogue,

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

Verizon Data Breach Report, 2010

The immense DBIR has been released for several weeks, and is chock full of great information.  While reading through the report highlights the very challenging environment we operate our digital assets within, it does provide a road map where professionals can focus their attention.  There is no possible way to abbreviate the report, but a few specific quotes caught my attention:

Malware gets increasingly difficult to detect and prevent (especially once the attacker owns the system) . Therefore, protect against the damage malware does after infection, much of which can be mitigated if outbound traffic is restricted.

“…a breakdown of organizational size follows a rather normal-looking distribution. It’s quite possible (and perhaps logical) that an organization’s size matters little in terms of its chances of suffering a data breach. One
might speculate that smaller budgets mean less security spending but it probably also means fewer assets to protect and a lower profile. Thieves are more likely to select targets based on the perceived value of the data and cost of attack than victim characteristics such as size.”

“The rather high percentage of “unknown” in Figure 18 is attributable to many factors. Many times there were no logs, corrupted evidence, and/or users were unavailable for interview. Occasionally, we see some of the “old school” infections vectors like e-mail and network propagation. Outside the world of data breaches, these are still alive and well but when stealth is critical and persistence is the goal, these vectors have less merit.”

When reading through the report I would suggest looking at the trends where security controls failed the most – not what worked the most.

Here is a link to the report, and their quite valuable blog.  A few good quick bits can be found here and here is an interview with Alex Hutton.

Well done gentlemen.

James DeLuccia

Enforcement of HIPAA / HITECH violations and how to improve

A great challenge with gaining massive industry adoption of a set of standards – regardless of security, privacy, or operational effectiveness measures is making it worthwhile.  Some aspects of regulation and industry led practices are obvious and clear.  Others are strikingly similar (duplication in many instances) and can be adopted simply by communication and adjustments.  Unfortunately there are specific requirements that are not sufficient alone as self-evident, and these are then made necessary through fines and punitive actions.

HIPAA / HITECH components are absolutely valuable to the consumer, the individual enterprise, and the industry as a whole.  This is true when the directives are merged into the existing culture, and the business is able to remain competitive.  There are challenges of course when a business tries to bolt-on a set of requirements, as these are seldom done efficiently, effectively, and are generally unsustainable.

The financial damage to industry is clear – the most recent studies show over the past 5 years data breaches have cost victims $139 billion (Digital Forensics Association).  In addition there is a growing trend of enforcement by state and the federal agencies, such as the California DPH actions (audio teleconference file).

When these enforcements are released though there is always valuable intelligence released highlighting what is expected – today.  This perspective reinforces that security mandates’ intent are to secure the data, and businesses must shift and respond as the attack vector shifts and evolves.  The recent Rite Aid $1,000,000 penalty enforced by the OCR and FTC provided the following direction:

  1. Implementation of complete and sufficient Policies and Procedures is critical – specifically must include safeguarding PHI during the disposal process (dumpsters, shredding, disk wipe management, third party terminations)
  2. Develop complete training related to all aspects for protection of sensitive information – job specific training
  3. Develop, implement, and maintain sanctions policies

A nice article regarding Rite Aid is available here from Information Week.

As has been consistent with prior Federal enforcement, a 20 year expectation of independent security assessments is required with sufficient monitoring and triggering.  Here is the link to the Federal press release.  Other case examples and resolutions are available here.

As the data suggests that 395,000 individuals’ data files are being stolen daily, this is not a focus on the Healthcare sector but to provide lessons learned from others.

Wireless networks are vulnerable, again (WPA2 Hack)

This week we learned that after considerable effort a vulnerability has been uncovered within the popular and previously most secure method of wireless encryption – WPA2.  In classic form, the researcher will demonstrate at Defcon 18.  You may find additional (repetitive) writings here and here.

To recap WPA2 has been the recommended standard for many public industry best practice guidances, and has been the classic default in most wireless deployments.  However, this is not a “serious problem“…

Deploying wireless has been proven to be insecure since its inception, and as such best practices consistently advise that these wireless networks be deployed “as if they they were public connection”, and therefore are secured accordingly.  Specifically wireless networks are advised to be deployed on a network connection external to your corporate data network.  In this architecture the user may gain access to the public internet (with advisable filtering and automated trigger monitoring to prevent a slew of spam generation), and simply leverages their already familiar VPN connectivity software.  This provides a secure tunnel for all data transmissions and eliminates the past, present, and upcoming wireless encryption vulnerabilities.

The PCI DSS standard in fact requires compensating controls if an organization chooses to deploy wireless to enhance the existing security state where wireless is required.
Wireless is a great business enabler, but should be architected, secured, and monitored in a manner that reflects the inherent trust aspects raised with the implementation.

A nice writeup, as always, can be found at Darknet.

Best,

James

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