Hacktivism: The Real Threat
Security Expert Says DDoS Attacks a Gateway to Data TheftDDoS attacks launched by hacktivists are often seen as little more than an interruption in services for an organization. But Terry Ray of Imperva highlights a greater worry hidden behind the attacks.
See Also: Gartner Guide for Digital Forensics and Incident Response
"The reality is [distributed-denial-of-service attacks] are just the front end, if you will, of hacktivism," says Ray, vice president of worldwide security engineering for web application security provider Imperva, in an interview with Information Security Media Group [transcript below].
The first step is the targeted, technical attack against an organization, Ray says, which follows with the hacktivists trying to steal data.
"SQL injection, cross-site scripting, all the other types of attacks that people are familiar with on the web-application side - they try all that," he says.
"The reality is, yes, they absolutely are interested in stealing data," Ray contends.
During this interview, Ray discusses:
- The fundamental security risks to critical data;
- How standard perimeter security is not addressing vulnerable web app risks;
- The real threat to the data hacktivists access during DDoS attacks.
Ray leads Imperva's field, corporate and channel security engineers and has designed and deployed data security solutions for customers in the healthcare, financial services, government and e-commerce sectors. Since 2003, Ray has focused his efforts on data security, working with companies to secure, monitor and audit external and internal activities.
Web App Security: Top Concerns
TRACY KITTEN: You were telling me that there are two specific areas that are concerning when it comes to web application security. What are those?
TERRY RAY: When you talk about the areas of web application security, really there are two primary areas, and those areas tend to be around hacktivism and cybercriminals. If I step back just a little bit, when we think about web applications, the common question I ask customers is, "What is it that your application actually does?" A lot of customers will tell me their applications do a lot of things, whether it's e-commerce, banking or what have you.
The reality is ... the fundamental function of a web application is to be a client to your database, your data. For us, it's about data security, the data that drives your business; the data in your data center; and securing your data. When we talk about the applications, that's what it's really all about, being able to secure those applications from people like hacktivists, which are very common, as well as the cybercriminals.
To give you a couple of percentages here, when we look at the number of attacks that an average web application gets over any particular year, from Incapsula, which is a subsidiary of ours, it's about 4,000 attacks per year on an any given individual application. That's not per organization; that's per application. Organizations have tens to hundreds of applications, so that can be a significant amount of attacks happening in an organization.
The other percentage that's relevant here is a percentage from WhiteHat Security where they said that 86 percent of applications on average have at least one serious vulnerability. When you put those numbers together - 4,000 attacks per year, 86 percent of applications have at least one serious vulnerability - the overwhelming majority of applications that people use today have at least one serious vulnerability and are attacked 4,000 times a year. That's a problem, and it's a problem that can be solved but isn't necessarily being solved by all organizations.
Hacktivism
KITTEN: You've noted hacktivism. How concerning should hacktivism be when it comes to the theft of actual data?
RAY: There's a bit of a misnomer when we think about hacktivism. A lot of people equate hacktivism to DDoS. It's very synonymous. The reality is DDoS is just the front end, if you will, of hacktivism. When organizations that are hacktivists go out and try to attack an organization, step one is to do a targeted technical attack. They try to steal data. SQL injection, cross-site scripting, all the other types of attacks that people are familiar with on the web-application side - they try all that. They use very specific, automated tools to do that. It's a process that we've been able to record, but they always end with DDoS. The reality is, yes, they absolutely are interested in stealing data. They aren't always successful with it, but they do always end with DDoS, which is why they have that front-end DDoS face.
KITTEN: What about the ways that hacktivists are attacking data? We talked a little earlier about Anonymous and some of the different tools that they're using. They don't always have to have a botnet, for instance.
RAY: For me, the most eye-opening thing about the research that we've done with regard to hacktivists is their use of automated web-application-scanning tools. They use a lot of different tools. They use a lot of automation. There's not a lot of by-hand stuff happening here, so they're using a lot of these tools that are available in the marketplace. The tools that they use are tools that, frankly, enterprises use, and I think that's the biggest thing that I took away from this. When we look at the tools that hacktivists use, [they] use web-application vulnerability assessment scanners to scan your application and find where your application has vulnerabilities. Interestingly, enterprises use the exact same tools in many cases that hacktivists are using and vice versa.
What happens is a hacktivist will scan your application, they'll find a vulnerability and they move immediately to being able to exploit that vulnerability. Organizations scan their application, find that they have 50-100 vulnerabilities - whatever those vulnerabilities are - and they then take those vulnerabilities and give them to their app developers. They wait some period of time for the developers to try and fix the application.
Another statistic from WhiteHat is that it takes a little bit over 100 days on average for any developer to fix any particular application vulnerability. The problem with that is there's a major gap between the timed exploit that a hacker has once they find the vulnerability using the same tool and the time that the enterprise has to fix the vulnerability using that same tool.
What we have initially created is called virtual patching, where customers can now integrate web application firewalls and, in particular, Imperva's web application firewall, with the common web application vulnerability assessment tools. When you find your vulnerability, you can give the vulnerability information to your developers for them to fix the application, but at the same time you can use ... the application assessment application feed directly to your web application firewall and immediately start mitigating where you know you have known risk in your web application. Mitigate that risk immediately. The idea is to give organizations the same power to close their holes as attackers have to exploit them.
Vendor Collaboration
KITTEN: Where do you see vendors coming together, and where's the need for more integration, especially where web application security is concerned?
RAY: Specifically with regard to web application security, as I alluded to a moment ago, at Imperva we have a lot of partnerships with the web application vulnerability assessment tools. We work directly with those tools to create that virtual patching solution so that you have that ability to close that time of gap of when you can actually identify the vulnerability and mitigate the vulnerability.
Further than that, we're finding that web-application firewalls need to have additional partnerships. One of the things we have is something called ThreatRadar. ThreatRadar gives us the ability to go out and work with phishing companies: companies that identify people who are trying to phish your website; companies that try to provide information around malicious IP addresses; companies that try to provide information around anonymous IPs, essentially IP reputation. We don't do it ourselves; we work with third parties that feed us the information to our customers that give that information. The idea is to have a solution that protects your application that's contextual. It's not just a point solution that says, "I see something bad and I need to block it." But instead, I have a lot of other elements of information, layers of security, that I can bring to bear that may allow the web-application firewall to make far better decisions about when it's going to block something and when it's not so that it doesn't have to make mistakes like maybe other products have in the past.
Lessons for Asia Pacific
KITTEN: When it comes to web-application security, you mentioned earlier that the market in the U.S. or North America is a little bit more mature when it comes to its understanding and its need for web-app firewalls. What could Asia Pacific learn from its North American counterpart?
RAY: The quick and easiest thing is the problem of hacktivism. The problem of cybercrime is not a localized problem. It's really a global problem. A credit card that you steal in the United States is just as good as a credit card that you steal in India, for example. Just recently, the $45 million stolen from banks due to a breach in Indian banks that allowed people to change the credit limit on credit cards - that's a problem. That wasn't an American problem. They stole the money from American ATMs and other ATMs around the world. The reality is that a credit card is a credit card. It's not a big bank problem. It's not a small bank problem. It's everybody who takes credit cards that has that data; they're all just as good as anyone else's. It's mom-and-pop shops on up to the big boys.
Credit cards aren't the only problem. I have a lot of people that come to me and say, "I don't have any private data." I ask them, "Do you have user names and passwords?" They say, "We do." I say, "Well I can't speak for myself, but my parents aren't that technical necessarily, so at the end of the day their user names and passwords tend to be used on more than one website. Their user names and passwords are private data, and if I can steal their user name and password and try it on their banking accounts, there's a chance that might actually work, even though I stole it only from Hotmail or from Facebook or somewhere else."
Private data is only relative to the people that are using it. It may not be sensitive to the company that's holding it, but it may very well be usable for people that steal it and they can use it in a lot of very different interesting ways.
Role of Privacy Laws
KITTEN: I did also want to ask about the role that privacy laws are playing in some of these differing markets.
RAY: Privacy laws are one of the major drivers in the United States that really gave us a head start in terms of the market for web-application security. In the United States, you've got PCI, Sarbanes-Oxley, HIPAA and a lot of other different kinds of regulations that we had. They aren't necessarily shared throughout the rest of the world. EMEA has some now. You see APJ starting to have privacy laws in Australia, Korea, Japan, and Hong Kong and throughout.
Now we're starting to see this ramp up. We have private data too. There needs to be some level of regulation because, without it, organizations may not have the true driver to really secure that data. Some organizations do it because they've been hacked. It's responsive rather than proactive. We do see that out here. The reality is compliance absolutely is a driver in terms of web-application security, and we're seeing a major uptick in Asia now with some of those drivers coming to fruition.
The Need for Web App Security
KITTEN: Before we close, how often are you asked by clients about the need for web-application security and a web-application firewall?
RAY: We get that question a lot. The question quite frequently is around the solutions that organizations have already deployed around their perimeter: their traditional network-security solutions; their next-generation firewalls; even anti-virus to some degree. The reality is that those solutions just simply solve the problem of web-application security. While I could go on for hours and talk about the individual reasons why, the reality is that they're perimeter solutions and they all need to allow, for business purposes, access to your web infrastructure. That's what your web infrastructure is all about. It's usually the customer-facing face of the organization. You have to allow people to access that. It's very difficult for these other organizations to allow all access to that, yet at the same time prevent all access to those structures.
At the same time, most of the access that we're now starting to see tends to be more ciphertext. There's more encrypted data that's happening there, and most of the traditional solutions that are out in your perimeter simply don't de-crypt the SSL traffic. Even if they did, you have to look at those solutions and say, "Do these solutions know anything about my web application?" The reality is they really don't. They may know some level or some types of SQL injection at a very high-level way, but we're seeing the SQL injection; we're seeing cross-site scripting. They're obfuscated in such ways that you really can't detect them unless you really have an understanding of the individual application and how that application works. And until solutions that are at the perimeter really understand the applications, understand the cookies and all of the other elements that are relevant to applications, they don't really stand a chance to secure that.
I think the bigger factor is we've seen this question so frequently that we've actually created a tool called the web application testing framework tool. This tool's specific purpose is to help organizations answer the question of, "I have security in my environment right now. I have firewalls, IDS and IPS. Why isn't this solving my problem?" It allows you to run traffic through your environment and not just test your solutions on whether or not they detect all the bad traffic, but also test them on how much of the good traffic that you actually block as well. I ask my customers, "If your solution blocks good traffic, what do you do?" The answer is, "I turn it off." It may be an exclusion rule or you effectively start to lower the element of security that's available there. That's the problem we see with applications. They're so complex that, even the solutions that claim to be able to do application security without all the contextual partnerships that we've talked about here and the ability to understand the application, they really stand no hope of being able to provide security without creating the false-positives that limit them in their ability to really be effective in an environment.