Archive Page 2

06
Oct
14

PCI Compliance Certificates Rear Their Ugly Head Again

Apparently, a bad practice started a number of years ago is appearing in other parts of the world.  That practice is PCI Compliance Certificates.

I wrote a post a number of years ago about this practice and provided the direct quote from the PCI SSC’s FAQ on the subject.  If you need more proof, go to the PCI SSC Web site and click on FAQ and search for ‘PCI DSS Compliance Certificate’.

This is a marketing ploy and it needs to stop.

These certificates are not worth the paper they are printed on and anyone purporting them to have meaning is uninformed, or worse, lying.

I would highly recommend that if you encounter anyone that tells you such nonsense, they should be immediately reported to the PCI SSC –  qsa AT pcisecuritystandards DOT org. Include their name and the name of their organization in your message.

UPDATE: Only a few minutes after I put up this post I received just such a certificate from a major bank as proof that their business partner was PCI compliant. Unbelievable.

27
Sep
14

Interested In Business As Usual?

I am encountering more and more organizations that are interested in business as usual or BAU.  Organizations are finally realizing that the only way they are ever going to feel secure is to embed security controls in their everyday business processes and make sure that they periodically assess that those controls are working.  The PCI SSC used a page and a half in the PCI DSS v3 to discuss the concept of BAU.  This leads some of us to believe that BAU will become part of the requirements at some point in the future.

However, what is involved and what will it take to implement BAU?  This post will give you an idea of what you will be up against.

Going through the PCI DSS v3, I did an analysis of the requirements and testing and came up with some interesting statistics regarding BAU.

  • There are 14 requirements/tests that are required to occur at least daily.
  • There are 18 requirements/tests that are required to occur whenever changes occur.
  • There are five requirements/tests that are required to occur whenever significant changes occur.
  • There is only one requirement/test that is required to occur at least weekly.
  • There are three requirements/tests that are required to occur at least monthly.
  • There are 11 requirements/tests that are required to occur at least quarterly.
  • There are four requirements/tests that are required to occur at least semi-annually.
  • There are 118 requirements/tests that are required to occur at least annually.

For my analysis, I assigned actual values to those requirements/tests that use the words “periodic” or “periodically” in their definitions.  The values I assigned were based on other standards or security “best practices”.  That is why my analysis does not include those references.

In total, there are 227 requirements/tests that need to be done at some frequency.  There are some requirements/tests that are duplicated in this count because they are not only required to be performed for example at least quarterly or annually, but they may also be required to be performed whenever changes occur.  The best example of this is vulnerability scanning which is required to be performed at least quarterly but also whenever a significant change occurs.

The biggest problem organizations will have with BAU is getting all of this integrated into their operational.  To address that, I tied the requirements to their priorities from the Council’s Prioritized Approach spreadsheet.  This allowed me to determine which BAU to implement first, second and so on.  What I found was:

  • There are 16 requirements/tests in BAU that have a ranking of ‘1’ (highest priority).
  • There are 75 requirements/tests in BAU that have a ranking of ‘2’.
  • There are 37 requirements/tests in BAU that have a ranking of ‘3’.
  • There are 58 requirements/tests in BAU that have a ranking of ‘4’.
  • There are 30 requirements/tests in BAU that have a ranking of ‘5’.
  • There are 11 requirements/tests in BAU that have a ranking of ‘6’ (lowest priority).

Once BAU is integrated into operations, organizations will want to ensure that it continues to operate effectively.  That will likely mean including the assessment of BAU as part of their internal audit activities.  This will further mean that departments will have to maintain evidence of their BAU activities to prove that BAU is being followed.  Some of that evidence will already be maintained in centralized logging and change control solutions.  However, other evidence such as with new user setup or user termination may have to be retained in a folder in the email system or exported as a readable file and stored on a file server.  The bottom line is that evidence of some form needs to be maintained to provide proof that BAU activities are performed and performed consistently throughout the year.

But that is the ultimate point about BAU.  It is all about engraining the security concepts in the PCI DSS to better ensure security is being maintained throughout the year, not just at assessment time.  And that is where most organizations fail with PCI is keeping the controls functioning throughout the year.

I have yet to encounter any organization that can prove to me that all of the PCI requirements are functioning at 100%, 24x7x365.  All organizations have issues with controls, but with BAU, the idea is to have a mechanism that identifies those issues before they become damaging and correct them before too many controls fail and result in a breach.  If you read any of the breach analysis reports, that is why the breach occurred because the controls were not functioning and no one addressed the failure.

17
Sep
14

How Many Auditors Does It Take …

The title of this post sounds like the start of one of those bad jokes involving the changing of light bulbs.  But this is a serious issue for all organizations because, in today’s regulatory environment, it can be a free for all of audit after audit after assessment after assessment.  A never ending cascade of interruptions to their business operations as they go through audits and assessments, all in the name of ensuring controls are designed and functioning properly.

But another reason I have written this post is because of all of the comments that I have received that seem to paint my position as a reason why QSAs are not needed to conduct PCI DSS assessments.  I wanted to clarify for everyone my rationale for my position.

Besides those reasons, the larger reason this issue needs to be brought up and discussed is that the PCI SSC is pushing for organizations to adopt business as usual (BAU).  For those of you that did not read the preamble of the PCI DSS v3, BAU is the integration of relevant portions of the PCI DSS into an organization’s everyday activities.  A rather noble goal and only a recommendation at this time, one has to believe that BAU will at some point become part of the PCI DSS in a future version.

Any organization that takes the time to implement BAU is going to want to assess their implementation of BAU.  They will do this through internal/external audit activities, automated real-time monitoring via dashboards and other internal assessment processes.  Why bother with BAU if you are not going to use it to spot control issues before they become major problems?  That is, after all, the whole point of BAU.

Which brings me back to this year’s Community Meeting and the question I asked about reliance on other auditor’s/assessor’s work.  The reason for the question is to minimize, as best we can, the disruptive effects of the myriad of audits/assessments that some organizations are required to submit.  The answer provided by the Council was an emphatic “NO!” followed by some backtracking after the audience apparently showed its displeasure to the Council members on stage to their take it or leave it answer.

The reason for the audiences’ displeasure though is genuine.  A lot of organizations question the number of times user management controls such as identification of generic UIDs, last password change date, last logon date and the like need to be performed before such activities are deemed adequate?  How many times do facilities people need to be interrupted to prove that video monitoring is performed and the video is retained?  How many times do facilities have to be visited and reviewed for physical access controls?  There are numerous areas in all control assessment programs where those programs cover the same ground in varying levels of detail and focus.  It is these areas of commonality where the most pain is felt and we hear the lament, “Why do I have to keep covering this ground over and over with every new auditor that comes through?”

It is not like the PCI DSS cornered the market on control assessments.  Organizations have to comply with ISO, HIPAA, GLBA, FISMA, NIST and a whole host of other security and privacy control audits or assessments.  All of these audits/assessments share certain common controls for user management, physical security, facilities management, etc.  What differentiates the programs is the focus of what they are trying to protect.

One easy approach to address this situation is to combine audit/assessment meetings with personnel in physical security, facilities management, user management and the like.  Each auditor/assessor can ask their specific questions and gather evidence and conduct testing as they need.  Unfortunately, due to timing of reporting requirements, having common meetings might not always be possible.

But another approach would be to use internal auditors performing testing monthly, quarterly, etc. and then the QSA reviewing those results during their annual PCI assessment process.  There might be some independent testing required by the QSA for areas such as device configurations, change control and application development changes, but the sample sizes of any testing could be greatly reduced because of the testing done throughout the year due to the implementation of BAU.

If we as QSAs work with other auditors/assessors and agree to common criteria in our respective work programs that satisfy our common controls then we will not have to interrupt an organization to ask the same questions and alienate people as we do today.

Success of compliance programs is the result of making them as unintrusive and automatic as possible.  BAU is a great idea, but it will only succeed if the Council understands how BAU will be implemented in the real world and then adjusts their compliance programs and assessment approach to take BAU into account.  The quickest way to kill BAU is to make it painful and cumbersome which the Council is doing very effectively at the moment.

11
Sep
14

2014 North American PCI Community Meeting

Another year has come and gone and so has another PCI Community Meeting.  There were a number of interesting events at this year’s meeting.  Some I will cover here and some I still have to digest and determine what they really mean.

Good Bye Bob

This year’s meeting is the last one for the PCI SSC’s current General Manager, Bob Russo.  Over the years, Bob has been a good sport and has been a cowboy and other characters.  This year’s community meeting was no exception.  At Wednesday night’s networking event, Bob showed up as Gene Simmons’ brother decked out in silver colored platform boots, black tights, leopard spotted top, long black hair and doing his best to show off his tongue.

A lot of us over the years have pilloried Bob for various edicts and clarifications as he was the leader of the Council.  However, if we step back, Bob got the PCI SSC off the ground and took on the thankless task of combining the disparate security standards of the five card brands and giving us the common set of standards we have today.  As well as then asking us to do our best to ensure that those standards were followed.

Even though I have been critical at times of Bob, he has always been pleasant and cheerful to me and others at the community meetings and other events where he was present.  Bob recognized that there are always some of us in the crowd that are very passionate about security and tried to assist us in channeling that passion.

Bob stated that he will be doing a “Goodbye Tour” to the other community meetings this year, so make sure to thank him for his efforts, shake his hand and say your goodbyes at whatever meeting you are able to attend.

P2PE v2

The first versions of P2PE were lambasted for being pointless and the number of solutions certified, now at six, has somewhat proven that the newest of the PCI standards needed some work.  As a result, in November 2014 we will receive version 2 of the P2PE standard.  According to people I spoke with at the meeting that have seen the new version, the new standard should be much better. Is it perfect, no. But it supposedly is a better version than the originals.

The most notable change to the standard is the approach the Council has taken.  Based on the presentation made, they seem to abandoning the complete end to end model and are moving to a component approach based on how the solution will be implemented.

But the huge change to the standard is that a certified P2PE solution can be managed by a merchant without a third party.  That is, merchants can manage the encryption keys.

It will be interesting to see just how much the standard has changed since its last iteration only a year ago.  But most of all, it will be interesting to see how the new implementation approaches will work.

SAQs

The biggest clarification to come out of the community meeting on SAQs is the Council’s and card brands’ endorsement of using multiple SAQs for documenting compliance with the PCI standard versus doing an SAQ D.

This situation occurs when a merchant has multiple payment channels such as with merchants that have retail stores using traditional card terminals (SAQ B or B-IP) and an eCommerce presence that is outsourced (SAQ A or A-EP).

The other area of discussion that seemed to cause a bit of a stir was related to Web sites that use redirects or iFrames for payment processing.  The reason for this contention is the result of claims from vendors of these sorts of payment solutions in the past that claimed that their solutions placed merchants out of scope for PCI as it related to their eCommerce operation.

Ever since the issuance of the eCommerce information supplement in January 2013 and with the recent issuance by Visa of their eCommerce guidance, the outsourcing world has been buzzing about the implications.  Merchants of course have been going back to their eCommerce outsourcers and complaining about the fact that their eCommerce is no longer out of scope.

Reliance On Other’s Work

My final comment will be related to a question I asked at the Open Forum session on Wednesday.  We have been getting push back from our larger clients on our limited use of their internal audit work, SSAE 16 reports, ISO 27K audits and similar work, if we used it at all.  The driver is that clients want to minimize the amount of disruption to their personnel by all of the audits and assessments that are occurring these days.  This prompted me to ask the question at the Open Forum as to the Council’s advice on reliance on other auditor’s work to reduce sampling.

The answer I received was, “No, absolutely not.”  Quickly followed by, “Of course, I mean other auditors, not other QSAs and PA-QSAs.”

This blunt answer apparently shocked the audience as the people on stage reacted to that shock as well.  The people onstage then backed off saying that the Council would have to take the issue back and discuss it.

After asking this question I was approached by a number of people thanking me for bringing up the topic.  The bottom line is that organizations are audited and assessed out.  Most feel like one audit/assessment ends and another one begins.  But the truly annoying thing is that there are certain portions of all of these audits/assessment that cover the same ground over and over and over again such as with physical security, access controls and end user management.  Handled properly, it would not eliminate all testing, but it would definitely reduce the amount of testing and also reduce sample sizes.

But a very telling comment came from a member of the American Institute of Certified Public Accountants (AICPA) who told me that the AICPA has repeatedly tried to meet with members of the PCI SSC to discuss the SSAE 16 standard and how it could be used to reduce a QSA’s work only to be rebuffed by the Council.

Organizations would be more willing to go through PCI assessments if work done by their internal auditors as well as outside auditors could be leveraged to simplify their lives, not complicate them.  This will only become more important as the Council pushes organizations to adopt business as usual (BAU).

If I had one important take away for the Council to work on, it would be to work with other standards bodies such as the AICPA, ISO, FFIEC and the like and work toward providing guidance to organizations on how to use internal and external audit reports.

29
Aug
14

Is The PCI DSS Effective?

Brandon Williams has a great blog post on his site that answers this question.

The bottom line is that there is no organization that is going to execute the PCI DSS, or any security framework for that matter, 100% of the time, all day, every day.

Why? 

Security is NOT perfect. 

Why? 

Because it involves human beings and we are flawed.

However, that does not mean that you should not try and be as close to 100% flawless as possible.  Because the difference between an organization that is breached and one that is not breached, can be only a percentage point.

For all of you in the United States, have a safe holiday weekend.

24
Aug
14

P2PE Versus E2EE

I have been encountering a lot of organizations that are confused about the difference between the PCI SSC’s point-to-point encryption (P2PE) certified solutions and end-to-end encryption (E2EE).  This is understandable as even those in the PCI community are confused as well.

E2EE is the generic terminology used by the IT industry to describe any solution that encrypts communications from one endpoint to another endpoint.  Key management of the encryption can be done by any party that has an endpoint such as a merchant or a service provider.  Examples of E2EE include IPSec, SSL and TLS.

One of the most common E2EE solutions used by merchants is derived unique key per transaction (DUKPT) also known as “duck putt”.  DUKPT is commonly used in the convenience store and gas station industries to encrypt sensitive authentication data (SAD) from the gas pump to the merchant or processor.  DUKPT uses the 56-bit data encryption standard (DES) encryption or triple DES (3DES) algorithms.  While DES and 3DES 56-bit and 112-bit are no longer considered secure, because DUKPT uses a unique key for every transaction, it means that every transaction has to be individually broken to gain access to the data.  While using the cloud could be leveraged to perform this rapidly, it would be too costly an effort for the data retrieved.  As a result, DUKPT is still considered a secure method of encryption.

P2PE is a subset of E2EE.  This is because the major difference between P2PE and E2EE is that P2PE does not allow the merchant to be a manager of the encryption keys.  Under the P2PE standard, only the transaction processor or other third party is allowed to perform key management.  The merchant is never allowed to perform encryption key management under the P2PE standard.  As a result, DUKPT can be used by both P2PE and E2EE solutions.  However, under P2PE, the key management must be done by a third party, not the merchant.

While third party key management is typically acceptable for small merchants, this does not work for merchants that switch their own transactions to various processors as do mid-sized and large merchants.  That does not mean that E2EE solutions are not acceptable for reducing PCI scope.  As with PA-DSS certified applications, P2PE certified solutions can be accepted by a QSA as long as they are implemented according to the P2PE implementation guide which can reduce the amount of testing a QSA is required to perform.  In my experience, P2PE versus E2EE testing efforts are typically negligible, so any so-called savings are limited at best.

The huge downside to P2PE for merchants is that once you decide on a given P2PE solution, you are pretty much stuck with it and the processor providing it.  That is because most processors offering P2PE are only offering one P2PE solution.  As a result, if a better deal comes along for processing your transactions, you will likely have to replace your terminals and possibly other equipment to switch to the new processor.  For some merchants, that could be a costly proposition and make any switch not worth the effort.

So if your organization is looking at P2PE versus E2EE, I would not necessarily give an advantage to P2PE over E2EE.  Just because an E2EE solution is not P2PE certified does not mean it is not secure.  It only means that the vendor did not believe that the P2PE certification was worth the effort.

08
Aug
14

Requirement 10.6.2 Clarification

As a refresher, requirement 10.6.2 states:

“Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment.”

The argument in PCI circles is the definition of “all other systems”.  Some of us believed that it meant systems other than those in-scope.  Other people believed that it had to refer to only in-scope systems such as a user workstation.  As a result, I asked the PCI SSC to clarify this requirement and this is the response I got back.

“In PCI DSS v2.0, logs for all in-scope systems were required to be reviewed daily. However it was recognized that for larger or more complex environments, there could be lower risk systems that were in scope for PCI DSS that could warrant less frequent log reviews. As such, PCI DSS v3.0 defines a number of events and system types that require daily log reviews, and allows the organization to determine the log review frequency for all other in-scope events and systems that do not fall into those categories.

For some environments, such as those designed specifically for the purposes of PCI DSS, then it is possible that all in-scope systems fall under the system categories defined in Requirement 10.6.1, meaning that daily log reviews are required for all in-scope systems. In other environments, there may be many different types of system that are considered in-scope, but which are not critical systems and neither store, process or transmit CHD nor provide security services to the CDE. Some possible examples could be stock- control or inventory-control systems, print servers (assuming there is no printing of CHD) or certain types of workstations. For these events or systems, the entity, as part of its annual risk assessment process, is expected to define the frequency for reviews based on the risk to its specific environment.

The intent of this update is not to apply PCI DSS Requirements to out-of-scope systems. We realize that the current wording is causing confusion and will address this in the next revision.”

So there we have it.  Not the first time my interpretation was wrong.  The requirement means in-scope systems that, from an assessment of risk, are at less of a risk of compromise can reduce the frequency of log reviews.

But that means you need to have an accurate risk assessment to support your argument.  So those of you that have not explicitly assessed the risk of your category 2 systems will have to break them out to support a reduced log review frequency.




Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

November 2014
M T W T F S S
« Oct    
 12
3456789
10111213141516
17181920212223
24252627282930

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,018 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,018 other followers