Sunday, February 16, 2014

Blinded (and Bitten) by Compliance

I have remained silent on issues of security as we entered the new year, and many of my readers have asked me why. With the plethora of merchant breaches that hit the news during the holiday seasion, surely I had an opinion (or six) on the topic...so why not share them?  The reason was simple: there were already way too many "experts" and pundits providing comment with minimal information that adding one more voice to the fray would most likely be counterproductive.  The merchants who were breached have been vilified in the press and had their collective competence unfairly questioned by far too many people in far too many venues;  anything I had to say (and much of it would be favorable to my security brethren) would merely add to the noise...and might be subject to misinterpreation by folks hungering for a story.  Still, now that the media drama has subsided and we're into the "what must be done" phase of the crisis, I think its time for me to come up for air.  While I don't wish to continue "making glue" out of well-flogged security issues, there is one area that I believe bears a tad more exploration:  the PCI-DSS and its role within payment security.   

Earlier this month, Bob Russo of the PCI Council formally responded to criticisms  of the PCI-DSS standard in the wake of recent breaches.  Mr. Russo reminded nay-sayers that (a) there is no such thing as a silver bullet; (b) the PCI standard represents an "excellent line of defense" in terms of security; and that (c) it is not the job of the PCI Council to enforce merchant or banking institution security.  In short:  the recent merchant breaches do not represent a failure in the PCI-DSS but rather a breakdown in security controls within the respective institutions.

Hmmm....

I remember working as a CISO in the mid 2000s during the early days of credit card breaches.  I remember watching a couple of television commercials sponsored by all five major credit card brands touting the safety and sanctity of credit cards payments.  Every time I saw one of these commercials I noted to my colleagues that I felt the credit card companies were "running scared" from regulation in light of the then-current state of breaches;  I was curious as to what the card brands would propose to fend off the spectre of further regulatory oversight.  The very next year, PCI-DSS came into being.  More prescriptive and detailed than HIPAA, the PCI-DSS had more teeth than existing federal mandates given the ever-looming possibility of losing the ability to process electronic payments transactions.  During this time, the card brands feverishly campaigned to anyone who would listen about how PCI-DSS would collectively raise the bar in how credit card processes were secured and inject peace of mind back into transactions.

The security community willingly and eagerly jumped onto the compliance bandwagon, touting HIPAA, PCI, and GLBA whenever possible.  "At last," the community said, "we have a useful arrow in our quiver."  Security was either the law of the land or a regulatory requirement for business.  We hitched our programs onto these regulations and laws with reckless abandon, eschewing the nay-sayers (yes, I was one of them) who touted the  regulations yet cautioned that they could become yet another brand of FUD (fear, uncertainty, and doubt) if we linked our programs too closely to them.  Years would pass before we would come to realize that by equating security to compliace we risked watering down our programs to the minimum necessary controls required to obtain a compliant state.  It would be even more years before we recognized that the final determination of legal and/or regulatory sufficiency often did not reside within security but with the offices of the corporate attorney.

At the end of the day, any security professional has to agree with the statements made by Mr. Russo.  Any assessment against regulation is a point-of-time view of an organization, and while the DSS is an excellent standard it mightn't be suffient to ensure security of all critical assets within the envirionment.  Worse, if security controls are not monitored and appropriately enforced then even the most robust ecosystems will beome vulnerable.  In defending the PCI-DSS  and its viability, Mr. Russo has merely restated a tenet that security professionals started saying en masse several years ago:  compliance does not equal security. My minor umbrage, if you will, to Mr. Russo's comments stems from the fact that the security community's late realization of the aforementioned tenet was one of the contributors to the successful marketing of the PCI-DSS as a standard of excellence for security.   

One cannot help, as a community, feeling partially thrown under the "blame bus" by an ally.  

Mr. Russo's interview should hopefully represent a wake-up call for those still focused on compliance instead of security.   Anyone struggling with their leadership to focus on holistic, risk-based security versus compliance should use Mr. Russo's interview as a reminder of the role -- an limits -- of compliance within one's security program.

My two cents...

1 comment:

  1. After spending years redesigning and architecting numerous corporations to help them comply with PCI, I do find it disturbing to see PCI becomes the strategic architecture that defines security within an enterprise. For instance, a CISO may consider an ISO27002 framework and the numerous compliance regulations will fit within the ISO framework. The PCI Standard is not a security strategy; whereby as Kim stated, compliance does not equal security. While the PCI Standard is a good regulation, it should never be used as the security framework of any company. Unfortunately, I have seen the PCI Standard as the security framework for countless small and large corporations. Just because your company is PCI Complaint does not mean your company is secure. Take for instance the weaknesses of the PCI Standard:
    1. System account passwords never need to be changed. Most system account passwords are super easy and are repeatedly used on multiple systems using the same password.
    2. No control that states SSL must be used on every internal web site. Many admins use the same credentials for the credit card application as they do for web portals that don't has a self-signed SSL cert. It is great for hackers or malware to intercept privileged credentials.
    3. Credit card data, CVV, name, expiration can be transmitted in the "clear" within the company network for pre-authorization to the payment processor.
    4. Any provisioning system that can bring up servers very quickly are using the same password credentials. If you get one password, you get on many systems.

    These are several examples of how PCI does not equate to security.

    ReplyDelete