Archives For Data Breach

It is very interesting to understand how attackers work, and sometimes it is also scary to see how unprepared we are. This in an unbalanced war, which we are losing.

Ransomware is on the rise, and it is more and more dangerous. But it is not the only problem. Many of my customers are totally unprepared, yet they say that they have not been compromised in the past, but for a couple of well known incidents. No wonder, considering that their detection controls are in some cases totally ineffective.

Sometimes customers have no clue of where their assets are or how they can be exploited. The most absurd thing to see is that many organizations have VIPs that are not tolerant toward the limitations imposed for Security reasons, and they have the power to require exemption: as a result, sometimes those who have the highest value for an organization are the least protected!

Attackers already know all this and understand your business better than you. They are going to find your weakest spots and to hit them, hard. Many are not able to see that coming and even less to respond properly.

FireEye’s incident response business further reports the mean “dwell time” for breaches in EMEA is 469 days, versus 146 globally.


In other words, in EMEA the time an attacker on average remains undetected in a victim’s system, is more than 3 times higher than the World average!

We have to change this and soon, and it all starts from adopting a more active stance toward Security. It is not a cost: it is a necessity!

David Ferbrache from KPMG describes the situation very well, and SC Magazine has an article about it that can be both alarming and illuminating:


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.