PCI DSS
Never Rest on Your Laurels

Published On: June 25th, 2020Categories: PCI DSS

Almost four years ago the Payment Card Industry Data Security Standard (PCI DSS) version 3.2 was introduced and has only received a minor revision to version 3.2.1 since. Add to that, some companies have been assessed by the same assessors for years on end and both the assessed and assessors could become complacent feeling they know what to expect year over year from their compliance assessment. Hackers never rest on their laurels though, and neither should the assessed or the assessors.

To “rest on one’s laurels” comes from ancient times but today it means to be satisfied with one’s past success and to consider any further effort unnecessary. But in cyber security that means allowing gaps to develop over time. Imagine never patching a server because at one time it was secure, and you felt that was enough. As we all know, vulnerabilities can be found and exploited, and at times require patching. If you don’t patch you may as well leave the gate down across the moat and open. Hence complacency isn’t an option.

So how do I ensure my team, as assessors, never rest on their “laurels”.

Well as one of them put it, I “keep them on their toes”. Each Report on Compliance (RoC) my team writes goes through a rigorous quality assurance process. The RoC is first reviewed by a Managing Consultant before it reaches me, the Regional Director, and eventually makes its way to the Quality Assurance (QA) team. Before it reaches QA though I challenge the team and their findings. I may harp on a specific phrase or control in the PCI DSS standard and ask the team why they believe that may or may not apply.

I throw multiple curve balls at them in the way of further queries:

  1. To see if they have a solid understanding of the environment they assessed, and
  2. To ensure that they are 100% certain of the solutions that they assessed and compliance to the standard.

I don’t wear my team out with that approach, but at times it has led to some out of the box thinking and reassured viewpoints in others. It has also helped make the clients environment stronger as we discuss approaches from multiple angles and not just the approaches we frequently see. We don’t consider further effort unnecessary to ensuring compliance, quite the opposite in fact. If an assessment has made it past me it still has a QA process to navigate before reaching the client.

What about those being assessed?

A common thing we see is a “compliance curve” where a project to achieve compliance is started just prior to the required compliance date and there is often a mad rush to achieve all that is required in a very short time for compliance. Then if they manage to achieve compliance there is this downward slide on the curve to complacency, where the goal to remain compliant drops as they recover from the mad rush of meeting their last compliance date. They rest on their laurels. The problem is there are several tasks required throughout the year to maintain PCI DSS compliance, so complacency may see you fail your next compliance date very quickly. For example, quarterly clean vulnerability scans are required – missing one is not something that may be recovered from without impacting your next compliance date. There needs to be a constant effort in maintaining compliance and not a “curved” approach. In no way should a company rest on their laurels after achieving compliance.

Taking our ancient analogy further, the ancient Roman soldier’s success as an effective fighting force depended somewhat on their armour, which included a large shield. If any one part of that armour was missing, damaged or misaligned it would open up a gap that could allow missiles or a strike to wound the soldier. Do you think a Roman soldier was ever complacent about maintaining his armour, and do you think if an upgrade to his armour was available he would dismiss it? In the cyber security world of today, complacency leads to gaps and gaps lead to breaches.

It’s not only incumbent upon us to keep on our toes during assessments, no matter how many times we may assess the same company, it’s also the duty of each company to not only keep on the front foot but to stay that way throughout the year to ensure that compliance is maintained and gaps don’t develop to allow for a breach. Like I said in the beginning, hackers never rest on their laurels so neither should we.

_________________

SecureTrust, a Sysnet company, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.

CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.

_________________

Brian Odian is the Director of Asia Pacific Global Compliance & Risk Services Consulting at SecureTrust, based in Sydney.

Written by Brian Odian

Brian Odian is the Director of Asia Pacific Global Compliance & Risk Services Consulting at SecureTrust, based in Sydney. He has over 32 years IT industry experience including roles as a Security Delivery Manager and Global Security and Transformation Lead for large worldwide information technology corporations. During his career he has been across a wide range of industries and roles, including global management experience across multiple cultures and business environments.

Experienced in running global security programs, and some of the largest regional projects in Asia Pacific, Brian brings a mix of project management, security and compliance credentials together (CISM, CRISC, PMP, QSA, ISO27001 IA, CDPSE) to achieve the best results in delivering security solutions and compliance programs. He has been published by the Project Management Institute (PMI) and MSSP Alert along with conducting webinars on the General Data Protection Regulation (GDPR) and Compliance Intelligence. He has also presented on PCI Compliance for some of the “big four” banks and the Customer Owned Banking Association (COBA).