The difference between Compliancy and Security could be less clear than one would expect. This is very understandable, because some Compliancy Certifications are all about Security. Let’s consider for example the Payment Card Industry Data Security Standard (PCI/DSS): this is an industry standard defined by a Consortium lead by the most important Credit Card issuers, born to ensure Security of Credit Card data by defining compliancy requirements binding each part involved in the management this data, during an after the processes required to perform Credit Card transactions.

The need is clear: what is more clearly a target for malicious people than money? So, it is all too natural that the Companies issuing Credit Cards require an high level of security from anyone that is supposed to handle credit card data. This has been the origin of PCI/DSS as a Security Standard and as a Compliancy requirement.

So, being compliant with PCI/DSS would mean to be Secure, wouldn’t it? Well, unfortunately not.

The fact is that Compliancy is a first step: it allows avoiding some stupid mistakes by leveraging the experience gained over time by other people in the field, but it is not a guarantee. In fact, attackers are not limited to the scope of what the standards dictate: they can search for additional mistakes and vulnerabilities. Let’s see some examples of that.

Target is an important retailer in the U.S.: they have seen their POS (points-of-sale) compromised by a group of attackers from Russia. The weakness, for Target, has been about giving too much access to a supplier (see Fridge vendor pegged as likely source of Target breach): the attackers violated the latter first and they gained full access to Target POSs as a result. The final outcome has been that a huge number of credit card numbers have been stolen and the credibility of the chain has collapsed so badly that the CEO had to resign (see: Target CEO Gregg Steinhafel Resigns In Data Breach Fallout).

More recently, a restaurant chain in the U.S., Jimmy John’s Sandwich Shop, detected an attack to their POS too, based on vulnerabilities found in their terminals, provided by Signature Systems (see: Signature Systems Breach Expands).

Finally, only a few days ago Staples has confirmed an attack to some of their POS, with a number of credit card numbers stolen (see: Staples is investigating a potential issue involving credit card data).

Surely enough, all the organizations above would have thought to be safe because of the good security practices they have in effect and because they are Compliant. This self assuredness have ultimately been to no avail, though: proof is that they have fallen to persistent attackers.

This is a very common situation, so much that attackers are focusing their attention in trying to violate specifically retail web sites: a recent study from Imperva’s Application Defense Center group on a set of 99 applications protected by their Web Application Firewalls, has shown that 48% of the attacks from August 2013 to April 2014 have targeted retail websites, while in the same timeframe 10% of the attacks have targeted financial institutions (see: Retail applications hit hardest, Web Application Attack Report indicates).

So, all those regulations should help avoiding incurring in those threats, but the sad truth is that they can do only so much. In fact, on one hand they cannot be updated very frequently, because large organizations tend to be able to embrace change only at a slow pace; on another hand, security depends also from the specifics of the given solution: in other words, a regulation imposed by a third party need to be applied to many contexts and therefore it tends to cover as much as possible, but not everything, leaving out what is less common.

Speaking of which, I remember a customer I worked for some years ago. His company routinely engaged a Penetration Testing company to check on their public-facing applications: in doing so, they were Compliant with an internal regulation. “All greens!”, he proudly said to me was the latest result. Well, after a brief discussion that lasted no more than half an hour, I did discover an important vulnerability in the design of their solution.

The moral is that to be really safe it is better to consider Compliancy as a starting point, not as a goal, and to design and implement Security assuming that violations are a fact of life: we should simply work toward giving attackers the hardest time and to limit the (bad) effects of successful violations as much as possible.