Epsilon Security Breach

Since my last post on the Epsilon Security Breach, the impact of the Epsilon security breach has gotten bigger. In fact, in an article posted on Yahoo news, a Reuters news writer stated:

In what could be one of the biggest such breaches in U.S. history, a diverse swath of companies that did business with Epsilon stepped forward over the weekend to warn customers some of their electronic information could have been exposed.

So the breach has grown since it was first announced last week. I wonder if this will get bigger  since the same article goes on to say:

“While we are cooperating with authorities and doing a thorough investigation, we cannot say anything else,” said Epsilon spokeswoman Jessica Simon. “We can’t confirm any impacted or non-impacted clients, or provide a list (of companies) at this point in time.”

The problem for Epsilon seems to keep growing. As developers, we need to remember this because the last thing any of us want is to the be developer responsible for letting the hackers in.

Security Has to Be Job #1

It’s been a busy week for security administrators. First, the Lizamoon attack last week. Then, data was stolen from Epsilon.

LizaMoon Attack

I first started reading about Lizamoon last Friday (4/1/2011). I was wondering if it was an April Fool’s joke but quickly discovered it was not. Depending upon what estimates you read, Lizamoon infected between 100,000 and more than 1,000,000 pages. In my opinion, the worst part of this attack is that it should have been prevented.

According to WebSense:

We were able to find more information about the SQL Injection itself (thanks Peter) and the command is par for the course when it comes to SQL Injections.

While the attackers did escape many of the characters to make it difficult to decipher what they were doing, SQL injection attacks are easy to prevent:

1. Run your web application under an id with limited privileges.
2. Use parameters in all SQL statements. This alone would have prevented this attack.

I found this attack disappointing. I remember reading about SQL injection attacks more than 5 years ago along with how to prevent them. How can we have come so far as an industry but still have so far yet to go?

Epsilon Attack

Sometime last week, Epsilon was attacked and had data stolen. I first heard about this when I received an email from BestBuy Reward Zone which included:

On March 31, we were informed by Epsilon, a company we use to send emails to our customers, that files containing the email addresses of some Best Buy customers were accessed without authorization.

We have been assured by Epsilon that the only information that may have been obtained was your email address and that the accessed files did not include any other information. A rigorous assessment by Epsilon determined that no other information is at risk. We are actively investigating to confirm this.

I received a similar email from Chase today. And, according to Engadget, more companies than these two had their data stolen:

A rigorous investigation has concluded that no other personal data was exposed, however it’s not just TiVo that’s affected — other big names, such as JPMorgan Chase, Citi, US Bank, Kroger, and Walgreens have also seen their users’ deets dished out to the unidentified intruder.

The good news is that only names and email addresses were stolen; there was no information stolen that would lead to monetary or identify theft.

But think about what this will do to Epsilon itself. They haven’t published how the hackers got in and stole the data and I could argue that they shouldn’t.

But hackers did break into their systems and steal data. They had to issue a press release stating as much. And, the impacted companies are blaming Epsilon for the security breach as they should. I wonder how much this will hurt Epsilon’s reputation and market share.

So, What’s Next?

The Lizamoon attack was caused by developers not accounting for SQL injection attacks in their code.

We don’t know what was the underlying cause of the Epsilon attack. From the press release and the apology emails being sent out, I think it’s safe to assume it was an exploit as opposed to a social engineering attack. That means it was probably either a developer-created security hole or operations falling behind on patching servers (or both).

So how do we prevent these types of attacks?

First, I think we as developers need to take more ownership of these types of problems and do more to prevent them. The problem with this is that we’ve heard this all before. And many of us do take ownership and work hard to insure our code doesn’t have any exploits. But a lot of us don’t.

Second, we need to educate our management so that security gets taken seriously. If we do find an exploit in existing code, fixing that exploit has to be a top priority. I bet that isn’t always the case. The problem is the risk and that is, I believe, the key to getting management to increase the priority of fixing exploits; by talking about what would happen if the exploit is found.

Third, we need better tools to help us determine if our websites are secure. Most of the tools that I’m aware of do code analysis and are looking for exploits within our code. That doesn’t help us in these cases because the exploits are in how our web site is working and not in how our code is working. Hopefully some good tools will come along shortly and will help us in this area.