Category: Regulatory Compliance

One of the goals of this blog, as well as the ultimate goal of my career, is to simplify all aspects of cybersecurity. Well, maybe not all. I have no idea how to simplify a penetration test (or even perform one), or encryption mechanisms, but I’ve got the high-level stuff covered! 🙂

From my perspective, cybersecurity is already simple. You would hope so, it’s what I do, but that’s not actually what I meant. Which is that every aspect of cybersecurity must be simple for it to even be effective security in the first place. There is no room for complicated. It must also be accessible to everyone who needs it, regardless of their current role or previous experience.

It is therefore the job of every cybersecurity professional to make this stuff easy, but clearly we are not doing a very good job. In fact, I would go as far as to say that there are certain elements that seem to go out of their way to make things difficult!

What / who are these elements, and why are they doing it?

o

  1. No offence, but Element 1 is You; While you may not be a security expert, you are every bit as responsible for security as those who are the experts. Ignorance of your responsibilities is no excuse, and if your organisation does not provide you the necessary training, demand that they do so. Unless you’ve lived in a hole for the last 10 years, you have seen the headlines related to data breaches. You really don’t want to be the cause of one.
    o
  2. Which is the ideal segue into the Element 2, which is; Senior Management. If they don’t care about security, there’s a very chance you don’t care (see element 1.). If cybersecurity is not in the Top 5 priorities of your BoD / CEO, then you likely have an entirely ineffectual security program. If you even have one at all. There is nothing more difficult and seemingly complicated than starting something from the very beginning, but start you must.
    o
  3. Element 3 is of course, Lawyers / Regulators. Not that they do this on purpose, it’s that they just can’t help themselves. The language of the law is practically incomprehensible to the rest of us, yet it has to be lawyers that write every contract, regulation, and [of course] law out there. Combine their legal-ese with something you already don’t understand [cybersecurity], and you’re left scratching your head in frustration. Or worse, avoiding it altogether.
    o
  4.  And the worst of the bunch, Element 4; Security Vendors. This is the one that is truly reprehensible. How many of you, for example, know what Cloud Access Security Brokers (CASBs) are? Or User and Entity Behavioral Analytics (UEBA)? What about Intelligence-Driven Security Operations Center Orchestration Solutions? No, me either. What I DO know is that you don’t need ANY of these things until such times as your risk assessment TELLS you need them! You have that process well oiled, right?

Of all the horrendous clichés out there, my favourite is ‘Back to Basics’. Cybersecurity is simple, bloody difficult, but simple. Anything that complicates it can be effectively ignored until such times as you’re ready for it. You will never get there by buying technology, and you will never get there until you get the basics right.

Luckily the basics are the cheapest things to fix. All you have to do is get your CEO to care, formalise your Governance, and get all of your policies and procedures in place.

Simple, right?

OK, that was facetious, but if you think any of these things is complicated you’re just not asking the right people the right questions.

[If you liked this article, please share! Want more like it, subscribe!]

In honour of the SSC’s 10th year in power [oops!] business, I thought it would be interesting to run a little retrospective.

On December 15th, 2004, a day that will live in infamy, Visa released the Payment Card Industry Data Security Standard (PCI DSS) v1.0.

~2 years later, the PCI Security Standards Council (SSC) was formed, closely followed by the release of DSS v1.1.

Six iterations later, here we are at v3.2.

To emphasise yet again just how sad I am, I chose to map v1.1 against not just the v3.2 standard itself, but its corresponding Report on Compliance (RoC) Reporting Template . While this seems like an extreme comparison (download it here), I wanted to get the full flavour of just how PCI compliance assessments have evolved in the 10 years since v1.1’s debut.

At first blush, they would appear to be radically different. For a start, v1.1 was just 17 pages long, v3.2 is 139 pages, and the RoC Reporting Template is a whopping 198 pages! But what becomes clear very quickly is that most of the changes are related to assessment guidance, validation guidance, and wave after wave of clarifications.

I mean, seriously, excluding the Bill of Rights the US Constitution has only been amended 17 times in 227 years!

Take Requirement 1.1.1 for example, this is what v3.2 looks like in the v3.2 RoC Reporting Template:

Screen Shot 2016-08-10 at 10.46.04

This is from v1.1:

Screen Shot 2016-08-10 at 10.39.46

Radically different, right?

Not really, everything in 1.1.1.a – 1.1.1.c is validation guidance, nothing more. In other words, if the original v1.1 assessors were doing a good job, this is how they would have assessed their clients back in 2006.

But they weren’t doing a good job. Not even close. Even into v1.2 QSAs were still filling out ‘Yes’ for in-place and ‘No’ for not-in place.

What we have seen from v1.2 onwards is the gradual increase in detail related to the validation that has to be performed. From v2.0, a separate document was provided to QSAs, the ‘ROC Reporting Instructions for PCI DSS v2.0‘ that broke down what was expected during compliance validation.

This was also implemented poorly by a lot of QSA companies, while others were clearly unaware of its very existence.

Roll on DSS v3.0, the version that caused by far the biggest stir in the PCI community since the DSS’s initial release. There were shouts from the merchants that the SSC had just raised the bar to unacceptable heights. There were even complaints from QSAs that the ‘new’ instructions would increase the workload to the point assessments would be unprofitable. And worst of all, the more unscrupulous QSA companies actually raised their prices! Here are my thoughts on those companies; PCI DSS v3.0 – Do NOT Pay More For Your QSA Services!

The fact is that v3.0 was a consolidation of the DSS Requirements and the Reporting Instructions, and little more (detailed mapping here). If the QSAs and the organisations they were assessing had been performing assessments properly, the effects would have been minimal.

How Similar is v1.1 to v3.2?

About 82% according to my calculation. Obviously this is at the overarching control level, not the validation detail. v1.1 had exactly zero guidance in that regard.

Other than some wording and requirement numbering changes the controls have remained remarkably consistent.

…and the ‘major’ changes aren’t really that major. Certainly nothing outside of basic common sense:

  1. Req. 1.1.3 – Cardholder Data Flow Diagrams – [How would you determine scope in the first place?]
  2. Req. 2.4 – Asset Inventory – [Seriously, how could you possibly achieve PCI compliance without one?]
  3. Req. 5.x – Make sure anti-virus are actively running etc. – [Really!?]
  4. Req. 7.x – Additional requirements around job classification etc. – [RBAC is RBAC, this should never have needed changing.]
  5. Req. 8.6 – ‘Other’ Authentication Mechanisms – [About time non-password stuff was introduced.]
  6. Req. 9.3 – Physical access based on job function – [As opposed to?]
  7. Req. 9.9 – Protection of Terminals (only affects retail) – [Sigh…]
  8. …etc…

So What Are You Saying?

There are two ways to look at these results:

  1. The main controls of the DSS were correct from the very beginning and there has been no change in either the threat landscape, or security technology; and
    o
  2.  The card schemes do not WANT to make significant changes, because they already consider the controls to be risk reduction enough. Not to mention the poo-storm that would descend on them if they did.

I think we all know that the first option isn’t true, so that leaves the second. And can you really blame them? Besides, what does it really matter, the DSS will never have the opportunity to improve much beyond minor clarifications. Payment cards just don’t have enough life-span to warrant anything else.

Nothing more to add really, now I need to go get a life.

[If you liked this article, please share! Want more like it, subscribe!]

The SSC released their Information Supplement ‘Effective Daily Log Monitoring‘ in MAY, and I’m only just hearing about it now! Either I’m completely out of the loop (not being a QSA) or the SSC did a very poor job PR-ing it.

I think I understand which it is now that I’ve read it.

Anyway, despite the blatant oxymoron in the document’s title, and my own predisposition toward negative bias where the SSC is concerned, I was still hoping to be pleasantly surprised.

I wasn’t, but nor was I as horrified as I have been while reading output from other SIGs.

It’s actually a really good beginner’s guide to logging, but it’s completely unsupported by the DSS in its current form. And it’s not just me looking for faults, they have not put logging into a proper, or even accurate, context to the DSS requirements as written. With their knowledge of best practice, they basically made the rookie mistake of assuming requirements mean more than they do.

To be clear; If it’s not specifically spelled out in the standard, it is not mandatory. Period / full stop. Even if it’s the right thing to do.

For example: There is no requirement for any automated alerting. Not from firewalls, not from A/V, not from IDS, not from FIM, and not from ‘system components’ like servers and applications. So the statement; “The PCI DSS recognizes the importance of proactive monitoring of security logs in the detection of attacks on information assets and the protection of those assets from compromise.” is inaccurate. The SSC might recognise the importance of pro-active monitoring, the SIG’s participants clearly do, but the DSS only recognises the need for what amounts to forensic evidence. Nothing more.

The DSS uses the word ‘alert’ in only 6 relevant Requirements:

  • “6.6  For public-facing web applications, ensure that either one of the following methods is in place as follows:

• Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:

– Is configured to either block web-based attacks, or generate an alert that is immediately investigated.” – [Alerts are non-mandatory, and can be manually generated.]

  • “10.5.5  Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).” – [No time-period defined, so you have to assume weekly like 11.5, or at most daily like 10.6. Alerts can be manualy generated.]
    o
  • “10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.

Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.” – [Non-mandatory]

  • “11.1.d  If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to notify personnel.” – [Non-mandatory, and/or no time-period defined.]
    o
  • “11.4  Use intrusion-detection systems and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.” – [Alert how? Automatically or during a daily review?]
    o
  • “11.5  Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.” – [Weekly notification, so clearly does not require automation.]

So if there’s no requirement for automatically generated alerts, and daily is the maximum defined review timeframe, how can they possibly insist on 24/7 availability related to Incident Response (DSS Req. 12.10.3)? Who is going to choose 2AM for their daily review?

Even the SIG makes the statement; “Without automated alerting mechanisms, it is almost impossible to identify and alert about such events in near real-time.“. In other words, in time to actually do something about it before it gets out of hand.

But I thought this was about effective DAILY log monitoring?

So All In All…

The thing that still confuses me most, is that the DSS is full of mandatory technologies, but a manual and daily review of logs is still OK?! Not one technology in the DSS is required to be utilised properly, and some have significantly less benefit than a Security Incident & Event Management (SIEM) or an equivalent managed service:

  • why require firewalls and routers then don’t mandate review of the traffic logs?
  • why require an asset database, but not an asset management system on which every other security processes can rely?
  • anti-malware is based on signatures so is all but useless
  • intrusion detection is pointless unless the entire infrastructure is baselined to a known-good
  • …and so on.

So of ALL requirements, how can centralised logging and automated alerts not be mandatory?

This post in already too long, and I’ve barely begun to scratch to surface of why logging and monitoring is so important.

There’s no escaping that the document name; ‘Effective Daily Log Monitoring‘ is misleading, it should be called the ‘We Cannot Tell You to Buy a SIEM, But Good Luck Getting Compliant Without One‘. Basically the SSC has all but admitted that the logging and monitoring requirements are completely inadequate, but can think of no way to change them in the DSS. Not without pissing off a lot of people anyway.

Finally, it IS  a good document, worth a read, and kudos to the authors. Unfortunately it’s guidance is meaningless to those without the means to perform anything other than manual daily reviews.

Bonus Material

If you’re interested, I have provided some additional thoughts in my own Logging Supplement document. There are 3 sections:

  1. Breakdown of Existing DSS Logging & Alerting (Non-Server) – There are 5 DSS requirements outside of the established logging and alerting requirements, and are ambiguous at best. They are also not covered appropriately in the SSC’s Supplement.
    o
  2. Missing from the DSS – The SSC’s Supplement did not cover daily review appropriately, nor did then then go far enough to cover appropriate automation. This section covers a few of the major benefits of logging and monitoring properly.
    o
  3. Automating the Daily Review – There are only three processes required to automate the daily review, but it cannot be done without centralised logging and scripting skills, a managed service, or a SIEM.

[If you liked this article, please share! Want more like it, subscribe!]

[Disclaimer: The following is based on information received from a single acquirer, and I have been unable to corroborate any of this from other sources.]

Have you seen Visa Europe’s new fine structure for cardholder data breaches? Can you afford THAT kind of loss? More importantly; Are you really PCI compliant, or did you just fake your way through a Self Assessment Questionnaire (SAQ)?

In case you weren’t aware, the fines for a breach are levied against the results of the mandatory forensics investigation, not just your self-assessment status. Anyone caught lying on a self-assessment attracts the maximum fines, and rightfully so.

OK, full disclosure on the title, I did go straight into a worst case scenario, but would you read about PCI otherwise? If you’re like 99% of the people I’ve ever had as PCI clients, you care nothing about PCI compliance per se.  Other than wanting it to just go away of course. Historically, even threats of fines have done little to motivate organisation to take PCI seriously.

Until now perhaps.

But first, believe it or not,  some good news!; “Assessments levied for non-progressions and portfolio targets have been withdrawn.” – in other words, there will no longer be Visa Europe-defined fines for non-compliance. This is not to say your ACQUIRER can’t fine you, but Visa has only ramped-up the fines in the back-end.

In this case, the ‘back-end’ means you’ve been breached, and there is now a whole host of things you have have to take into account to work out your potential losses:

  1. The loss of 1 PAN & CVV attracts a fine of €18.
  2. There is a €3,000 ‘Account Data Compromise (ADC) Management Fee’ imposed on all breaches.
  3. For penalties over €100,000, the fines can be capped at “5% of the merchant’s Visa gross annual purchase volume in 12 months prior to the initial notification.” I assume this is entirely discretionary and weighed against the egregiousness of the non-compliance.
  4. Did the acquirer correctly report the merchant’s compliance status? – Even is the status is non-compliant, there is a 25% reduction in fines for correct reporting.
  5. Are the ‘majority’ of the merchant’s transactions authentication with Verified-by-Visa (VbV) – 50% reduction in fines if yes.

ADC Scenarios:

  1.  Non-compliant Level 4 Merchant puts 1,000 PAN and CVV2 numbers at risk – Acquirer correctly reported compliance status, and VbV is in place;
    o

    PAN & CVV 1000 x €18: € 18,000.00
    Compliance Reductions @ 25%: -€ 4,500.00
    Sub Total:  € 13,500.00 
    VbV Reduction: -€ 6,750.00
    Sub Total:  € 6,750.00 
    ADC Management: € 3,000.00
    Cap Applied: N/A
    Grand Total:  € 9,750.00 

    o

  2. ‘Compliant’ Level 3 Merchant puts 5,000 PAN and CVV2 numbers at risk – Acquirer incorrectly reported compliance status, and VbV is not in place;
    o

    PAN & CVV 5,000 x €18: € 90,000.00
    Compliance Reductions @ 25%: € 0.00
    Sub Total:  € 90,000.00 
    VbV Reduction: € 0.00
    Sub Total:  € 90,000.00 
    ADC Management: € 3,000.00
    Cap Applied: € 25,000.00
    Grand Total:  € 28,000.00 

    o

  3. Non-compliant Level 2 Merchant puts 75,000 PAN and CVV2 numbers at risk – Acquirer correctly reported compliance status, and VbV is in place. No penalty cap applied;
    o

    PAN & CVV 75,000 x €18: € 1,350,000.00
    Compliance Reductions @ 25%: -€ 337,500.00
    Sub Total:  € 1,012,500.00 
    VbV Reduction: -€ 506,250.00
    Sub Total:  € 506,250.00
    ADC Management: € 3,000.00
    Cap Applied: N/A
    Grand Total:  € 509,250.00

Conclusion:

Will Visa Europe’s new fine structure get merchants moving towards compliance? I seriously doubt it. Frankly nothing will get them moving unless the CEO / BoD see these fines as a legitimate business risk instead of a worst case scenario. And what are the chances of that when the cost of properly securing cardholder negatively impacts the quarterly numbers?

Fining for non-compliance was stupid anyway. It basically forced merchants to just lie on their SAQs and do nothing to actually reduce the risk. Huge fines for a breach is arguably a more appropriate way of punishing those who egregiously ignored the standard. But it’s still after the fact.

But what if the card schemes actually provided INCENTIVE for achieving [and appropriately demonstrating] compliance? Reduced interchange rates perhaps? Financial incentive to adopt their increasingly desperate ‘innovations’ maybe? Wouldn’t THAT be something.

[If you liked this article, please share! Want more like it, subscribe!]

In a recent CSO Online article; “The National Retail Federation is dead wrong about PCI“, the author made, in my opinion, one the most reprehensible defences of PCI I’ve ever seen. Even the SSC have not been so bold as to make these kinds of off-the-mark and clearly self-serving assertions.

After an innocuous 2 paragraph preamble, the author(s) state;

“Despite NRF assertions to the contrary, the payment card industry has asserted that their card security standards are voluntary. Merchants have a definite choice if they want to accept credit and debit cards or not. It’s quite safe to say if retail establishments couldn’t accept payment cards; most would see massive sales reductions, and a large number would simply go out of business.“

How can he possibly say that merchants have a choice, when he says it himself that most would see “massive sales reductions”!? Call that a choice!? That’s right up there with ‘face or gut?’!

The fact remains that the card brands STILL have merchants by the short-and-curlies when it comes to non-cash payments. You only have to look at the anti-competition or unfair business practice suits that card brands have had to fight over the years to see how distastefully are their business practices perceived.

And quite frankly, this all shows a complete lack of understanding of the NRF’s main issue; They don’t CARE how they receive payment, payments are NOT core to their business. Being paid for their product / services is.

The author goes on to say;

“Given the significance of payment cards, we would have expected the NRF to be at the forefront of PCI advocacy and compliance. Yet the reality is that they have an extremely disdainful view towards PCI.“

Seriously? Ask me to pick up the cost of fixing your crappy service and I’ll be equally ‘disdainful’. Sod that, I’d be thoroughly pissed-off, but I still wouldn’t have a choice, not if I wanted to stay in business.

The NRF have every right to expect the card brands to do something more appropriate, THEY are the ones providing the service and THEY (and their associated middle-men) are the ones who’ve made billions through merchant transactions over the course of 50+ years.

But it’s the merchants who are the ones who are paying the interchange rates. And it’s the merchants who have to spend billions on infrastructures that do absolutely NOTHING to help them improve their customer’s shopping experience.

Guess who pays for this in the end? Yep, us, the consumers.

As I have written (or at least allude to) many times in the past, the very technology behind payment cards is past its usefulness. Anyone trying to prolong this ancient, inherently insecure, and zero-value-add technology clearly has a vested interest in doing so. Card Brands, Issuers, Acquirers, Payment Service Providers (PSPs), and Terminal Manufacturers are obvious stakeholders. However, QSA companies exist to a large degree on the budgets that PCI compliance extorts. Call them PCI War Profiteers if you wish, I’ve heard worse, and I have also benefited.

In the card brand’s defence, they have done a truly astonishing job over the course of 5 decades in bringing trust into non-cash payments. That’s what their logos are; a symbol of trust. The next generation of payment providers owe them an enormous debt of gratitude. That said, we didn’t keep horses around because we felt sorry for the ferriers, we jumped head first into the automobile.

Mobile phones are now more ubiquitous, and can be infinitely more secure and ‘value-add’ than branded plastic (even while tokenised in ‘[X] Pay’ services). All we need now are the banks to get their acts together and provide the trust and there will be little need for the innumerable middle-men.

Which brings me to my final point on the article; yes the NRF and all other retail associations have the right to be angry, but they have done next to nothing to help themselves. They played a game whose rules were set by the card brands and used none of their extraordinary power and influence to tip the balance in their favour.

For example, I have estimated that the Top 10 retailers in the US alone account for almost 1 TRILLION USD in branded transactions. If we assume an average of 1.75% interchange, that’s 1.75 BILLION in fees the retailers have paid to ‘middle-men’. How much influence would you exert over those middle-men if it was your business?

So in summary;

QSA Companies: Keep your opinions of retail to yourselves, your self-serving diatribes are inappropriate. Serve your clients, don’t brown-nose the brands.

Card Schemes/Issuers/Acquirers: Use your incredible knowledge and combined talent-pool to lead the way in the removal of plastic, and therefore the need for PCI. It’s time to move on.

Retailers: Put aside your differences, stop bitching to the wrong people in the wrong way, and do something useful with your power. Focus on what you WANT, not want you DON’T want.

All of this boils down to one thing; what do consumers want? Most have no idea, but I do, as do thousands of others like me. Ask us.

…and it had better not involve yet another piece of plastic.