This is like “Tales from the Crypt”, but much, much scarier…
Last time we talked about “Making PCI Compliance Easier” and now my subject is something that few people admit, most criticize and – that is the dirty truth! – a lot of people actually do. Namely, despite all the talk about “’compliant’ does NOT mean ‘secure’”, “Titanic WAS Compliant!” (and Part II here) , “unified compliance” (e.g. here) and “do security first!” (e.g. succinctly here and better here [PPT]) there is a sizable (multiply your wildest estimate, by, say, 10x!) population that treats, for example, PCI DSS compliance as just another IT project. A sad side project implemented in a siloed, “shoot and forget”, “plan to do as little as possible – and then cut the plan by 2” fashion.
First, imagine this hypothetical situation: a medium-size organization’s management finally “gets the PCI message” and decides that it is important to deal with PCI DSS compliance. Maybe their acquiring bank “introduces” them to PCI or maybe their service provider starts bugging them about “that PCI thing.” What happens next? In the “compliance first” mindset, the management summons an IT manager (for they are probably not big enough to have full-time security people) and hands him a copy of PCI DSS, a mandate to “do this!”, and a generous budget of $5.50, enough to procure one Venti Latte at “Starbucks.” Notice that this case does not fall under “just say ‘Yes’ on the SAQ” (like I describe here); here the organization does in fact intend to “address compliance.”
What happens next? The IT manager reviews the requirement list and notices that he already has some of the things done. For example, a network diagram (PCI Req 1.1.2) is proudly displayed on his cubicle wall. How about the rest though? Let’s look at some of the specific requirements, his responses (and some of his unspoken thoughts):
- Req 5.1 “Deploy anti-virus software on all systems commonly affected by malicious software” - “OK, we have anti-virus! Great!” (Is it on all ‘at-risk’ systems? Maybe not…)
- Req 5.2 “Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.” - “Hmmm, what do they mean here? I guess they do run, don’t they?” (Antivirus audit logs? Huh?)
- Req 6.6 “… Installing a web-application firewall in front of public-facing web applications” - “Oh, we already have a firewall in front of the website!” (Web + firewall = web firewall... I think?)
- Req 10.6 “Review logs for all system components at least daily.” -“Log management? Let’s get the syslog server up.” (Review all logs daily? Do they really say it?)
- Req 11.4 “Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises.” - “OK, let’s put snort on this box here, and start it. We will (read: might) look at the alerts later.” (I’ve heard IDS is a pain, but we can just drop it in and be compliant, right?)
Requirement by requirement he goes and figures out what is on his network vs what is in the document; sometimes he plans to make a change here and there.
Ta-dam. Done. PCI DSS is “covered.”
Is he compliant now? It depends. If they are not to be audited (and sometimes even if they are), they might well consider themselves “compliant with PCI DSS” (as long as they pass the scans – more on that below)
Is he more secure now? It depends. There is a good chance that if he were aware of the risks to his company (and few such organizations are) and have taken simple actions to deal with those particular risks (and almost no such organization does), he would have been more secure. However, there is a still some possibility that his security has improved a bit due to his PCI DSS “effort” (e.g. if he had to change his password policy to a more stringent one).
In any case, they now feel better about answering that self-assessment questionnaire (SAQ) and getting scanned.
Scanned? Yes, scanned for vulnerabilities by a PCI Approved Scanning Vendor (ASV), such as Qualys. Such scan must come up with no “PCI-scope vulnerabilities” (example). If it in fact does, the organization will likely feel much better about their overall PCI compliance status.
However, what happens if they rescan in a month, right before submitting the report on compliance (RoC) to their acquiring bank, while new vulnerabilities have been discovered in the software they use?
‘OMG! Somebody just “BROKE OUR PCI COMPLIANCE!”’
“Why is this scan showing vulnerabilities if we were just about to report the success of our little compliance project? Why are you, an evil ASV, breaking our beautiful PCI compliance? Have you got no shame? How about we replace you with another product that shows us compliant… always (like Scanless PCI or similar :-))”
People, it really doesn’t matter how many times we say “security first!” If some organizations don’t get security with all of its complexities and ignore it for years, “compliance first” becomes a real choice for them. At least they can understand it. And then later, “compliance first” becomes “compliance ONLY,” “checklists” replace “risk awareness,“ “flowcharts” replace thinking about their threats and vulnerabilities.
And then they get 0WNED. And CNN writes a great story about them!
To top it off, PCI Council also fines them since they were NOT even compliant…
So, make your choice:
“Security FIRST” or “Compliance FIRST”
Final word: if upon reading this, you excitedly choose ‘Compliance First!"’, please at least make sure that “Security SECOND” happens. If you have to focus on compliance first, please make sure to address security second because security is what probably drove the compliance requirements in the first place…
Possibly related posts:
No comments:
Post a Comment