Salted Hash is on the road this week. All week long, the blog will be updated with news, and various tidbits from Black Hat USA, B-Sides Las Vegas, and DEF CON 22.
The annual gathering, sometimes called Hacker Summer Camp, is one of the year's largest events, covering everything from corporate-focused security briefings and training, to hands-on lessons in physical security and actual hacking from the people who live and breathe security both on and off the clock.
Unlike many of the corporate conferences, such as the RSA Conference, Black Hat, B-Sides Las Vegas, and DEF CON, allow security types the chance to socialize more than usual, while providing a place to learn from their peers. While Black Hat has shifted to a more corporate stance, that's ok because B-Sides and DEF CON are more than able to cover the gritty stuff when needed.
Given the theme of the week, today's post will examine the evolution of the security industry.
Later this week, Trustwave will be releasing their Global Security Report, but unlike previous releases, this new report is interactive – more of a website really – and includes all of the data from previous reports, as well as new content added on a regular basis.
"Over the past five years, we have noticed the criminals have gotten smarter and more successful," Trustwave explained in a briefing on the report.
"However, the more businesses use threat intelligence to create and modify strategies, the greater the likelihood they will stay ahead of the crooks."
Looking at the stats from 2009 to 2013, Trustwave's GSR offers an interesting snapshot into the threat data the company has collected over the years.
For example, there is a clear pattern that more organizations are detecting breaches themselves. While that's good news, it's still a low number - 24 percent in 2012 and 29 percent in 2013.
Self-detection is one way to decrease the time it takes to contain the incident and recover, which lowers the incident's overall impact. Looking at the growth that's been recorded, it's likely due to a mix of threat awareness and risk-based protection planning. Two topics that have been heavy hitters in the corporate world.
Another historical note focuses on the types of compromises that have happened over the years. In this instance, the largest growth is located in the e-commerce sector, as attackers follow the money and target the low-hanging fruit.
Last year, 54-percent of the assets targeted by criminals, based on the incidents Trustwave was involved with, were e-commerce assets and 96 percent of the applications tested had at least one serious flaw.
Part of the reason e-commerce attacks are so common is that retailers are eager to leverage Web and app-based services to increase their foothold on the market, but while business-driven apps and services are advancing, the process of securing them has stalled.
Thus, problems like SQL Injection, Cross-Site Scripting, and flawed authentication and session management, remain easy targets to criminals.
While reading the stats from Trustwave, I was reminded of a recent conversation with a developer. During the normal progression of talking shop, the topic of application security came up.
Part of the conversation hit on the fact that some of the more common application flaws are more than a decade old. For example, SQL Injection is sixteen years-old, and Cross-Site Scripting has been around since the 1990's. So why are they still a problem?
The developer and I didn't come up with any answers, and given the state of things today, no one else has either. Common protections, such as application firewalls, code analysis, and vulnerability scanning exist, but they can be costly and unavailable to development teams.
Worse, the development team isn't given the option to process code in stages or bake security into the product. Security is still seen as something that can be added with a patch later, once the product is live. It's a poor practice to be sure, but it's a common one.
Another common problem is poor Q&A and code recycling. Sometimes, a developer needs a quick function and uses Google to search for examples. Sure enough, on a forum somewhere, someone has posted the exact code needed. It's added to the application, it works, and the project is marked as finished. The problem is, no one thought to check to see if that function was safe, and later, it turns out that it wasn't.
On top of that, the inclusion of flawed third-party code or applications into a product can also create problems. Even worse, sometimes the included code or applications are outside of the organization's direct control, e.g. OpenSSL.
Perhaps then, while in Las Vegas this week, security professionals will discover something - be it a product, or new approach - that will help them get ahead of the problems that their organization's face.