Listen to or download the 9:07 minute podcast below:
What follows is the transcript of my podcast with Sanjay Mehta, Senior Vice President of Sales and Marketing for Breach Security, where we discuss the ValueClick data breach, what happened, how it was the result of a corporate takeover, and how takeovers often results in unsecure, 'orphaned' applications.
Can you give me a general overview of the ValueClick security breach?
Sure. There were three main components in that breach. The first was just a simple violation of the CAN-SPAM Act, essentially centered around deceptive emails. The folks at ValueClick were passing out emails that were touting free gifts, pretty high dollar items like iPods or laptops. When consumers clicked through those ads to go to the websites to claim their free prizes, they were assaulted, if you will, with a large number of extra steps to go through including solicitation of paid for goods.
So that was the first area, and the area that the TFTC was originally tipped off on. The next was non-standard encryption. So they're very well known standards for protecting sensitive information with encryption today. ValueClick was using something that is essentially was just a customer built character substitution. So if you watch any modern day movies where people are hunting treasure maps and trying to substitute characters, they were using a fairly similar method.
It doesn't really encrypt the data, it just obscures it and anybody with even moderate skills can essentially translate that back and get the clear text data, so that was the second area. And then the third one was they were vulnerable to a very common type of application specific attack called the "SQL injection" where essentially somebody with malicious intent can put in certain character sets, if you will, to dump information out of a database or other data store.
Was ValueClick following acceptable security practices?
No, they really weren't. So the spam thing is really a different issue, right. They are well known pieces of legislation on how companies can email solicit their customers, and they need to identify who they are, and the email address itself needs to be legit, and the physical address needs to be included so people know they're dealing with a legit business so they made violations on that.
On the security front, the two areas, again, were the weak encryption and the SQL injection. So the application security phenomenon is, in general, new. It's only been out two or three years in terms of real customer adoption. It's been a topic of media and press on data leakage over a similar period of time, but more and more folks are rolling web apps out. So there are very commonly known industry bodies, if you will, where you can go get information on how to live up to best practices.
The most commonly referenced one is something called "OWAS", the Open Web Application Security Project. And that gives the top ten things you need to be concerned about and things you need to do if you're doing business on the web, two of those being SQL injection protection and encryption, and ValueClick came up short on both of those accounts.
So looking back, what should VauleClick have done to prevent this from happening?
A few things. Part of their challenge is something that a lot of companies face today, which is the application in question was one that they acquired from E-Babylon. So in today's world where we're all geared up for high competiveness and rapid growth, acquisition is a pretty typical growth strategy. When ValueClick acquires somebody or even "Bank A" acquires "Bank B", you inherit a bunch of applications that you know very little about.
And as part of that competitiveness aspect to streamline the business, you let a bunch of people go. So these applications get inherited and then they're what I called "orphaned", right. The people who wrote the applications, the people who were previously responsible for securing the applications are no longer with the company, the applications are mission critical, they're driving business and they need to stay online.
So now, you have new folks responsible for securing these things that they know nothing about. ValueClick was essentially a victim of that phenomenon where they brought over these apps from E-Babylon, they had poor encryption, they had susceptibility to very common vulnerabilities, and they needed to keep it online.
So what they should've done is sat down and gone through a comprehensive review of how that application's protected, what it was, how often it changed, what its business features were, etc, and then deployed some sort of defense in-depth approach to secure the application. They're -- an application security, there's no silver bullet, it's no different than network security.
You need a defense in-depth approach that starts with training your developers how to write securely, reviewing that throughout the development process to make sure code is being written in a secure fashion according to your corporate standards and industry best practices.
And then, once in production, making sure that you have the tools and techniques in place to detect the changes to the application and how that might be introducing new vulnerabilities. And also, just understanding what's going on in the outside world and who's targeting your application and your corporate data.
Now, with the FTC fine against ValueClick, what do companies need to know about complying with the government security requirements?
In the world of payment, in the world of web transactions, it's actually much broader than just the FTC. So the government certainly has legislation around this and there's certainly some precedent around fines. The more prominent movement is actually sponsored by the major card brands, and that's PCI, the Payment Card Industry Initiative and they have something called the "Data Security Standard".
And essentially, everybody's pointing back to the same thing. So pointing back to something like the OWAS, that I referenced, at owasp.org, and complying with best practices to security web applications. Everybody's looking at the same standards so it's not hard for a merchant or anybody else doing business on the web to comply with multiple standards regardless of where they're coming from as long as they do [0:05:43] best practices.
So the fines with PCI have been pretty severe. Companies are violating that, they're getting fined $30,000 a month, they rates on credit card transactions are going up, and in the worst case, you're actually getting dropped so you can't take cards anymore. So whether it's a FTC fine that could result in millions of dollars of various things or actually losing your business, companies need to step up and protect their web applications the same way they protect their networks.
What part does your company, Breach Security, play in this process?
Yeah, Breach Security is squarely focused on the solving the problem of web applications security. So if you think of a network, networks are by and large static. Company to company, you have border routers, firewall, switches, load balancers, etc. And if somebody wants to attack a network, they attack it in roughly the exact same way.
So if you think back to five, six, seven years ago when all heard about the SQL Slammers, and the Blasters, and the NIMDAs, and the Code Reds, they were very wide spread mass propagating worms designed to wreak havoc across lots of networks simultaneously. If you think about the web application security world, every web app is unique. So instead of ValueClick, for instance, they've grown through acquisition.
Let's say they have a 100 applications, for the sake of argument, each of those applications, even if built on a common framework of tools, has a unique purpose in the way an end user interacts with it is different. So to protect that web application, you need to understand its unique intricacies if you will.
So Breach Security focuses on delivering a suite of web application security solutions that not only have great detection of what's going on from the outside world, right. Who's trying to attack you? What vectors are they taking? But also understanding how the application itself works so you can protect it in the best way, and also complete the lifecycle so security folks can have cogent conversations with application developers about actual flaws not theoretical vulnerabilities so code can be secured at the core.
Now, so what do you see for the future then of application security?
Yeah, I think to broaden the question a little bit, folks are finally starting to look at security a little differently. Historically, we've looked at stovepipes of technology. So we've said, oh, we need a firewall. Oh, we need intrusion detection. Oh, I'd like to consolidate my data path a little bit so I'm going to jam all these various things into some sort of UTM device or a switch. But applications are bringing a whole business context into it, which is I need to do business on the web for the following reasons.
And to do that, I need to enable certain classes of users to do certain things. I need end users or consumers to come in. I need my extranet business partners to come in. I need my inside guys to come and access the web applications, all for different purposes. So I need different authentication routines. I need different authorization routines. And then once people come within those gates of authorization, I need to make sure that they're only doing what they're allowed to do.
So in web application, development, and production apps, people are taking a different look at the problem, which is what's the core value here I need to deliver and then how do I secure that entire value chain from start to finish across my various constituencies? So I think that the market's going to start consolidating, if you will, around a different mindset which is; it's not all about jamming more stuff into a network, it's about finding a business problem and then making sure that you can deliver secure access for that business problem and the easiest way.
Leave a comment