Townsend Security Data Privacy Blog

According to the Identity Theft Resource Center, over 8.49 million files containing personally identifiable information or protected health information (PII or PHI) from 208 separate data breaches have been exposed so far this year. Companies of all sizes and types were victims of breaches, from NASA to a Five Guys Burgers and Fries joint in Schenectady, NY. Other breach victims include utility companies, non-profits, higher education, state-run, and healthcare organizations. On average, a company that experiences a data breach will pay about $200 per record lost in fines (which includes the cost of fraud alerts, credit reports, and other fines). Because organizations most often will lose thousands or millions of records in one breach, these financial penalties can be devastating.

The truth of the matter is this: If you are a company that stores or moves PII or PHI (names, birth dates, addresses, social security numbers, credit card numbers, medical records, etc), you are subject to data protection compliance regulations (PCI DSS, HIPAA/HITECH, FFIEC) and should implement a comprehensive data protection plan that includes AES standard encryption and proper key management. If you’re not sure what constitutes a data breach, read more in our blog Data Breaches Drive Encryption Projects in 2012.

Top data breaches (so far) 2012:

1. New York State Electric & Gas Co.
1.8 million records

2. Global Payments, Inc.
1.5 million payment card numbers

3. California Dept. of Child Support Services
800,000 records

4. Utah Dept. of Technology Services
780,000 medicaid patient files

5. In-Home Support Services, state of California Dept. of Social Services
701,000 records

6. University of Nebraska
654,000 files

7. University of North Carolina-Charlotte
350,000 files

8. Emory Healthcare, Inc.
315,000 records

9. South Carolina Dept. of Health & Human Services
228,435 files

10. Thrift Savings Plan
123,000 federal employee’s data

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

Recent weeks have seen an upsurge in enforcement activity by the FTC around data breaches. That’s right, the Federal Trade Commission. We are used to seeing HIPAA enforcement activity by HHS related to data breaches in the medical segment, and merchants and card processors who experience data breaches of credit card information are penalized by the card brands when they are out of compliance.

But the FTC ???

Clearly the Federal Trade Commission is taking published assertions about data privacy seriously, and is treating violations of published privacy policies as a case of consumer fraud. Or, as they like to put it, “unfair and deceptive” trade practices.  So, if you say you are protecting consumer’s personal information, you had better be doing it. And you had better be using security best practices.

Here is an extract from the June issue of InformationWeek article on a recent action against of Wyndham:

The FTC is suing Wyndham for "unfair and deceptive" practices, owing to promises made in the company's privacy policy, which reads, in part: "We recognize the importance of protecting the privacy of individual-specific (personally identifiable) information collected about guests, callers to our central reservation centers, visitors to our Web sites, and members participating in our Loyalty Program." According to the FTC, "the case against Wyndham is part of the FTC's ongoing efforts to make sure that companies live up to the promises they make about privacy and data security."

Wyndham is challenging the action, but they are not alone in being targeted by the FTC. There have been recent actions against a car dealership, credit report resellers, restaurants, and even Google.

We’ve been thinking about the cost of data breaches too narrowly.

We’ve been thinking that only highly regulated industries such as medical and banking were subject to data breach fines. We’ve been thinking that small companies were not likely to see action against them for data breaches. At the last trade show I attended, three people on the same day said to me “We are a small privately held company. The data breach laws don’t apply to us.” 

Sorry, the FTC does not agree with you.

There are a lot of things you need to do to protect customer information. But if you are not encrypting that information, you are exposed to this type of action.

And if you think a little further into what it means to encrypt data, you have to figure out how to protect encryption keys. If you are encrypting the information but are not protecting the encryption key, you are also exposed. Think about it this way: When you leave your house or apartment in the morning, you don’t tape your key to the door. So why would you store the encryption key on the same server with the protected data? That is not going to pass the sniff test if you have a data loss.

Here is one last thought: The FTC doesn’t like to have to solve the same problem twice. Typical settlements of FTC actions include many years of mandatory and expensive audits. I’ve heard the business logic that says “If we get caught we will just pay the fine.” Don’t be that guy, life is rarely that simple.  Download our white paper "AES Encryption and Related Concepts" to learn about encryption and key management best practices that can help keep your data safe.

Patrick

LinkedIn recently experienced a data breach that exposed over 6.5 million hash passwords. This also recently happened to eHarmony and Last.fm.  All three of these are notable Internet organizations, so it makes you wonder what they were doing wrong in terms of password security.

We live in a world now where we assume that all major Internet sites use the most up-to-date technologies. However, the truth is that often, they don’t. I sat down with Patrick Townsend, founder & CEO of Townsend Security to discuss how online organizations can prevent a password data breach from happening to them. Here’s what he had to say:

Let’s take a look at an overview of how this probably happened. First, like many websites, you access LinkedIn by providing a user ID—typically an email address—and password. In almost all cases the actual password is not stored in the clear. Instead, websites such as LinkedIn store the passwords as cryptographic hash values. When you log in, LinkedIn creates of hash of your typed password and compares it to the stored hash. If it’s the same you’ve entered the right password, if it’s different then it isn’t the correct password and you’ll get prompted to enter it again. The most important part of this process is protecting the hashed passwords, which apparently LinkedIn was either not doing or doing poorly. When the hashed passwords were stolen and posted, it left them vulnerable to being attacked and exposing the original passwords.

Hash cryptography is a continually evolving technology and stronger versions are always on the horizon. Cryptographers are always working hard to understand how to make more secure one-way hashes. If it’s done properly, hashing is practically impossible to reverse and uncover the passwords. However, there are a lot of ways to do hashing improperly, and there are a lot of weak hashing methods out there. There are two important ways to make sure you always use the most secure hashing technology:

1. Don’t use outdated hashing algorithms.
Examples of older hash algorithms are MD5 and SHA-1. SHA-1 was the technology apparently used at LinkedIn. Today you should never use either of those. You can use the newer versions of secure hash algorithms SHA-256 or SHA-512, but you should definitely not use known weak hash algorithms such as MD5 or SHA-1.

2. Use Salts
In cryptography, a salt strengthens the end result of one-way hashes. If you are hashing small amounts of data like a password or credit card number, using a salt is critical to prevent a “dictionary” or “brute-force” attack.

These two factors are considered security best practices using hashes, and ensure that you won’t end up with a weak implementation of a hash value. If LinkedIn had used these practices they would be in a much better security position than they are in today. Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about the LinkedIn breach and ways you can keep a similar breach from happening to your organization.

In the wake of the recent LinkedIn password breach where LinkedIn lost control of over six million passwords, the question of how Internet sites securely store log-in passwords has come into global focus. I recently sat down with Patrick Townsend, founder & CEO of Townsend Security to discuss security best practices for creating hash value passwords:

1. Use only an up-to-date hash method
Because computers have become stronger, faster, and more powerful over the past decade, some of the older hash methods should no longer be used. MD5 and SHA-1 are two outdated hash algorithms that are considered no longer secure. Unfortunately, LinkedIn was using SHA-1 and a poor implementation method, which is what most likely led to their data breach. The newer hash algorithms, SHA-256 and SHA-512 are up-to-date and considered much more secure.

2. Use a hash based on industry standards
The National Institute of Standards and Technology (NIST) publishes standards of hash algorithms. The SHA-2 family of hash algorithms (which includes SHA-256 and SHA-512) is published by NIST as a standard. The goal at NIST is to keep track of hash standards, test and review hashes on a regular basis, and know when it’s time to update them. As hash algorithms become weak and outdated, NIST will withdraw recommendation of those hashes and publish the most secure and up-to-date algorithms. Sites using hashes should always use the most up-to-date hash standards.

3. Use Salts
In hash algorithms, a salt is a critical piece of data that is particularly crucial in Internet applications. A salt strengthens the end result of one-way hashes. If you are hashing small amounts of data like a password or credit card number, using a salt is critical to prevent a “dictionary” or “brute-force” attack.

Ultimately, it is not enough for an Internet site to enforce the use of strong passwords. The problem with thinking that most people will choose strong passwords was revealed with the LinkedIn breach where we saw that too many people were using passwords like “linkedin” and “123456”. Even if a site forces a user to create a strong password by requiring certain length or characters, passwords can still be hacked attacked if they are not protected with a proper hashing method or encryption. These methods should always be employed using hashing best practices. Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about this breach and ways you can keep a similar breach from happening to your organization.

The loss of passwords by LinkedIn, eHarmony, and Last.FM should be a wakeup call for CIOs, security auditors, and IT security professionals everywhere. Let’s take a look at what probably happened, what you can do, and why you need to look beyond passwords on your own systems.

One-way hashes are used in many places in your applications for data protection, data verification, and integrity checking. It is one of those fundamental building blocks of security. There are standards for hash algorithms and conscientious security professionals will be sure that a system uses industry standard hash methods such as those recommended by the National Institute of Standards and Technology (NIST). The Secure Hash Algorithm (SHA) is one of those standards and is readily available in a variety of open source and commercial applications (we have one). It is a common practice to save passwords as hashes rather than saving the password in the clear or encrypted. (You could, of course, protect passwords with encryption and good key management, but that is a discussion for another day).

LinkedIn was using SHA-1 for their password hash. So what went wrong?

First, SHA-1 is no longer recommended for use in security systems. It has been replaced by a new family of stronger and more secure SHA methods with names like SHA-256, SHA-512, and so forth. These newer hash methods provide better protection from the type of attack that LinkedIn experienced. We use SHA-256 or strong methods in all of our applications. So using an older, weaker algorithm that is no longer recommended was the first problem.

Second, it is considered a security best practice to use a Salt value with any data that you are protecting with a hash method. What is Salt? In the context of hashes a Salt value is just some additional data that you add to the sensitive data you want to protect (a password in this case) to make it harder for an attacker to use a brute force attack to recover information. LinkedIn was not using a Salt value with passwords, and more simple passwords were easily recovered. (More on Salt in a moment). The attackers easily recovered LinkedIn passwords.

LinkedIn has apparently taken some steps to better protect their passwords. Is it enough? Let’s look at what should be done. This will help you look at your own Web and IT systems and understand where you have weaknesses.

These are all common recommendations from the security community:

Recommendation 1 – Use industry standard, strong hash methods

You should be using SHA-256 or SHA-512 for this type of data protection.  Do not use weaker versions of the SHA hash method, and do not use older methods like MD5. Do not be swayed by arguments that hash methods consume too much CPU power – just ask LinkedIn if that is their concern right now!

Recommendation 2 – Use NIST certified hash software libraries

If you use a hash method to protect sensitive data, you should use a NIST-certified software library. Why? Because it is terribly easy to make mistakes in the software implementation of a SHA hash method.  NIST certification is not a guarantee, but in my mind it is a minimum requirement that you should expect. I find it curious that most people would not consider buying a used car without a CARFAX report, but completely ignore NIST certification when deploying hash software to protect sensitive data. A lot more is at stake, and you don’t even have to pay to verify certification!

Recommendation 3 – Always use Salt with your hash

Always use a Salt value when creating a hash of sensitive data. This is particularly important if the sensitive data is short like a password, social security number, or credit card. A Salt value can make it much more difficult to attack the hashed value and recover the original data.

Recommendation 4 – Use a strong Salt value

Never use a weak Salt value when creating a hash. For example, don’t use a birth date, name, or other information that might be easy to guess, or discover from other sources (attackers are great data aggregators!). I recommend using a random number generated by a cryptographically secure software library or HSM. It should be at least 4 bytes in length, and preferably 8 bytes or longer.

Recommendation 5 – Protect the Salt value

Protect the Salt value as you would any sensitive cryptographic material. Never store the Salt in the clear on the same system with the sensitive data.  For the Salt value, consider using a strong encryption key stored on a key management system that is itself NIST certified to the FIPS 140-2 standard.

Are your systems at risk?

You are probably using hash methods in many places in your own applications. Here are some thoughts on where you can start looking to uncover potential problems with hash implementations:

• Passwords (obviously)
• Encryption key management
• System logs
• Tokenization solutions
• VPNs
• Web and web service applications
• Messaging and IPC mechanisms

Hopefully this will give you some ideas on what questions to ask, what to look for, and where to look for possible problems on your own systems. You don’t want to be the next LinkedIn, eHarmony, or Last.FM. They are not having fun right now! 

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

Patrick

It is common knowledge in the IT world that the threat of a data breach is now greater than any other time in the history of technology. Since late 2007, the amount of personal information that has been exposed through data breaches is alarming. According to the Identity Theft Resource Center, over 30 million Americans have been victims of data breaches. This is not withstanding the fact that these statistics only count breaches that have been reported.

However, this problem is not unique to the United States. No business organization is immune to risk no matter its size and regardless of the industry or location. Governments all over the world have instituted laws and regulations aimed at protecting the privacy of its citizens. Businesses have now realized the importance of keeping their sensitive data (PCI DSS, HIPAA, SOX, FFIEC) safe and secure. They have come to realize that protecting their sensitive and critical data protects not only their reputation and profitability, but also aids business objectives. Storing and moving unencrypted sensitive data means taking risks that may result in brand damage, loss of customers, heavy litigation expenses, and possibly millions of dollars in fines. These are some of the dilemmas that an organization would not want to find itself needing to mitigate.

Encryption and key management are a critical part of the solution.

Data encryption is now the primary control helping organizations meet security standards and comply with regulatory guidelines such as the PCI DSS, HIPAA, SOX, and GLBA/FFIEC.

What factors and threats drive companies to use encryption key management to mitigate their risk of a data breach?

• An increase in the amount of sensitive data being stored
• Risk of data loss by employees mishandling data
• Increased sharing of authorized data with external users
• Emerging markets for stolen data
• Stringent regulatory requirements

Current NIST standards have rendered old security technologies ineffective in dealing with IT security risks. Effective encryption key management protects your customers data from potential threat. Encryption will help:

• Protect your data and sensitive information regardless of the location
• Meet compliance and regulatory requirements and therefore pass your audits
• Protect your business, avoid brand damage and  increase profitability

If your business wishes to protect its information from all the above risks, data encryption is necessary to achieve your data security goals and objectives.

Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.

In a highly digitized environment, identity theft poses a great risk if the necessary safeguards are not utilized. It is paramount that businesses and consumers are made aware of the massive repercussions a data breach of patient info can result in--such as identity theft of patients, as well as financial damage to and reputation loss of healthcare organizations. Current HIPAA regulations mandate that if a data breach occurs, then the organization responsible for that breach must reported it to Health and Human Services (HHS), pay thousands or millions of dollars in fines, and may have to report the breach to the media.  However, if your organization’s data is securely encrypted, you will be exempt from these repercussions.

Despite Health Insurance Portability and Accountability Act (HIPAA) security laws, healthcare data breaches are on the rise. According to the Ponemon Institute, the healthcare industry has lost more than $6.5 billion dollars due to data breaches.

Ponemon also identifies the three most common culprits of healthcare data breaches: stolen or lost equipment, third-party mistakes, and employee errors, indicating that many data breaches stem from unintentional mistakes. Storing health information on mobile devices is also a common practice among health care organizations. However, 49% of the respondents reportedly do not take any steps to secure patients' information on those devices.

A great example of an accidental data breach recently took place in South Carolina where a Medicaid employee transferred several spreadsheets of sensitive patient data to a personal email account. This kind of data breach could have exposed hundreds of thousands of patients to possible theft of Social Security numbers, Medicaid ID numbers, addresses, phone numbers, and birthdates.

Another alarming example took place at an Emory Healthcare storage facility where 10 back-up disks for an old computer were found missing. These disks contained protected health information (PHI) of more than 300,000 patients including patients' names, doctors' names, diagnoses, medical procedures and other privileged information protected under HIPAA.

As healthcare organizations face greater challenges in protecting massive amounts of patient data, the US federal government continues to strengthen security laws, regulations, and best practices. Due to the HITECH act of 2009, HIPAA compliances now requires more stringent steps to ensure full security of patient information.

As the CTO, IT Manger or System Administrator of your healthcare company, you have a critical task to accomplish. You cannot afford to waste time and money on legal battles that you can avoid in the first place. If you do experience a data breach, the emotional toll on your patients could result in lost clients and a tarnished company image.

Here is the good news: NIST-certified encryption and FIPS 140-2 certified encryption key management is at your fingertips!  Townsend Security’s encryption solutions offer affordable possibilities that will fully protect your patients' records and allow you to avoid a breach notification in accordance with HIPAA/HITECH. You need a security technology with a strong encryption solution that is NIST certified and suitable to your server environment. If data is securely encrypted, data breaches don’t need to be reported and you and your patients are assured peace of mind.

For more information, download our podcast "Protect PHI and Manage Risk - HIPAA Compliance" and learn more about achieving Safe-Harbor status in the event of a breach and what is considered a data breach.  Additionally, learn what to be aware of when selecting an encryption or key management solution.

I found the data breach of Epsilon just shocking for several reasons:

First, the scope of the breach was astounding. About 2,500 companies are using Epsilon for email communications with their customers, and some of these companies are quite large. Thus the number of email addresses exposed was gigantic. You really have to wonder why those email addresses weren’t encrypted. Anyone would see those email addresses as a high value target. And email addresses are Personally Identifiable Information (PII), after all.

Second, you have to wonder why really large companies trusted Epsilon with their customer information without insisting on good data protection practices.  What were they thinking? When you hand over your data to an outside company, you aren’t off the hook if there is a data loss.  It wasn’t Epsilon who had to send emails and letters to customers. The originating companies bear the cost of that effort, and the business damage that follows.

Third, the loss of an email address is not trivial. It’s true that email addresses are more public than many bits of personal information we have. But email addresses are often used as account identifiers for on-line services. If I have your account ID it is a lot easier to attack your password credential. People are amazing lax about creating strong passwords. So the loss of emails provides one more weak link in the chain of security for individuals.

Then there are the phishing attacks. If I have your email address it is a lot easier to send you an infected PDF file. I just look on your company’s web site or Facebook page and find the name of your CEO. Then I send you an email with the CEO’s name and an infected PDF. Perhaps I name the PDF “Look at these terrible results!.pdf”. You are probably going to jump to open that one!  So now I have invaded your internal network.

You can see how this can really escalate to bad news for you and your organization.

The lesson for any organization is to do some due diligence with your service providers. Be sure they are protecting your information with the same level of care that you do. After all, you are on the hook if they lose your data.  For more information, download our white paper titled AES encryption and Related Concepts.