PCI DSS Compliance

Compliance obligations need not stand in the way of better information security and risk management

I couldn’t help write this post when I noticed this press release based on an IDC Insights Survey of Oil & Gas Companies. I don’t have access to the full report so I am basing my comments solely on the contents of the press release.

I found the following two findings (copied from the press release) to be of interest :

• Security investments are not compliance driven. Only 10% of the respondents indicated that they are using regulatory compliance as a requirement to justify budgets.

• Tough regulatory compliance and threat sophistication are the biggest barriers. Almost 25% of respondents indicated regulatory environment as a barrier to ensuring security. In addition, 20% of respondents acknowledged the increasing threat landscape.

The good news here is that only 10% of the respondents used Regulatory Compliance needs to justify budgets. What that tells me (I hope it is the case) is that the remaining 90% make budgetary decisions based solely on the information security risks that their  businesses face and not on the risks of not complying with regulations or audits. I would commend them for it… and I don’t think any good auditor (regulatory or internal/external) would have a problem with it either if the organization was able to “demonstrate” that the risk of not complying with a particular regulatory requirement was very low. Agreed.. you still need to be able to “demonstrate” which isn’t easy if one hasn’t been diligent with risk assessments.

The not-so-good news to me is the 25% number (I realize it might be low enough for some people)..  that of folks indicating that regulatory compliance is a barrier to ensuring security. For those folks, I say “It really doesn’t need to be a barrier”, not if you have good   information risk management governance and processes. I don’t know a single regulation that would force you to implement specific controls no matter what. Even if you are faced with an all-or-nothing regulation like PCI DSS, you can resort to using compensating controls (see here and here for some coverage of PCI DSS Compensating controls) to comply with a specific mandatory requirement.  To repeat my argument in the previous paragraph, an auditor would be hard-pressed to fault you if you were able to clearly articulate that you went about the compliance program  methodically by performing a risk assessment and prioritizing (by risk level) the need for specific controls required by the regulation. If you did that, you would focus on ”ensuring security” and not ignoring it for the sake of compliance.

May we suggest some priority adjustments to your PCI DSS Compliance program?

It isn’t any news that achieving PCI DSS Compliance continues to be onerous for many merchants out there. PCI DSS is after all an all-or-nothing regulation meaning that not passing even one of over 200 requirements could prevent you from getting there. And then, if you do become compliant, there is really no assurance that you will have 100% security. This is something we have known all along to be true for any regulation and now we have one more statistic from the 2010 Verizon Data Breach Investigation Report to prove it …  21% of organizations facing payment card data breaches were compliant with PCI DSS at the time of the breach.

So, may be it is time to rethink our approach to PCI DSS compliance, in terms of how do we get there by way of addressing controls that carry higher breach risks before the others. That will at least help improve your  organization’s security posture against potential breaches even if you are nowhere close to meeting all PCI DSS requirements.   I think recent breach surveys or reports are a great source to identify such controls  with an objective of prioritizing the remediation initiatives in the right order. Such prioritization should help in achieving a better security posture sooner, as we’ll see below.

I am not the first one to suggest a prioritized approach to achieving PCI DSS compliance. In fact, PCI SSC already has guidance on this, though the guidance itself is somewhat dated having been issued back in February 2009. Since then,  the threat environment has probably evolved somewhat and exploitation of certain  vulnerabilities isn’t quite of the same order relative to others. Therefore, I suggest leveraging the data breach findings to make necessary prioritization adjustments.

Here are some findings from three recent reports on which I am basing my recommendations:

Here then is a summary of the key controls in the above table, relevant PCI DSS requirements and priorities from the PCI SSC Guidance.

Note: Numbers in brackets are the priority numbers from the PCI SSC guidance. Numbers in the guidance range from 1 through 6. A lower number indicates a higher priority.

As we can see from the table, there are several requirements which if addressed sooner, will actually improve an organization’s security posture against potential breaches, based on what we know from the recent breach studies.  I would recommend increasing the priority of the requirements in red to at least 3 if not 2. I do realize that organizations may not be able to afford to address too many requirements at a higher priority. If that is the case, you may want to review the current priority 2 and 3 requirements against the key controls in the table above and then decide to push some of them lower down the priority order as applicable.

Hope this is useful! As always, we welcome your thoughts and comments.

RisknCompliance Services Note

We at RisknCompliance track about a dozen of such reports every year and maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in  providing our clients with  a much-wanted third-party assessment of their risk management or audit methodologies and  programs. After all, security risk assessments and audits form the very foundation of risk management or audit programs, so we believe it is critical that every organization fine-tunes its methodologies and  knowledgebase.

Please contact us here if you would like to discuss your needs. We will be glad to talk to you with the details and how we could be of assistance to you.

Verizon 2010 Data Breach Investigations Report – Key takeaways for Security Assessors and Auditors

The Verizon 2010 Data Breach Investigations Report (DBIR) released last week has some interesting findings, just as it did last year. What makes it special this year is that Verizon partnered with the United States Secret Service in developing this report. I don’t intend to discuss all the statistics in this blog (will do so in another upcoming blog) but as you will see explained in the report, the Secret Service’s involvement has thrown new light into some of the findings.

My intention here is to highlight the significance of such a report to security and audit practitioners with the objective of improving the quality of their risk assessments or audits and more importantly, help make the right recommendations to management.  From my experience as a security practitioner and an occasional auditor, I can tell that we may not always be using all the available information to help improve the quality of our risk assessments or audits. And, I think reports such as the Verizon DBIR can provide some valuable help from that standpoint.

Let me explain what I mean… Deliverables for any risk assessment or audit typically include a list of findings and for each finding, we provide an explanation of the risk, the risk severity  (High, Medium, Low) and suitable recommendations for risk mitigation or remediation.  The management would then proceed to remediate various gaps in priority based on our risk rankings. Considering that risk is a product of likelihood and impact (I like the OWASP risk rating methodology, so will use it here), it is important that we get the impact and likelihood right.  Impact is largely a function of the organization’s characteristics including various technical and business factors seen in the methodology. On the other hand, likelihood is a function of threats and vulnerabilities.  I think the DBIR can be a useful reference in estimating the likelihood.

For example, the DBIR says that external agents were responsible for about 78% of the breaches whereas about 48% were caused by insiders. These numbers can be used to arrive at a better objective estimate  of the likelihood that these threat agents may cause any harm. Similarly, the DBIR also says that  48% of the breaches involved privilege misuse, 40% resulted from hacking  and 38% utilized malware. These numbers can be used for objective estimation of the likelihood that associated vulnerabilities could be exploited. The OWASP methodology has an illustration for such objective risk estimation.

These are but a couple of examples. The DBIR has a wealth of information that can be useful to auditors and security practitioners alike, both in improving the quality of their work as well as in being able to defend their risk rankings. We all realize that risk rankings almost always have a level of subjectivity in them but I think reports like the DBIR can be leveraged to make them as objective as possible. A very good example is the risk level one might normally assign to a case of unpatched vulnerability versus a configuration issue.  It may not be readily obvious that one might need to be assigned a higher risk level over another until you read the DBIR. The DBIR tells us that the likelihood of exploitation of an unpatched  vulnerability is far less as compared to a vulnerability caused by a configuration issue. If we didn’t leverage the DBIR (and assuming both issues had equal impacts), we might assign equal risk levels to both the findings or worse, we might assign the unpatched vulnerability a higher risk level.

Over the next couple of weeks, I plan to be blogging with a detailed commentary on some of the findings in the report including a special post on how the report can be leveraged to enhance the effectiveness of PCI DSS programs.

Hope this is useful! As always, we welcome your thoughts and comments.

RisknCompliance Services Note

We at RisknCompliance track about a dozen of such reports every year and maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in  providing our clients with  a much-wanted third-party assessment of their risk management or audit methodologies and  programs. After all, security risk assessments and audits form the very foundation of risk management or audit programs, so we believe it is critical that every organization fine-tunes its methodologies and  knowledgebase.

Please contact us here if you would like to discuss your needs. We will be glad to talk to you with the details and how we might be of assistance to you.

Logging for Effective SIEM and PCI DSS Compliance …. UNIX, Network Devices and Databases

In one of my previous blogs, I covered the importance of logging the “right” events for an effective Log Management or Security Information and Event Management (SIEM) deployment … see here or here for a discussion on the two technologies. The blog also provided a suggested listing of the Windows or Active Directory events that you might want to log from a PCI DSS Compliance standpoint.

Clearly, no amount of investment in your Log Management or SIEM solution is going to do much good, unless you have been able to generate all the right logs to begin with … see a related discussion with the recognized PCI Expert and Author, Dr. Anton Chuvakin here.

I would like to extend my suggested list in the previous post to cover a few other systems here,  specifically UNIX/LINUX, Network Devices and Databases. Note that this list is only a starting point so you can work with the respective System Specialists or Administrators in your organization to generate these events.

UNIX/LINUX Logging for Effective SIEM and PCI DSS Compliance

Logging of Network Devices for Effective SIEM and PCI DSS Compliance

-

Database Logging for Effective SIEM and PCI DSS 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.

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.”