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.

Payment Application Pacman

Lately, I have been flooded with Application Security Assessment work. Applications of all forms, shapes and sizes have been given to me to test, which I have gleefully accepted. The work is supremely interesting. I always knew that there were tons of applications being developed all over the place, but I always figured that they would be of a certain nature, like a plain vanilla E-Commerce Application or a Banking Application, etc. Because of the spate of application security testing I have been doing recently, I have found that there is an application for everything. Right from Flea-Market Management to Cold Storage Management Applications. The granularity of business verticals which applications are catering to today are mind-boggling. Wait, I think I have diverted from my story, haven't I? Damn, I do this all the time, okay, back to the story.

I was testing this application for Payment Card Industry Compliance recently. I was quite impressed with the application at the outset. The application seemed to be loaded with some innovative features and it seemed like a great application for the business vertical it was hoping to address.

I started to test the application a few days later. It was sometime in the evening. I was not in the mood for any more testing. I had done quite a bit that day. I had already finished a preliminary vulnerability assessment of the server and as the assessment would be performed over a few days (yes, I procrastinate, a lot!), I thought of playing some Pacman. It is one of my favourite games. I thought of a slightly weird way to play it. The application I was testing was structured in a way where the user would use the input fields to enter values to be stored in the Database and as the Database updated, the previous inputs would be displayed in the table below it. Great way to test for persistent XSS, thought I. Therefore, I entered this harmless reflected XSS script alert in a field


and this is what I got


"Not bad", thought I, "the developers have managed to keep the bad apples out, or could it be the simplistic process of weeding out the angular bracket using a even simpler client side validation routine?"

Not to be deterred, I fired up my ever-trusty WebScarab and decided to take this attempt at killing two birds with one stone (namely me wanting to play Pacman in a different way and app sec testing) and caught a perfectly harmless request and gave it a interesting twist. I entered as input an html embed pointing to the Pacman Flash game, a lo I was gleefully playing Pacman on an application which had no business storing this in its Databases. One part of my test was done, quite a finding too. Cross Site Scripting (and later CSRF) vulnerabilities rampant on this site.

Coming back to my initial tangent. There are around 108 million distinct websites in the world today and even now, 23% of the world's population is exposed to the Internet, which is looking at a meteoric growth pattern in the future. According to the WASC (Web Application Security Consortium), almost 50% of web applications are vulnerable to Scripting and Information leakage vulnerabilities. As development becomes easier for everyone, we are only going to see more number of sites and apps falling prey to session hijacking, SQL Injection, Denial of Service and many other evolving attacks.

BTW, You can play the evergreen Pacman here