Author Archive for PCI Guru

29
Apr
22

The SAQs Have Been Published

Just a quick post to let everyone know that the PCI SSC has published the version 4 Self-Assessment Questionnaires (SAQs). You can get them under the Documents Library and select SAQS.

20
Apr
22

The Gag Is Coming Off!

Coming Thursday, April 28, to an internet connection near you!

The PCI Dream Team of Ben Rothke, Art “Coop” Cooper, David Mundhenk and the PCI Guru himself will finally be able to openly discuss PCI DSS v4 – warts and all!

So, bring your questions and concerns to this open discussion of v4. As always, if you cannot attend the live session, you can submit your questions to pcidreamteam AT gmail DOT com.

Register here for this session.

We look forward to “seeing” everyone there.

03
Apr
22

PCI DSS v4 First Blush Comments

All I can say is Wow!  WOW! 

There is a LOT of “busy work” in this version. 

For any QSA that does not have access to some form of tool for filling this bad boy out, heaven help you.  It seems that the Council has declared war on the QSACs and QSAs.  I would venture a guess that the number of hours required to fill out and ticking and tying things will be twice the amount of time a QSA spends on actually doing the assessment. 

Sadly, it is painfully obvious as to why this has happened. 

I am sure it is to get back at all of the “ROC Mills” out there (you know who you are) that conduct PCI assessments by essentially licking a finger, putting it in the air and sensing which way the wind is blowing, i.e., “you are compliant!” 

But sadder still are the poor merchants and service providers that are now collateral damage in this “war”.  I would not be surprised that, if after reviewing this Albatross of a standard, those merchants and service providers revolt.  That constituency is not going to pay for the overhead in this new version.  Even those that have done the correct thing and minimized their scope are going to get screwed over because of all of the “busy work” required to even complete their assessments. 

If the Council wanted to find a way to put themselves out of business, I think they have found that in v4. 

I thought I was only joking in my April Fool’s Day post about “Miserable Edition”.  But I was apparently spot on.  I cannot wait to attend training on this abomination to understand their justification for making a PCI assessment even more miserable than it already was. 

31
Mar
22

The PCI Council’s Bold Move

The long wait is over and PCI DSS v4 has finally been released!

In a very bold move, the Council has taken a page out of the Microsoft playbook.  Instead of being called “PCI DSS v4” the Council has chosen the name “PCI DSS Miserable Edition” or PCI DSS ME.

Council Communications Director, April Fool, said that, “Everyone was getting tired of the numeric increase, so with the consent of the card brands we decided to change things up a bit with this release.  Based on the feedback we have gotten from the Participating Organizations, QSAs and other stakeholders, this new designation seemed to be appropriate.”

I am sure we all remember how well Windows ME worked out and that set the bar pretty low.  PCI DSS ME can only be a step up.

Have a great day and do not get taken in by any calls from Mr. Bear or Mrs. Cougar.

23
Jan
22

See The PCI Dream Team LIVE!

I just wanted to give everyone a heads up on the latest speaking engagement for the PCI Dream Team.

I recently got word that the PCI Dream Team will be back speaking at Secure360 in Minnesota. We do not have our time yet nor the location of the event (I would assume it will be held at Mystic Lake Casino) but we do know that the conference occurs on Tuesday, May 10, through Wednesday, May 11, and is currently expected to be a LIVE event. I am not sure if the event will also be live streamed for those of you unable to travel.

As usual, we always accept questions at our email address of pcidreamteam AT gmail DOT com.

Stay tuned to the blog and as we get more information I will share it here.

21
Jan
22

The Final Draft Of PCI DSS v4 Is Available

The wait is over for participating organizations, QSACs and ASVs. The PCI SSC announced this morning that the final draft of PCI DSS v4 is available to the primary contacts of those organization via the PCI Portal. The Council reiterated that the public release of PCI DSS v4 will be by the end of March 2022.

I guess I know where my weekend will be spent provided my primary contact downloads it today for me.

UPDATE: We really need to see the Report On Compliance (ROC) Reporting Template. There is some interesting stuff in the draft, but without the Reporting Template it is very hard to judge the impact the new version will have on assessments.

11
Jan
22

A Half Day Of Dream Team!

Apparently, a successful talk I gave more than a year ago on PCI compliance for the Toronto Chapter of ISACA’s Lunch and Learn program has led to an opportunity of a half day of the PCI Dream Team on Thursday, February 3, from 1PM – 430PM ET/1800 – 2130 UTC.  Because of the scale of this event, there is a fee involved to attend.  Attendance by ISACA members will cost $50 CAD (approx. $40 USD or €35) and non-member attendance will cost $60 CAD (approx. $48 USD or €42).  You can register here for the event.

The format of this session is like a TED Talk only with a Q&A session afterwards.  One of the Dream Team will make a 20 to 30 minute presentation on a PCI topic near and dear to their heart and then open the floor to questions on the presentation or any other PCI or information security topic for another 40 to 30 minutes.  Rinse and repeat.

As with all our sessions, we will be accepting questions via our Gmail account at pcidreamteam AT gmail DOT com so that you can ask them ahead of time and allow us to prepare.

We look forward to seeing you at this event.

UPDATE: Thank you to all who joined us at this great event. The Dream Team had a great time and enjoyed all of the excellent questions that got asked. We look forward to future meetings like this.

09
Jan
22

Penetration Testing – Yes, It Is Still Misunderstood

Remind me again how far down the road we are with the current practices of information security? Has it really been almost three decades?

Yes, it really has been about that long.  Yet, it continues to fascinate me how those practices are so misunderstood in the information security community.  Particularly when a significant portion of that community holds one or more certifications in the topic.  In my very humble opinion, we should not be having such basic understanding conversations and yet these topics keep constantly coming back up.

One of those practices that is heavily misunderstood is penetration testing.  I have written numerous posts on the subject and yet the understanding of penetration testing continues to be a challenge.  This is particularly true when it comes to PCI compliance.  As a result, I decided I would share some important points about PCI compliance and penetration testing as is required in requirements under 11.3.

A lot of these misunderstandings are clarified in the PCI SSC’s Information Supplement on Penetration Testing.  If you have not read this document, I highly recommend it as it explains a lot about the process and why it is important.

Yet, sadly, it too has some flaws in it that have created more problems than the document solved.  The biggest of which is on page 7 where it discusses the scope of a penetration test.  The only thing those of us can figure is that the group that developed the information supplement assumed that the cardholder data environment (CDE) is implicitly secured by the security measures taken because of the PCI DSS requirements.  Therefore, the actual CDE is not required to be tested.  How any information security professional could think this is a good practice is beyond a lot of us in the profession, but the information supplement only says that the CDE MAY BE tested. 

But then on page 8, comes this quote.

“When access to the CDE is obtained as a result of the testing, the scope of the penetration test may allow the tester to continue exploring inside the network and further the attack against other systems within the CDE, and may also include testing any data-exfiltration prevention (data-loss prevention) controls that are in place.”

“May allow” further exploration?  Wait!  What?  Since when does an attacker stop looking around?  Are you kidding us?

In my very humble opinion (and the opinion of those of a LOT of others in the profession), everything that is in scope for PCI compliance needs to be penetration tested.  No exceptions!  But all QSAs and penetration testers that take this approach have received push back (sometimes significant) from clients and then we usually back off and do exactly as the information supplement states.  I would like to tell you that it ends well, but I have had numerous clients come back later (sometimes years later) and complain (some very loudly) to me that I should have stuck to my guns and tested everything as they hold me responsible for why they got hacked.

The next big misunderstanding is what is considered a “passing” or “clean” penetration test?  Section 4.1.6 on page 16 of the Penetration Testing information supplement discusses what constitutes a successful penetration test.

“Defining the success criteria for the penetration test allows the entity to set limits on the depth of the penetration test. Without agreeing upon the point at which the penetration test is complete, there is a possibility of the tester exceeding the boundaries and expectations of the target entity. This should be documented in the rules of engagement.”

Sorry, but this is not an excuse for the assessed entity to avoid penetration testing by setting the scope of the test too small.  It is up to the client and the penetration tester to agree on the scope based on network and dataflow diagrams.  Going back to my earlier statement, a penetration test should test every device/system that is in scope for PCI compliance.  When I say everything, that does not mean that every “Connected To” system needs to be penetration tested such as with Domain Controllers or other devices where the penetration tester can confirm that standardized configuration practices are in place and can be proven to be standard.  It also does not mean that containers or servers that are spawned to increase capacity in a virtual or cloud environment need to be individually tested as long as the penetration tester can document that all instances are the same.

Another misunderstanding is when exploitable issues are found is that only critical, high or severe exploits need to be addressed in order to get a “passing” test.  Sorry to rain on your parade, but penetration testing is not like vulnerability testing where critical, high or severe vulnerabilities need to be fixed within 30 days and the others can be addressed within 90 days.  An exploit found by a penetration test MUST BE remediated or mitigated and then retested to get a “passing” test.  All someone needs to do is to read the PCI DSS requirements under 11.3 and see that nowhere in those requirements is there ever a reference to critical, high or severe exploits, nor any other remediation criteria.  ALL exploits documented must be addressed, regardless of any documented criticality, and either be remediated or mitigated and then retested to get a “passing” test.

A key point about retesting is that the penetration tester does not have to conduct a complete penetration test as a retest.  The penetration tester only needs to retest those exploits that were found in the original testing exercise.

Another critical point is when an exploit is mitigated and not remediated.  When mitigated, that means that the organization is relying on a variety of controls to detect and alert on the exploit being used.  When testing an exploit that is being mitigated, the penetration tester needs to have a clear understanding of those mitigating controls so that when they review their testing results they can attest to the fact that all of the mitigating controls functioned to identify, alert and then allow personnel to stop an attack.  If those mitigating controls cannot be confirmed then the mitigation is not considered successful.

Another point of confusion regarding penetration testing is network segmentation testing.  Why segmentation testing is bundled with penetration testing is unknown, but it has always been that way.  A lot of us would prefer it was a separate requirement in section 11, since it does not require a penetration tester to conduct this testing which is a surprise to most.  The person conducting the segmentation testing only needs to be deemed as “qualified” to conduct the testing.

People are also typically surprised that segmentation testing does not require anything more than Nmap installed on a laptop.  The key though to a successful segmentation test is that every segment deemed “out of scope” must be tested to ensure that they have no direct communication capability with systems contained in the CDE – inbound to the CDE OR outbound from the CDE.  This testing requires having Nmap test all 65,535 TCP and UDP ports to/from every network segment which takes time – a lot of time depending on the number of active IP addresses in the network segment.

For large organizations with tens of thousands of network segments, the idea of testing EVERY segment that is out of scope against the CDE is not realistic.  There are two options to address this situation.  The first option is to use a tool such as AlgoSec, FireMon, Tufin or the like.  Most large organizations have such a tool installed.  Using the tool’s database, queries can be run against the CDE and all segments to find any “holes” in those rules.  To use this approach though the entire network needs to be in the tool’s database because you are going to test ALL segments and you need to test all the segments.  Sadly, most large organization do NOT have all their network segments in the tool, so it is not usable for segmentation testing.

The second option requires an analysis of the firewall and routing rules to determine if there are ways to “sample” network segments that are covered under the same rules in the firewalls and routers.  If the segmentation tester can document that say one thousand network segments are all governed by the same set of firewall/router rules, then testing of five randomly selected segments of those thousand segments and getting the same results, those results can be extended to the remaining 995 segments.  But the key to this second option is making sure that the rules are exactly the same for all one thousand segments which is sometimes not as easy as it sounds.

Hopefully these clarifications will assist you in conducting and evaluating penetration testing.

02
Jan
22

PCI DSS v4

I wrote this for my new employer’s, Truvantis, blog so I figured why not point you to it here. Just my thoughts on the subject and all of you are concerned about: what is in the new coming release of the PCI DSS?

https://www.truvantis.com/blog/pci-dss-v4-2022-how-to-be-prepared

Enjoy!

19
Dec
21

Updated PAN Truncation FAQ

As part of the holiday giving tradition, the PCI SSC has given us an updated FAQ (#1091) on the subject of PAN truncation and it will likely go down as the most confusing FAQ ever.

The FAQ starts out simple enough with the statement:

“A maximum of the first 6 and last 4 digits of the PAN is the starting baseline for entities to retain after truncation, considering the business needs and purposes for which the PAN is used.”

But it is the table that follows that gets messy.

It seems that each of the card brands has their own take on PAN truncation based on PAN length and other factors. Only American Express has stayed the course.

Based on the guidance for UnionPay, Visa, Mastercard, JCB and Discover, the idea of first six/eight and ANY OTHER four is a bit bizarre not to mention risky.

Never mind the obvious warning note at the end of the FAQ that states:

“Access to different truncation formats of the same PAN greatly increases the ability to reconstruct full PAN, and the security value provided by an individual truncated PAN is significantly reduced. If the same PAN is truncated using more than one truncation format (for example, different truncation formats are used on different systems), additional controls should be in place to ensure that the truncated versions cannot be correlated to reconstruct additional digits of the original PAN.”

Personally, I would stick with the good old first six, last four and avoid any of these other formats as you are likely setting yourself up for problems and PCI non-compliance.

Happy holidays to all!




Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

May 2022
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031