Townsend Security Data Privacy Blog

Over 8 Million Passwords Hacked? It Happened in Europe.

Posted by Adam Kleinerman on Aug 6, 2012 8:12:00 AM

data privacyCyber hackers have repeatedly victimized US businesses, resulting in a widespread movement to increase cyber security in many US organizations. Due to this influx of security, hackers have recently turned to European companies in an effort to attack weaker targets. The most recent target, Gamigo—a German gaming company—was breached resulting in the loss of over eight million user names passwords. The breach was first reported by data breach watchdog service PwnedList.com, which has been vigilant in informing the public of particular breaches. Due to the great number of accounts hacked, some are referring to this particular breach as a world record. PwnedList’s founder Steve Thomas remarked, “It’s the largest data breach I’ve ever actually seen.”

Gamigo is currently going through the motions of damage control by offering reassurance to its customers. In fact, Gamigo automatically reset its users passwords immediately after the hack was discovered. However, the real danger to Gamigo’s clientele lies in the fact that so many people use a single password for many different websites. The password a person used on Gamigo could be the same password they use for their email or bank account. Even more concerning is that this sort of password breach (e.g. LinkedIn) has revealed that many people use extremely weak passwords such as “password” and “123456”.

Another blow is that Gamigo may ultimately lose is its clients and its client’s trust. Should Gamigo sustain any financial penalties from European security standards organizations, the losses it could experience may not be easily absorbed.

The recent data breaches of LinkedIn, eHarmony, and Last.FM may not have been well publicized overseas, but the Gamigo breach should put all European companies on full alert. Organizations asking for user names and passwords should always use the most up-to-date hashing technology and require stronger passwords. It is also not enough for a company to require strong passwords if their users’ personal information is stored on a database. If sensitive information is being stored on hardware, AES standard encryption and key management must be implemented. To learn how to protect your sensitive stored data, read our blog on how to protect databases that contain email addresses and passwords.

Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about Patrick’s take on the LinkedIn data breach and ways you can keep this from happening to your organization.

Click me

Topics: Data Privacy, Security News, Security Attacks

TRICARE: Encryption Could Have Saved the Day

Posted by Adam Kleinerman on Apr 30, 2012 10:44:00 AM

Breach Notification Safe-Harbor

PCI Compliance White Paper

Download the white paper "Achieve Safe-Harbor Status from HITECH Act Breach Notification" to learn more about encyption and key management best practices.

Click Here to Download Now

An alarming number of security breaches have occurred in the last decade victimizing families of military personnel, who belong to TRICARE. Since the fall of 2009, over 400 breaches have occurred. At least 500 people have been directly affected and another 50,000 smaller scale breaches have been reported to the government. The community of Palo Alto, California was hit closest to home, when over 20,000 names of emergency room patients were available on an online public forum before the list was discovered by authorities. For several months, all these people were susceptible to a profusion of afflictions such as identity theft, credit card fraud or fraud against Medicare and Medicaid programs. Just one move can financially ruin a family.

One major cause of the breach was that security tapes were stolen from the car of a TRICARE employee, and these backup tapes had people’s private information on them. The big problem of course, was that after these tapes were stolen, the information was readily available to pirates. Any encryption didn’t exist, so the information was just there for the taking.  If the data on these tapes was encrypted, TRICARE wouldn’t have to worry about the tapes being stolen and you wouldn’t be hearing about this problem – HIPAA grants a breach notification safe harbor to organizations who are encrypting their sensitive data.

If you aren’t familiar with HIPAA (The Health Insurance Portability and Accountability Act), it was established in 1996 and its main focus is to protect the rights to health insurance for families when the wage earner was to change or lose a job. It’s second objective focuses on standards for electronic health care transactions. With HIPAA, there are legal regulations that the government has put in place to protect our Personal Health Information (PHI).  While there is no encryption requirement, it is strongly considered a best practice.

The largest concern when a story like this breaks is for the victims. The Federal Trade Commission (FTC) has published a few tips for individuals who are affected from the TRICARE breach:

  • Don’t willingly give out personal information over the phone unless you know exactly whom you are dealing with.
  • Increase the frequency at which you check over your medical records to make sure nothing looks out of the ordinary.
  • Any fraudulent report you notice should be reported to the police immediately.

The TRICARE breach should be an example of why encryption should be mandatory for organizations that deal with PHI.  Not only does it protect the privacy of your customers, when a breach does happen, HIPAA grants you a breach notification safe harbor.

Learn more about encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Click me

Topics: Encryption, Data Privacy, Security News, Security Attacks

Could Encryption Have Stopped Stuxnet?

Posted by Adam Kleinerman on Mar 22, 2012 10:26:00 AM

computer wormIn June 2010, a computer worm called “Stuxnet” made worldwide news when it infiltrated Iranian science labs. Many of Iran’s industrial facilities including Natanz, were seriously harmed as a result of this worm. Uranium enrichment is a project that many global nuclear outfits are working on. The idea is to create a higher concentration of the Uranium isotope U-238 to make for a more reactive metal. The source codes for all of these machines are stored on computers, so they are run by what the computers are instructing them to do. When the bug hit, the sophisticated centrifuges began spinning too fast causing the machines to self-destruct.

The dials and gauges looked like they were functioning correctly, so the Iranian officials knew that an external virus or bug must have invaded their computer, with the specific instructions to destroy their appliances. After investigation, it was discovered that it wasn’t a virus, but a worm. A virus will corrupt individual files on a computer, but a worm is malicious software that spreads through a computer network. For a computer to avoid contracting a bug, computer security is paramount.

Having proper encryption and key management possibly could have prevented a disaster like this from happening. It really shouldn’t have had a chance. The Iranian government was running programs that needed the highest level of security and they could have done more to prevent this from happening.

We help our customers deal with security issues all the time. Alliance Key Manager, our encryption key management Hardware Security Module (HSM), has built-in encryption and decryption services. With an HSM, the encryption key never leaves the appliance, keeping the encryption key separate from the data it protects. By using encryption and key management, Iran could have possibly prevented Stuxnet from modifying the source code that caused their servers to self-destruct.

The effects of the Stuxnet worm were devastating for Natanz and other industrial facilities in Iran. Their nuclear projects were setback an estimated four months. This is of course, an extreme case with intended malice toward the government. This worm was specifically designed only to harm Iran’s centrifuges. Ralph Langner, an independent computer security expert and the man who discovered the intent of Stuxnet said, “The attackers took great care to make sure that only their designated targets were hit. It was a marksman’s job.”

 Hopefully, there isn’t a company or organization out there that will feel the need to specifically target your company. But there was some collateral damage to other computers caused by Stuxnet, and encryption and Key Management can prevent the effects or other worms. Take a look at the program!

For more information on encryption and key management, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data.

Click me

Topics: system security, Security Attacks

SQL Security Attacks: Same Ole, Same Ole

Posted by Patrick Townsend on Feb 11, 2011 1:29:00 PM

SQL Security AttacksThe PCI conference is just finishing up and I’ll have more on the conference a bit later when information can be made public. One of the interesting talks was by Chris Novak of Verizon. I just want to recap some of his thoughts.

The number of highly targeted and sophisticated attacks is on the rise. We’ve heard this message over the last few months, and the Verizon study confirms this. A highly targeted attack goes after a specific companies’ assets with a lot of knowledge about the internal systems. The ability of the attacker to cloak the software is good, and the sophistication of the attack is high. These are highly knowledgeable technicians creating the malware, and they are getting good at attacking sophisticated systems like such as Hardware Security Modules (HSMs) that store or process encryption keys. The targets are usually companies with a large concentration of high value financial information. It’s expensive to launch these types of attacks, and the payoff is high. When these breaches are discovered they get a lot of press. But here’s an interesting fact: These sophisticated attacks on specific targets are still in the minority. Over 80 percent of the breaches are pretty low-tech. That’s right, amazingly most of the attacks are against web servers and most of these use SQL injection as the way to get inside. What’s stunning is that we’ve known about SQL Injection attacks for a long time. We know how the attacks are made, we know how to test for the weakness, and we know how to remediate the problem. So why haven’t we made much progress in preventing this exposure?

First, we aren’t paying enough attention to our web sites which are not directly related to credit card process. Novak used the example of an attack on a companies’ HR web site. The company posted job openings on the site and did not think it was much of a target. But attackers gained entry to this job postings web site, and then navigated through the internal network to a high value target.

The lesson? We know what to do, we just need to apply that knowledge more broadly.

We might also ask why are we still having a problem with SQL injection? Novak had an interesting take on this, too. To prevent a SQL injection attack you have to use good programming practices. You can’t just plug in an intrusion detection device and think you are safe. You prevent SQL injection by changing the way you develop web and business applications. Do you know what OWASP is? If not, there’s a good chance you are exposed somewhere in your application code to SQL injection.

The lesson? We have to get much more serious about secure programming. If you are a developer of web or business systems, you should know the OWASP Top 10 forwards and backwards. If you manage a development group, be sure everyone is trained on secure programming practices. Make it a requirement for hiring and promotion.

I will leave you with one more interesting point from Novak’s talk. In almost all breaches that Verizon studied, there was enough information in the system logs to identify the attack, but the logs were not reviewed and the attack went undetected.

The lesson? We need to monitor our system logs a lot better. This means investing in software that can automatically sort through the large number of logs and tell us when there is a problem.

There are positive changes under way at the PCI council and I will discuss these more in the days ahead. But one big take-away is that we need to do better what we already know we should be doing. This part is not rocket science.

Patrick

Topics: HSM, Verizon, SQL, Security Attacks