PCI Compliance: Hazards of the "Dull-Clarity" effect

It has been a while since I sat down to write a post for my blog. The monsoon season has just set in this part of the world. The days are hot and it rains heavily on occasion causing one to just enjoy the comfort of his bed a little more than usual.

This was a piece, which had been in the works for sometime now. I had planned to write it, close on the heels of the Savvis lawsuit (for the CardSystems breach), but I missed my cue. Anyway, here goes. This lawsuit has been abuzz in blogosphere because some of the banks that were processing their card transactions through CardSystems (which was involved with one of the largest credit card breaches in history), have decided to file a lawsuit against Savvis, the organization that attested to the compliance of CardSystems, with the Visa compliance requirement called CISP (Cardholder Information Security Program). The CISP was the predecessor to someone we all know lovingly as the PCI-DSS (Payment Card Industry Data Security Standard). A little background here. CardSystems was one of the largest credit card processors in the US, and they were involved in a breach which compromised over 40 million card numbers. Savvis was the company, which certified CardSystems as compliant with the standards. Now, four years later, Merrick Bank has filed a case against Savvis, alleging that it has been negligent in certifying CardSystems. Frankly, I am not aware of whether Savvis has been negligent or not, but blogosphere and online news portals have gone wild with the news. The Security gurus are quoting their same old lines of the inadequacy of PCI Compliance and are questioning the 'rigour' of the standard in the protection of cardholder information.

My intention with this piece is 1) To introduce the some people out there to the concepts of "Reasonable Assurance" and "as on date"; Two concepts which have been in lost in the rhetoric which several security folks have been dishing out relentlessly. 2) Drive home my point of Risk based compliance, another concept which has been dulled with wrong interpretations of the PCI Standards 3) and hope that a few organizations would actually understand the concept of PCI being risk-driven as opposed to a dull checklist, requiring their meek submissiveness.

The security world has much to learn from the Financial audit and assurance world. No auditor will be able to guarantee that an organization's financial statements are free from error or misstatement. The auditor has to do everything that a prudent person in his place would do and in the end, signs off on a report which states that a "reasonable assurance" can be provided with respect to the financial statements. The auditor is not god, and the laws are quite aware of that and have provided for a similar treatment. Moreover, the auditor does not have to look for fraud, another basic truth in the financial audit world. The auditor must perform a risk assessment and gain an understanding of Internal control, before he performs his audit tasks. Contrast this with the security world. Information Security assurance, being nascent as it is, has not promulgated such basic truths to its practicing professionals. It still (subtly) preaches the utopian ideals of "Perfect security" Furthermore, PCI as a standard still has a very hazy understanding of what assurance the QSA actually provides. Is it "Reasonable Assurance" or is it a guarantee, because if it is a guarantee, then QSAs should pack their bags and quit the business, because that is impossible to provide. When it comes to reasonable assurance, the only defense that an auditor should provide in his alleged negligence, is his working papers and evidence. So my advice to people who are QSAs, please keep your workpapers and evidence in perfect auditor, they are your only saving grace tomorrow when fingers are pointed at you.

Another important concept which people usually miss out with PCI Compliance is the "as on date" concept. When an assessor certifies an organization for PCI, the certification is done as on date and not for the "period ending". I have seen several companies take the proverbial snooze after their PCI Compliance. 8/10 organizations I have seen have serious issues with their applications, or their network configurations or their log management and review. They would have slipped into non-compliance several times during the year and would have remained so till the the recertification for PCI Compliance. An assessor cannot be held responsible for the negligent organization on a future date, unless he has wrongfully or negligently assessed the misgiving as compliant as on the date of certification. I would like to add, at this juncture that I am not aware of whether Savvis was actually negligent or not. Its negligence can only be established once its made to produce evidence of its assessment and its work papers in front of a court. My advise to assessors is to go ahead and fail organizations which have not demonstrated compliance throughout the year.

When it comes to Risk based compliance, my views have already been aired, but I would like reiterate some practical angles to the same. Several clients ask me, "Where does it say that this has to be done in the PCI Standards?" The greatest advantage of the PCI Standards is also its weakest point. Its clarity. Several organizations interpret PCI to be a checklist requirement set which they need to fulfill and be done with. The PCI has acquired a reputation of being a standard which prescribes exaclty what to do and how to do it and that it is inflexible in its approach. True, it is specific, which is why, when a recommendation outside its realm, but very much in the realm of specific risk is given, it is quickly shot down by an organization as not being specific in the requirement. I have several (often heated) arguments with clients who ask me questions like, "Where does PCI say that Internet access to these partiular set of users should be blocked?", My reply to them is that PCI is a baseline set of controls to be applied to any environment storing, processing or transmitting cardholder information. For such specific requirements, a risk assessment is in order, which narrows down certain risks which are specific to the environment. If the risk of individuals having access to cardholder information as well as the Internet (where cardholder information can be sent over email or over the internet in any way) is high, then it is only prudent that you mitigate the risk and not let it become your Achilles Heel. My advice to organizations. Dont look at PCI as a checklist for truly being secure. Treat PCI as a baseline and add to it controls for the risks which are specific to your environment.

I would like to conclude by stating this. PCI Compliance, like anything else in Information security, is at its growing phase. There are bound to be a few teething problems with respect to the standard and its expectations. An organization intent on pursuing PCI Compliance should not be misguided by the pure view of the 12 requirements of PCI, but to understand the risks before going into requirements.

Why doesn't anyone pull their security SOx up?

This is a question, which has been raging in my mind for a while now. It has been something, which I see a great scope for improvement for and something that is currently, very rarely, if ever, followed.

The Prologue
First, a prologue to the entire story. I am sure all of you know the Sarbanes Oxley Standard, popularly known as SOx. It is one of the most important compliance requirements of publicly listed companies in the US. It is governed by the PCAOB (Public Company Accounting Oversight Board), which is an independent oversight body for SOx. SOx arrived in the wake of several scams such as Enron and WorldCom. These scams rocked the business world and caused a great deal of embarassment for corporate America. All these scams had something in common; they had cooked the books (misstated financials) and this syndrome percolated to the very top, including the CEOs and CFOs of some of these organizations.

Enter SOx. SOx was the brainchild of two US senators whose last names have been given to the standard. Their take on this was that shareholders and the general public need to be able to reaffirm their faith in an organization's financial statements. This involved, first of all, establishing accountability from the top management (as they had been intricately involved in the scams previously and had the most reason to misstate financials) and providing auditors with the teeth to ensure that the organization's control environment was adequate to ensure the "true and fair" view of financial statements. Therefore, as one can clearly see, SOx is primarily concerned with the integrity of the Financial Statements and the environment in which they are processed and created. The auditor assessing an entity for SOx needs to ensure that the environment in which Financials are prepared is secure and more importantly, an environment with controls which can be relied on to ensure the integrity of information and lastly make sure that the Financials are not misstated. This involves a process many of us have heard of. Identify scope, perform Risk Assessment, Document controls, Test controls, identify gaps, continuous improvement.

The Conundrum
Our look at SOx was fine and dandy, but all that is not new, right? All of you have heard it time and time again. Especially those of you who work for large consulting firms have seen SOx being thrown around in a conversation a lot of times. I have been interacting lately, with a lot of the auditors who assess their clients for SOx compliance. My question to them usually is, "How do you assess the integrity of the environment, which is involved in the creation and processing of financial information?". Their answer to that is something like this, "We usually ask a few questions about their IT policies and procedures and establish whether we can rely on the financial statements. Our worry is more on the business processes".

When I say "financial information", it means information from all quarters which is leading to the preparation of financial statements. It means, any system which is involved in the initiation, authorization, recording, processing and reporting of financial information. So you can imagine that this is.....a lot. An ERP system which is part of the organization would be a part of it, in case of an e-commerce company, for instance, the e-commerce accounting and inventory management modules of the applications would probably need to be a part of the SOx assessment.

Let me give you, quite a real scenario and then explain the matter. What if an ERP application is vulnerable to an Application vulnerability like XSS or SQL Injection where an insider might be able to hijack sessions, gain access to the privileged information and make unauthorized changes which are not logged, not checked in any way. If an employee were able to submit an expense statement and hijack his manager's session and authorize the expense statement, with no logging. Would I, as an auditor rely on the financial statements for a SOx environment, knowing that the application could be compromised and the financials could potentially be modified or in some cases even destroyed, and more so, without being checked (no logging). Taking the business process side of things, if the same person could could initiate an expense statement and authorize it himself as part of a business process, that would be looked upon as a serious hole in the internal control of an organization and the assessor would have no doubt that it was a significant deficiency. Let us take another instance, if a business unit of a corporation were vulnerable to several network issues, let us assume that they do not have proper firewalls rules, restricting specific IP and port sets, that default passwords still exist on their network devices and servers. Let us assume that a supplier breaks into this network and overstates the value of the organization's account payables. Would, I as an auditor sign off on that entity's financials, knowing that the entity can be easily breached and integrity of data can be adversely affected?

This is just from the auditor's standpoint. A company would be held equally responsible for its negligence to IT security (as IT is a key driver in financial statements) and its reputation and business value would be seriously impacted.

Unfortunately, the scenarios I gave you have real life significance and are quite real in the corporate environment and I believe that they are largely going unchecked, because the auditors for SOx are usually not capable of assessing IT controls and are under the false belief that SOx only applies to business process and related internal control, whereas the real scenario is quite different. In today's world of highly connected enterprises, IT is a huge area of consideration. IT controls, in essence form an integral part of the entity's internal control and can significantly impact the way financial statements are initiated, authorized, processed and recorded.

The Solution
My advice to the SOx assessors and auditors of the world is this. IT security is an important consideration for any entity today. SOx does not absolve you of the duty of performing basic risk assessment and control testing (like you would do for business process with assessment of internal control to ensure that financial statements may be relied upon). Integrity of information can be made or broken by IT security in today's digital age. SOx must be treated like any other security compliance which requires scoping of processes and applications affecting financial information, performing Risk Assessment, testing controls of the processes or applications and gap analysis. As you can see, this clearly involves issues like Firewall management, Application and Network security testing, Secure Application development, deployment and configuration, Network Change Management, Logging, Integrity Monitoring, Patching, AV and all the other IT security requirements which one can formulate through effective risk assessment and best practices. Bottom line. SOx is not just a financial standard. It has a serious impact in an IT environment and from an IT standpoint.

OWASP Chennai Meet - 17 May 2009

The OWASP Chennai Chapter meet was held on the 17th of May 2009 at Chennai. It was very nice to see some dynamism from the OWASP Community in India. I am happy to see great steps being taken by the Chennai OWASP Team (Chandrasekar and the rest) in taking initiative.

The talks scheduled for the day were on Globalization and its role in Information Security and Mobile Crimes

I was invited to speak and I spoke on Application Security Risk, in a talk entitled "Application Security Risk - The Full Circle"

Here's the presentation:

OWASP Chennai Talk - Application Security Risk - The Full Circle

View more presentations from abhaybhargav.

This presentation highlights the importance of Application Security Risk and how to perform effective and comprehensive Risk Assessments for Web Applications to provide for a robust protection strategy. It highlights how an effective Application Security Risk Assessment can result in the development of a secure SDLC, feed the Security Testing area with threat modeling and the development of "Abuse Cases" and become the foundation for a strong and secure web application.

The Devil's Advocate: Compliance vs Security

The fires in blogosphere are ablaze with talk about the Heartland Payment Systems breach. There has been a great deal of PCI bashing, right from Bob Russo's statements to the whole issue of Compliance and Security.

For those who are not aware of the HPS, or who have had their head in the ground because of the current economic meltdown, I shall recap. Heartland Payment Systems is a large Payment processor in the US. Malicious software in their payment processing network seems to have caused one of the largest breaches in history. It seems as though over a 100 million cards may have been stolen. The great gory details of the story are not known yet as forensics for this sort of thing takes quite a while.

Security vs Compliance is one of the most significant things I have heard being posted all over the Internet. Everyone seems to be talking about the fact that Compliance cannot be equated to Security and that the PCI Standards are flawed in their attempt to make their industry more secure.

Us security folk secretly love an incident of this magnitude. Its incidents like these which makes people sit up and take notice of security needs and this is our time to shine :) But on a more serious note, let us take stock of some important facts at this point.

Agreed, Security != Compliance. I believe strongly that those who expect their plain-vanilla compliance program to do miracles for them. Compliance can never take the place of a voluntarily committed security program which comes from experience and a proactive risk approach. But, at the same time, one cannot simply discount the fact that compliance is important. Take the case of the American Capital markets. The deregulation (lack of compliance and enforcement) did not ensure that all the Banks and large Investment houses take a "Safety First" stance. They continuously created their weird and arcane financial intruments, which were toxic for the economy. Until there was a Sarbanes Oxley for the Corporate world, there would be no accountability for any of the Top Management's statements and actions (case: Enron). In fact, only the stick that is accompanied with non-compliance (fines, increased transaction costs, de-listing, etc) gets some companies adopt a security program. The carrot that comes (proactive security, better understanding of risks, threats and vulnerabilities, etc) with compliance simply does not appeal to these companies.
In my time handling several PCI projects, I realized that there are always a bunch of organizations which are driven towards genuinely acheieving optimum security and not just chasing a certification and there are others, who decide to "dress their processes well" before the auditor walks in. We need to understand that there are always going to be organizations like the latter and accept the fact that these organizations can only be driven to better security by incentivizing them in forms such as low cost of security, increased business opportunity because of enhanced security and of course, once they get hacked and lose data and reputation (and if they are still not bankrupt in the process), would try and develop a proactive, risk based approach to security. This brings me to my second point....

PCI = Risk-based Security Compliance. When I hear someone talk about PCI Compliance, I usually hear the word "checklist". PCI is viewed as more of a checklist assessment and once the checklist is filled with "Yes", everyone's happy. This is very very far from the truth. Companies and Security professionals who look at PCI in this light are actually getting it all wrong. PCI is nothing but Asset Based Risk Assessment, where the asset in question is Cardholder Information and the ultimate objective is the protection of Cardholder Information. Which is why Security pros need to understand the systems of interest, access paths, points and containers in which the asset is housed and devise security solutions based on the PCI Requirements. One cannot advise a small organization getting PCI Compliant to drive its entire encryption process using a HSM (Hardware Security Module) or a large processor like Heartland to use something like TrueCrypt to drive encryption. Yes, PCI is granular, PCI is very clear on most counts, but by treating PCI Compliance as a checklist assessment or a checklist compliance program, security assessors are actually saying that Compliance = Security, which brings me to my next point.

In the long run, compliance ultimately becomes "bastardized" because of the people advocating and following it. The same thing happened for ISO-27001, which is a great standard, but eventually became mis-understood and mis-interpreted beyond recognition. I came across and ISO-27001 certification which was only done for the "Security Components" of a company's infrastructure (namely 2 firewalls and 2 routers, in which case the routers are not actually a "Security Component"). There is nothing inherently wrong with the standard. It is just that for the sake of convenience of both the security assessor and the assessee, the standards are interpreted in a way which does not take into account, the all-important aspect of Risk (which is unique to every organization). So, to re-iterate, when an organization is going in for PCI Compliance, it needs to determine what kind of entity it is. Is it the former type, proactive, and risk-based towards security needs, or is it like the latter, the "Chasing certifications 'cause I need this business" type. If a company actually believes that it is in the first type, then it needs to evaluate security professionals who share the same values and ensure that the professionals deliver on their promises at performing a solid evaluation of risk and then concomitant controls.

In conclusion, I would like to say this. Although Compliance and Security are not necessarily the same thing, we need to appreciate the fact that compliance, when interpreted and enforced correctly does eventually lead to a solid Information Security program. It is upto the people in the organization to determine what they want, Compliance leading to Effective Security or Compliance just leading to.....Compliance.