Verizon has released their 2009 Data Breach Investigations Report. Perhaps someone can recommend a new name for next year so we don’t have to say “did you see DBIR?” This is pronounced “Da Bear” and seems to start all kinds of references to Chicago sports.
Back to the point, the numbers are up, as most security professionals probably already knew and expected:
The percentage of breaches in our caseload involving financial service organizations, targeted attacks, and customized malware all doubled in 2008. It’s sure to win me the “Captain Obvious Award” from the Securitymetrics list, but organized crime activity increased and was responsible for over 90% of the 285 million records compromised. The scales continue to tilt more and more toward servers and applications as the point of compromise.
Here are some key points I noted:
Verizon continues to maintain a vast majority (74%) of data breaches originate from external sources, yet the “involved multiple parties” category grew nearly 10%.
Almost all (98%) of the breaches were related to a misconfiguration (mistake), hacking, or malware installed to collect data. Speaking of mistakes, I have to point out Figure 11 on page 15:
Oh, well. Nothing like a mistake within a report on mistakes.
More seriously, there is significant growth in the malware development community. You might say this is an obvious trend in an industry where writing malware now generates large amounts of cash. Nine out of ten records exposed are due to malware and yet only one-third of incidents involved malware.
Default credentials (third-party remote access) and application-level attacks on the database were the most effective attack vectors used to place the malware. This makes sense if the systems with data are still targeted. If those systems become more secure, then I suspect the attacks will come more through phishing, attachments and other social engineering efforts. Right now, however, malware is installed by the attackers themselves 90% of the time. Keyloggers and spyware are the most common, followed by backdoor/shell, and then capture/store data software.
Note that a small percentage of attacks (17%) considered to be “highly difficult” accounted for nearly all (95%) of the records breached.
The large number of breaches and exposure of cardholder data seems to be having an effect on economics of the underground:
…market saturation has driven the price down to a point where magnetic-stripe information is close to worthless. The value associated with selling stolen credit card data have dropped from between $10 and $16 per record in mid-2007 to less than $0.50 per record today.
Verizon says this comes from data collected by their underground intelligence operations. I wonder why do they call it underground. Intelligence operations would have the same meaning, but maybe they want to distinguish themselves as dedicated to monitoring only the underground as opposed to law-abiding citizens.
PIN data is now highly targeted, and has many issuers scratching their head, as we know from the RBS Worldpay, Citibank/7-11 and related cases. Verizon suggests this is a natural evolution based on the deflated value of cards and higher value of PINs.
The higher value commanded by PIN data has spawned a cycle of innovation in attack methodologies. Criminals have reengineered their processes and developed new tools—such as memory-scraping malware—to steal this valuable commodity. This has led to the successful execution of complex attack strategies previously thought to be only theoretically possible.
This is an interesting problem. Either security has failed to the point where cardholder data has flooded the market, driving down prices and thus forcing criminals to seek more valuable data such as PIN…or security has worked on cardholder data and so criminals have had to shift to PIN data to steal money/goods.
Two-thirds of the breaches were never publicly reported, but are included in the study:
At the time of this writing, about a third of the breaches investigated by our team last year are publicly disclosed. More, especially those toward the end of the year, are likely to follow. Others will likely remain unknown to the world as they do not fall under any legal disclosure requirements.
Oh, this is just begging regulators to start investigating and to create more laws. Two-thirds is a high percentage to call an official breach yet never disclose.
Unlike the datalossdb.org information, Verizon says 31% of breaches were in retail and 30% were in financial services. The latter is said to have doubled its percentage since last year. Does this reflect Verizon’s customer profile more than neutral market data?
The increase of data breaches in the financial sector is indicative of recent trends in cybercriminal activity highlighted in the “State of Cybercrime” section. As will be discussed throughout this report, financial services firms were singled out and fell victim to some very determined, very sophisticated, and—unfortunately—very successful attacks in 2008. This industry accounted for 93 percent of the over 285 million records compromised. This finding reflects a few very large breaches investigated by our IR team in the past year.
That says both the financial sector was targeted more in the shift-to-PIN trend mentioned above, and financial services breaches are large, but also that it was who Verizon worked with more often. I think another way of saying this is that retailers represented the breach when it targeted acquiring banks, but issuing banks are categorized as financial services, so issuers are officially sharing in the 60% of all breaches landscape. The other 40% of breaches seem to be related to travel and products.
Insider breaches, although lower in frequency (11%), appear to expose more records per incident (100,000 median) than external breaches (43% with a median of almost 40,000). With that in mind, total records exposed by only external sources was more than two hundred times greater (267mil) than only internal sources (1.3mil). This is due to the average of external source breaches running nearly 6mil. Verizon takes this, tries to characterize it in terms of likelihood and impact, and concludes that things are “exactly opposite” from prior years:
The threats are said to be predominantly from East Europe and East Asia. If you include North America, you have 82% of all attack sources, although a large majority of investigations stopped with an IP and never assigned geographic data. Likewise, attacks are usually not traced to a specific entity but about 20 percent still were found to be known organized crime.
Insider attacks came as often a regular user as an administrator. I say this does not bode well for administrators, although Verizon seems to think they are proving why we should not “infer administrators acted more deliberately and maliciously”. Administrator attacks should be assumed much lower than user, if you ask me, but maybe that’s because I still think of administrators as those you would hold to a higher standard before giving them access. A user could be anyone. In any case, delays in shutting down access were said to be the attack vector.
Verizon says the vast majority of attacks are at the application level. Yet, for all the noise on cross site scripting attacks in recent years, the data shows that default credentials are still by far the biggest problem, followed by SQL attacks. XSS is barely even on the charts. This is echoed by the fact that breaches that exploited known vulnerabilities involved patches available for more than a year. The data provided makes it look as though if you can patch within six months, you would not appear in the Verizon report. Perhaps most dramatic is the claim that they saw only one wireless exploit for all of 2008.
I thought it interesting that the highest percentage of breaches by software was split 30/30 between POS and DB with application servers at 12%, yet percentage of total records was split 75/19 between DB and application servers. Thus, POS were often breached but only accounted for 6% of all records. This makes sense as the POS should be wiped of data immediately after authorization and only hold a small subset of transactions. Web servers, just to make a point, were ten percent of all breaches but disclosed 0.004% of records. Begs the question of why it was not 0%, since web servers do not store data. This also makes me question Verizon’s claim that “Our data set…is comprised only of incidents in which an actual breach occurred.” Laptops account for 4% of breaches and have 0.000% of records. Why are laptops included then?
The unknowns section actually surprised me. I thought unknown assets were a frequent problem, such as in the FAA breach. However, Verizon suggests unknown data is a bigger issue, followed by unknown privileges and then connections. In other words, people know they have an asset, but usually do not know it has regulated data, often do not know what accounts have access, and sometimes do not know who can connect to it.
Another surprise was this comment:
In the large majority of cases, it was the lax security practices of the third party that allowed the attack. It should not come as a surprise that organizations frequently lack measures to provide visibility and accountability for partner-facing systems.
Lack measures or lack incentive? My experiences have always been that IT organizations love to assume third party systems will take care of themselves even when they known it not to be the case. This is like a form of liability transfer with no documentation. When the chips are down, this continues with people claiming the third party should have known, done a better job, and so forth. The job of the security organization is often to point out that third parties and partners are not doing anything they said they would, or haven’t a clue with regard to risk, and to try and find someone who will take responsibility for the relationship. This latter step is often the core issue. Many regulators are getting wise to this ruse and assigning a formal liability statement to those who use partners, so ambiguity and excuses will be less convenient. For example the ARRA/HITECH of 2009 clamped HIPAA rules directly onto treatment of business associates, whereas before HIPAA only applied to regulated entities themselves.
The recommendations seem straightforward, but perhaps they could have organized it by PCI priority/requirement instead of creating a new list. I mean they do not even mention removing data, which is clearly an essential step to avoiding a breach:
1. Changing default credentials is key
2. Avoid shared credentials
3. User account review
4. Application testing and code review
5. Smarter patch management strategies
6. Human resources termination procedures
7. Enable application logs and monitor them
8. Define “suspicious” and “anomalous” (then look for whatever “it” is)
Finally, there is interesting data on the timing relative to breach and discovery. Rather than comment here I’ll likely do a webinar dedicated to this topic in the near future, as well as expand on the other comments above.
