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.

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).

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.

Disclaimer

The author of this Blog, Simone Curzi, has been a Senior Consultant and Delivery Architect in Microsoft Consulting Services (MCS) Italy for more than 6 years and has spent a total of 15 year as a Consultant in MCS. After having spent 2 years as a Security Premier Field Engineer for Microsoft Proactive Services (CSS), he has recently joined Microsoft Global CyberSecurity Practice (GCP) as Senior Consultant.
Simone is also the Leader of Microsoft Technical Community for Application Security.
The content published here express his own personal opinions only. By any means they do not necessarily reflect Microsoft's assessments or persuasions around Security or any other topic discussed in this Site. Microsoft has not participated directly or indirectly to the preparation of the current Site, for example by providing any resource other than paying for the salary.
The content is based on public information and sanitized experiences: it will not contain Microsoft Internal-Only material nor information traceable to actual Customers, even if someone could occasionally recognize himself or herself.