Regulatory Compliance

PCI DSS – Quick and Dirty?

I recently received a tweet titled “PCI DSS Compliance – Quick and Dirty”. I think it is safe to say that such a title is bound to grab immediate attention of anyone that has been associated with PCI DSS in one form or another. I immediately clicked the link on the tweet which took me to this page.

Not sure what the tweet’s originator meant to convey…  Neither am I  sure there is anyone that knows or has a quick and dirty approach to PCI DSS Compliance. Not unless perhaps, yours is a highly mature Security and Data Protection program…. I mean really high, perhaps the 90th percentile or higher.   PCI DSS being perhaps the most prescriptive security standard out there, the reality is that most organizations will have a fair bit of work to do before they can claim compliance.

The link on the tweet points to the “Prioritized Approach for PCI DSS”. The document was put out by PCI SSC to assist merchants and Service Providers in undertaking a prioritized remediation effort when they may have gaps in a large number of control requirements.  As the document says, the prioritized approach was developed based on extensive feedback from assessments, breaches and investigations, among other things.

Quoting from the document itself… “It is not intended as a substitute, short cut or stop-gap approach to PCI DSS compliance”.

And then, there is this quote … “To achieve PCI DSS compliance, an organization must meet all PCI DSS requirements, regardless of the order in which they are satisfied or whether the organization seeking compliance follows the PCI DSS Prioritized Approach”.

That said, as a security practitioner, I really wish there will come a day when compliance with a standard like PCI DSS can be quick and dirty for most organizations.

Identity Theft Red Flags Rule – Is the 06/01/10 deadline looking good?

Frankly, I have lost count of how many times FTC has moved the deadline already (see my related post from 2009).  This time, however, I think the deadline is too close (about a week out at the the time of this blog post) that I think the rule is finally going to take effect.  Again, I may be proved wrong… let us wait and see!

Aside from the rule taking effect, enforcement of the rule is going to be interesting to watch! Just this past Thursday,  AMA and two other physician groups filed a suit contending that the rule shouldn’t apply to physicians.  The rule had already been contested by Lawyers and Accountants.

AMA’s suit comes after several back-and-forth discussions with FTC over the last year or so. It looks like AMA wasn’t obviously convinced that the rule should apply to physicians despite what I thought was this compelling argument by FTC.

AMA’s main contention has been that hospitals and physicians are already subject to HIPAA Security and Privacy Rules and therefore the Red Flags Rule shouldn’t apply to them. From my experience, however, I believe that most HIPAA Security/Privacy Programs may not be effective against Identity Theft tricksters of today. I would recommend that health care providers implement a risk-based, written Identity Theft Prevention Program to supplement the Administrative Requirements (§ 164.530) of the HIPAA Privacy Rule and Administrative Safeguards (§ 164.308) of the HIPAA Security Rule.

I think the below quote from FTC’s letter sums it up well:

“The Rule is designed to prevent identity theft primarily by ensuring that organizations are alert to signs that an identity thief is using someone else’s identifying information fraudulently to obtain products or services, including services such as medical care. Thus, the Red Flags Rule generally complements rather than duplicates the HIPAA data security requirements.”

New details released regarding Internal Security Assessor (ISA) program for PCI DSS

PCI SSC has just released new details regarding the training schedule for the ISA program. The program is obviously PCI SSC’s response to the often heard complaints from merchants and service providers about high costs involved with maintaining PCI DSS compliance.  Be sure to read the program validation requirements as well as the FAQs.

Key requirements to note are:

1. ISAs have to be on full –time employment with the sponsor companies. Specifically , ISAs will not retain the certification upon termination of employment and so can’t carry the certification to a new employer.
2. ISAs need to be recertified annually. The recertification process includes ISA Program training and passing the examination every year.
3. ISAs have to be part of a dedicated Internal Audit department.

Important to note is the scope/objective of the ISA program which reads as “to improve the organization’s understanding of the PCI DSS, facilitate the organization’s interactions with QSAs, enhance the quality, reliability, and consistency of the organization’s internal PCI DSS self-assessments, and support the consistent and proper application of PCI DSS measures and controls”.  It also says that the “ISA qualification does not entitle an ISA to perform special functions or conduct QSA Assessments".

Here is another interesting blog post on this topic.

Logging for PCI DSS Compliance

PCI DSS has had specific requirements for logging and review of those logs for sometime now. The logging requirements (under Requirement 10 ) have a primary objective of supporting forensics in the event of a breach of cardholder data. I believe it is fair to say that PCI DSS has played a large role in bringing into limelight the topic of Log Management, in effect creating an assured market for several vendors who are vying for a piece of the PCI business out there.

While most Log Management vendor solutions are featured enough and support quick deployments (normally a selling point one hears from most vendors), I believe it is important for PCI merchants and service providers to take that with a grain of salt. Granted that most vendor solutions have features for effective log parsing, normalization, reporting, alerting etc… As I am sure anyone that has worked on PCI DSS (or for that matter any Log Management or SIEM deployments) would attest, an effective deployment requires deliberate planning and ground work. And in my view, the most critical step for an effective Log Management solution (and most certainly those focused on PCI DSS Compliance) is the very first step, which is Log Generation (see NIST 800-92 Guide to Computer Security Log Management to learn more about Log Management processes). After all, you can get to managing and analyzing logs only if you generate them and more importantly from a PCI DSS standpoint, generate all the right logs!

To illustrate the point, below is a partial suggested list of events you might want to log on Windows and Active Directory. One really can’t overemphasize the need for various system administrators to work closely with the PCI readiness teams to make this happen. I have also included sample mappings to PCI DSS requirements, the likes of which you can use to demonstrate due diligence to your QSA.

Hope you find this information useful and I welcome your comments!

PCI DSS update related to digital audio recordings containing cardholder data

PCI SSC released another update yesterday related to digital audio recordings. The update provides further clarification (to the update on January 22) on the storage of sensitive data in digital audio recordings after authorizing transactions.

As always, RisknCompliance recommends that  organizations look at options to avoid storing CVV or like codes in their call center recordings after authorizing transactions. If the data is stored, they would be faced with the extra burden associated with compensatory controls (documentation, demonstrating effectiveness etc.)

(PCI SSC FAQ updates reproduced below)

————————————————————————————————————

PCI SSC FAQ – 5362 dated February 18, 2010

Question: Are audio/voice recordings containing cardholder data and/or sensitive authentication data included in the scope of PCI DSS?

This response is intended to provide clarification for call centers that record cardholder data in audio recordings, and applies only to the storage of card validation codes and values (referred to as CAV2, CVC2, CVV2 or CID codes by the payment brands).

It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.

Where technology exists to prevent recording of these data elements, such technology should be enabled.

If these recordings cannot be data mined, storage of CAV2, CVC2, CVV2 or CID codes after authorization may be permissible as long as appropriate validation has been performed. This includes the physical and logical protections defined in PCI DSS that must still be applied to these call recording formats.

This requirement does not supersede local or regional laws that may govern the retention of audio recordings.

————————————————————————————————————

PCI SSC FAQ – 5362 dated January 22, 2010

“It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization; as card data can easily be extracted using freely available software.

On an exception basis, storage of CAV2, CVC2, CVV2 or CID codes in an analog format after authorization is allowed; as these recordings cannot be data mined easily. However the physical and logical protections defined in PCI DSS must still be applied to these analog call recording formats.

Audio recording solutions that prevent the storage or facilitate the deletion of CAV2, CVC2, CVV2 or CID codes and other card data are commercially available from a number of vendors. All other recordings containing cardholder data captured by call centers must be protected in accordance with the PCI DSS, including PCI DSS requirement 3.4.”