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.

My brush with the Gumblar worm

Some of you might have heard of the new worm out there known as the Gumblar worm or the gumblar.cn worm. It is a worm which has been spreading rampantly across the internet. This worm has become the scourge of the internet after the conficker worm. The Gumblar worm has two ugly sides to it, both of which I have been exposed to.

This was way back in March, when we were performing a company's website assessment. The company had outsourced their website development activity to a organization that designs websites. The company had run into a few security issues including Directory traversal vulnerabilities and weak passwords which the web design company had caused. Once the website was up, I opened up the page to see my Avast Anti-virus light up like a Christmas tree, with a malware alert for a "JS:Redirect" worm. Needless to say upon exploring the source in the php and html files, I found that a large piece of javascript code, which had no apparent business being on the page, was there. It was obfuscated code, which obviously caused the worm to propogate. The Javascript code for Gumblar is given below:

I have removed the Gumblar worm code as some AV apps were throwing up alerts from their content filtering engines. Please check elsewhere for a copy of the code.

The gumblar worm infects the PC when the PC opens up the website which is infected the malicious javascript.












The execution of the malicious code results in a backdoor being installed which attaches itself to Internet Explorer and also manipulates Google searches. Furthermore the worm is also known to disable anti-virus software, install fake av applications and also sends out spam. This is the one facet of the Gumblar worm. The other facet of the Gumblar worm, is worse and is extremely worrisome for a security professional. Gumblar also steals FTP credentials and appends itself to pages hosted in the webserver, thereby wreaking havoc to a webserver. This means to say that Hosting providers and webservers hosted by organizations may well have already been seriously compromised. FTP credentials have been stolen several webpages hosted in webservers all ovetr the world have been affected by the gumblar worm. The number of attacks over the last week have grown by 188% and counting and has accounted for over 42% of the malware detected all over the world. The number of infected websites has jumped from 800 to over 3000 in a matter of a few weeks.

As you can see, the gumblar botnet really goes two different types of systems. One it goes after PCs, where the PC is infected and the Google searches, Internet Explorer and the vulnerabilities in Adobe Acrobat are exploited. The other system is the Webserver, where it goes after FTP passwords and then appends the code onto all the web pages in the webserver. I first experienced this worm in March of this year and the worm has now started surfacing in all its glory. So, for all of you, here are some tips to stay safe and keep your website safe:
1. Latest AV Definitions: The biggest issue has been that Antivirus vendors except, I think, Avast and Kaspersky have not woken up to this issue till recently. Please make sure that your AV definitions are up and functional against Gumblar's many variants.
2. FTP Credentials: This is a good time to run a thorough manual and automated scan of the webserver and change the FTP credentials for all users in the system. It would also make sense for organizations hosting their web content with hosting providers to talk to them and see how their dealing with the situation. Also, please make sure that the FTP passwords are stored securely and that there is adequate encryption or hashing which is used to protect the same.
3. NoScript: For ordinary users out there, please use NoScript with Mozilla Firefox, it goes the distance in protecting you from the malicious javascript in websites against executing and infecting your PC.
4. Hosting and Web Design organizations: Please make sure that your hosting providers also take the same precautionary measures. In case you are having your website being designed by others, please make sure you test it in a staging environment before deploying it over the Internet. You might be aiding in the propogation of the worm.
5. IPS signatures: I already know for a fact that ISS Proventia has signatures released for the Gumblar worm. I am sure others would have also done so. Please keep the IPS updated for the Gumblar sigs.

The Berkeley Data Theft

I just received word that the University of Berkeley has had a major security incident.

The Campus Health Services Center databases have been hacked (supposedly by foreign hackers) and over 160,000 records of PII (Personally Identifiable Information) have been exposed and may have been stolen.

According to the university, the databases contained individuals' Social Security numbers, health insurance information and non-treatment medical information, such as immunization records and names of some of the physicians they may have seen for diagnoses or treatment.

It is believed that the breach began sometime in the month of October 2008 and continued till April 9th 2009, when the campus administrators discovered the breach. The University has said "The attackers accessed a public Web site and subsequently bypassed additional secured databases stored on the same server."

This seems like another Web Application attack, where the attackers have been able to gain access to Databases using the Web applications and cause the breach. It might be a case of SQL injection coupled with various other types of attacks.

This is a "wake up call" for universities all around the world. Universities are perhaps the largest repositories of data (student data) and they have access to sensitive information about the students. Such breaches can cause massive instances of identity theft.

I find this even more alarming thinking about the Indian state of affairs. India's universities have recently taken to computerization and the number of students in Indian universities is a mind-boggling number of something like 8-10 million. Such security incidents put all that data at risk.

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.