I
don’t want to dump on the vendors, after all NCI is a vendor of a lot of gear
as well as a QSA, but I’ve bumped into some vendors lately that are making some
pretty sloppy claims about PCI compliance. And let’s not even talk about some
of the claims from service providers, at least not yet, maybe we can talk about
them in a later post (PCI & Cloud anyone?).
What’s
that you say? “Vendors making outrageous claims? I’m shocked! The room is
spinning, I have to sit down to clear my head.” Let’s try not to be
flippant, this is rather serious, and here is why.
Your
QSA comes in, whether for a scope assessment, gap analysis, your annual onsite
assessment, or even to review your SAQ, and they find a problem (We won’t be
specific about what the problem is because it’s not really relevant to the
discussion).
The
vendor said that their product would make you PCI compliant, or at the very
least help you meet some of the requirements, how could there be a problem?
Let’s take a look at two broad ways that we see vendors making promises that
they really shouldn’t’.
- A vendor of awesome security gear (i.e. they sold you a box that you put in a
rack in your computer room) tells you that all you have to do is use their
stuff and your PCI compliance woe’s (or is it whoa’s) will be all gone. - A vendor of your “important” software (could be a payment
application, or your ERP perhaps) tells you that if you install it in
such-and-such a way then, presto, PCI compliance is yours.
Not
so fast…
Are
these QSAs? Are they even a QIR (Qualified Integrator and Resellers)? In my
experience this is often not the case. So why are they offering authoritative
opinions on PCI DSS compliance matters? That last question was rhetorical. They
are doing it because that is what vendors do; they try to help their customers.
Sometimes they don’t end up helping though. They may even be making it worse.
Simply put they can’t offer a reasoned and considered opinion on PCI matters.
That’s for your QSA to do.
Let’s
give two examples:
- A vendor of log aggregation and analysis gear will put a box on your
network that will collect all the logs (that you send it), grind them up and
produce a canned report. But… Are you logging the right events as per 10.2?
Are you sending the right details as per 10.3? Are you restricting access to
logs as per 10.5? Are you reviewing the right things as per 10.6? Are you
keeping enough logging on hand as per 10.7? Selecting the “PCI
Report” is not a guarantee that you are, not even close. - The vendor of your payment application is performing an upgrade and as part of
that upgrade they’ve made changes to the underlying application architecture.
They now claim it is now possible to remove your workstations from your PCI
scope. Wow! That would be nice. But they don’t tell you that you also have to
change your business process so that you can’t take credit card details over the
phone. Oops!
How
could your QSA have helped?
- Your QSA is aware not just of what the PCI DSS has to say in requirement 10,
but also what the intent of that requirement is, what evidence must be produced
to validate this requirement, and the opinions of other QSAs in the industry
about this requirement. If the way you or your vendor have configured the
logging gear doesn’t pass muster with the QSA then you will have gaps in your
environment and may not pass your assessment. If you had involved your QSA,
either when selecting your vendor/product, or afterwards when specifying how it
was to be deployed and configured, a lot of headaches could have been
avoid. - Your QSA understands the ins-and-outs of PCI scope determination, interaction
with other PCI standards (such as the PA-DSS), and can consult with other QSAs
about what they’ve seen in the field for frequently used software. If you had
involved your QSA earlier, they could have reviewed the modified architecture,
read the Implementation Guide (required for PA-DSS applications), and with
knowledge your credit card handling processes validated if the vendor’s claim
was accurate. If it was not they could have provided you guidance as to how to
use the new version’s architecture to achieve the scope reduction.
Achieving
and maintaining PCI compliance is tough enough without having vendors, QSAs and
your staff working at cross purposes. Everyone has a part to play and everyone
should be involved in the right capacity at the outset. Vendors should bring
their expertise of their product to bear, QSA’s their expertise in the PCI DSS,
and customers their understanding of their business and technical needs. When
we’re all playing on the same team we can get to PCI compliance much easier and
faster than when we’re at odds with one another.
At
least that’s the philosophy at NCI. Give us a call to learn more.
Jason Murray, MEng, CISSP, QSA, CCSK