Townsend Security Data Privacy Blog

We’ve seen some high profile data breaches at colleges and universities lately. People have been asking if there is any reason why these organizations are experiencing a higher level of attack, and why this is happening now. Are they more susceptible in some way?

There is some good evidence that higher education institutions are experiencing data breaches at a higher rate than other organizations.  Just based on the reported number of reported breaches, number of records stolen, and the number of colleges in the general population of targets, you can conclude that they are, in fact, experiencing a higher rate of loss.

Are college students responsible for the higher levels of breaches?

In spite of the fact that college students are far more knowledgeable about technology, and have a high curiosity index, there is no evidence that students are the source of these breaches. If you look at insider threats and include students in this category, the data doesn’t support this idea. And students don’t want to put their academic opportunities on the line over a break-in, they are way too smart to put that much at risk.

So, why are colleges experiencing higher rates of loss?

Asked why he robbed banks, Willie Sutton supposedly said “Because that’s where the money is.”  A typical college runs retail operations through book stores and cafes, collects critical financial information about students and their families, and may operate a student health service. They are complex modern operations with very large amounts of sensitive data that is often retained for many years. I believe that colleges and universities are considered high value targets because they have a lot of valuable information. 

Here are some things that higher education organizations can do right away:

1) Know where your sensitive data lives.

You should have a good inventory of all of the systems that collect and store credit card numbers, social security numbers, financial information, and student patient information. Having a good map of your data assets is crucial to your data protection strategy.

2) Purge the data you no longer need.

We sometimes forget to take out the trash in our IT systems, and that historical data can be the target of a data breach. Now that you know where your data lives, purge the historical data that you don’t need.

3) Prioritize your attack plan.

We all tend to do the easy things first. There is some satisfaction in getting some points on the score board early in the game. Resist this tendency and protect the most valuable assets first.

4) Protect your data with strong encryption and key management.

There is a lingering belief that encryption is difficult and expensive, especially when it comes to encryption key management systems. That is no longer true! Be sure to include encryption and proper key management in your data protection strategy. If front-line defenses fail, and they will, be sure that the data that is stolen is unusable because it is encrypted.

There are reasons for colleges and universities to be optimistic about improving their data protection posture. Security professionals have learned a lot over the last few years, and there is better guidance and best practices on how to tackle this problem. And security vendors now offer more affordable and easier to use encryption and key management solutions. Download our podcast "Higher Education Under Attack - Data Privacy 101" for more information on what universities can do to prevent data breaches and how to easily get started today.

Patrick

For organizations storing Personally Identifiable Information (PII) or Protected Health Information (PHI), a security audit may be on the horizon. Companies concerned about how they protect their sensitive data, or are just beginning to protect their data, may need some guidance on how to create a comprehensive data security plan for their organizations to meet compliance regulations such as PCI DSS and state and the proposed federal regulations. I recently sat down with Patrick Townsend, CEO & Founder of Townsend Security to discuss the steps an organization should take when re-evaluating or embarking on a data security project.

A Roadmap to a Comprehensive Data Security Plan:

1. Develop a Data Security Plan based on these questions:

a. What are my organization’s policies and procedures around data protection?
b. Where does our data live?
c. Who has access to our data vs. who should have access to our data?
d. Do we conduct routine vulnerability scans?
e. Do we use proper system logging, encryption and key management?

2. Get an IT Security Assessment

a. Perform a data security assessment with in in-house consultant, security audit firm, or platform vendor to evaluate your current security posture.
b. Find the location of all sensitive data.
c. Evaluate the security of your tape encryption.

3. Implement your Security Plan with proper encryption and key management so that you can answer “yes” to all of these questions:

a. Is our encryption industry standard and NIST certified?
b. Is our key management FIPS 140-2 compliant?
c. Are we storing our encryption keys on a separate HSM?
d. Are we using dual control and separation of duties to reduce audit points of failure?

Once you have completed these steps, your data security posture will improve dramatically. For more information from Patrick Townsend on data security and compliance, watch this webinar “Four Solutions for Data Privacy Compliance”.

About 5 years ago I set myself the task of reading every state's data privacy law. There were 44 states that had passed some form of data privacy law, and several were in the process of updating them. I also created a spreadsheet and cross-referenced information what each state considered Personally Identifiable Information (PII) that needed to be protected. The State of California had led the way with SB-1386, and many states followed.

I learned a few interesting things from the process:

A significant number of states just lifted verbatim what other states had written into law. A rough guess is that about one third of the states had almost identical data privacy laws.

But the remaining two thirds of the regulations varied greatly, even in defining what PII is. It was common to consider the First Name and Last Name in combination with a Social Security number, bank account number, or driver's license number as information that constituted PII that needed to be protected. But after reading and collating all 45 states, there were some states that had a list of up to 41 data items that were considered PII! In addition to the standard data items, I found passport numbers, military IDs, medical numbers, email addresses, and much else. I even found definitions of PII that went something like this: "Any information in aggregate that can identify an individual must be protected." It was a lot of ground to cover.

Shortly after this exercise I remember having a conversation with a mid-western CIO about that information. She said "Really, email addresses? But what do I do about Outlook?"

It was a good question then, and it is even more cogent today. When an email address is lost with other information about an individual, it can lead to big problems.

Just look at the news today about Amazon and Apple. Information routinely exposed by Amazon was used to gain access to sensitive data on Apple's services. And the email address was an important piece of the information used in this attack.

So, should you be protecting email addresses? Absolutely!

As many of the recent data breaches demonstrate, an email address combined with a password or other information can lead directly to a data breach. Just think of eHarmony, LinkedIn, Yahoo, and many others recently in the news. It is common to store email addresses in business databases used for Customer Relationship Management (CRM), Enterprise Resource Management (ERP), and similar types of systems. If you store email addresses, you should start working now to place them under encryption control with good encryption key management. And you should start bugging your software and cloud vendors to provide you with this capability. For more information on how you should be encrypting your PII, download our white paper "AES Encryption and Related Concepts."

Patrick

Cyber 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.

We have recently seen the medical community step up their level of concern regarding protecting Protected Health Information (PHI).  Aside from just “doing the right thing” there are business reasons attached.  Data breaches are now a regular occurrence and have serious dollars connected to them.  Did you know that data breaches in the healthcare industry have increased 32% in the past year and cost an estimated $6.5 billion annually?  Additionally, breaches aren’t just a result of hackers.  Forty-one percent of healthcare executives attribute data breaches to employee mistakes.  Luckily, there is a safe harbor for breach notification – proper encryption and key management.

We recently held a webinar titled “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” and received some excellent questions that we would like to share with our blog readers around encryption, key management, and breach notification.

What does the Department of Health and Human Services (HHS) have to say about Encryption and Key Management?

The Department of Health and Human Services (HHS) points to the National Institute of Standards and Technology (NIST) for encryption and key management best practices.  When an organization has a breach, and their encryption and key management isn’t based on industry standards such as those defined by NIST, you can bet they are going to be responsible for a breach notification – averaging $214 per record or $7.2 million per breach.

So when NIST says “This is what we suggest you do,” companies are taking note.  WHEN there is a breach – not IF there is a breach – HHS is going to ask how you were encrypting your data.  Was your encryption based on standards? How were you managing your encryption keys?  Was your encryption a homegrown or proprietary solution? 

NIST suggests using Advanced Encryption Standards (AES) for encrypting data at rest and pairing it with a proper key management as you would find in our  Alliance Key Manager HSM.  With NIST certified encryption and key management, you are provably meeting standards and best practices, and in turn, HHS is more likely to say you are exempt from a breach notification.

We are a medical software vendor.  Are we required to encrypt PHI in our solution?

Software vendors and medical equipment vendors have no mandate requiring them to protect the data, but it is a strong recommendation.  Keep in mind that both end customers and their patients are expecting their data to be protected the right way and they don’t want to find themselves subject to breach notifications.  Implementing proper encryption and key management has become even more important for software vendors as it is becoming a competitive issue.  We are seeing our partners finding success because there are still gaps in terms of who is offering this kind of protection – though everyone should be.  

The other thing to think about, and HHS is quite clear on this issue, is they really want vendors of medical solutions to offer encryption.  Although it is not a mandate yet, companies that currently have solutions in the medical segments should be prepared for encryption and key management to become a requirement in the future.  As we have seen before, things that are strong recommendations today often end up as mandates tomorrow. 

View our webcast “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” to learn how your organization can manage their risk of a data breach and achieve breach notification safe harbor status.

Over the last few years we’ve seen attempts by the US Congress to pass new federal privacy notification laws. There are good reasons to do this as the current mix of state privacy notification laws are inconsistent and it is hard for organizations of any size to know if they are in compliance with the more than 45 state-level regulations. Businesses would appreciate some simplification and clarity, and one federal law would be preferable.

Both the House of Representatives and the Senate have seen proposed legislation pass out of committee. But no consolidated legislation has passed Congress and been signed into law.

The latest attempt is proposed Senate Bill 3333.

This legislation is similar to many state laws in how it defines Personally Identifiable Information (PII), how it proposes that breach notification take place, and how it levies fines for the loss of sensitive information. Like HIPAA legislation, it charters the Federal Trade Commission with enforcement responsibility.

Unfortunately, it won’t have much of an impact on reducing data breaches and identity theft.

First, the definition of Personal Information is too narrow in today’s consumer and Internet world. To qualify as a breach, the proposed act requires that the data loss include a first and last name combined with a social security number, or financial account information. The breach that happened to LinkedIn would not even qualify under this definition. And yet it was a serious security breach. The bad guys are really good at aggregating data like this, so the new law wouldn’t have helped. And it will give companies an excuse for hiding this type of loss.

When it comes to protecting sensitive data it leaves a gaping hole. Here is how the proposed legislation describes the approach to protecting sensitive data:

Personal information does not include information that is encrypted, redacted, or secured by any other method or technology that renders the data elements unusable.

Without a requirement to use encryption, AND clear guidance on protecting the keys used for encryption, we will continue to see significant data breaches taking place on a daily basis. Without this clear guidance, we will actually take a step backwards. In today’s world, security auditors and professionals already understand the need for good encryption key management systems and practices. They know that encryption keys stored with the sensitive data is equivalent to taping your house key to the front door when you leave in the morning. PCI data security auditors, SOX auditors, and almost all other security professionals now require that encryption keys be protected by HSMs designed for that purpose. But we don’t see mention of this in the legislation.

Rather than provide clarity around protecting sensitive data, this legislation will continue the confusion around how personal information should be protected, and even what constitutes a data breach. It will not provide the clarity and guidance that businesses hope for. It won’t stem the loss of sensitive information, and it won’t stop the terrible financial impacts of identity theft.

Let’s hope this bill gets strengthened before the final version is passed.

Patrick

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

The recent email and password breaches at LinkedIn and Yahoo have exposed how severe the loss of this information can be.  A large majority of people use the same email account and the same password to authenticate to multiple web sites and services. For this reason, the breach of any one site compromises the security of the others.  And the fact that Facebook, Google, and other sites make it easy to share authentication makes the impact of a loss that much greater.

Because of these losses, I’ve been getting a lot of questions from CIOs and database administrators about protecting email addresses and email passwords in their databases. While the techniques used to protect information in databases are different than the techniques used to protect login credentials, you should definitely put this type of information under data protection controls.

Here are some steps you can take to protect this important personally identifiable information in your databases:

• Be sure to encrypt BOTH the email address and the password.  I often find that companies only encrypt the password. It turns out that end users frequently use weak passwords and they are easy to guess. Even if the password is protected using strong encryption, the password can often be discovered through a dictionary attack. So encrypt BOTH the email address and the password.
• Don’t decrypt an email address and password if you don’t need to. I’ve noticed that many applications automatically decrypt a password when a row is read from a database even if it is not needed. This just creates an unnecessary exposure point.
• Use strong, industry standard encryption methods to protect the email address and password. I recommend using 256-bit AES encryption which is the most widely accepted standard for protecting data at rest.  Never use home grown or non-standard encryption.
• Use good key management practices. Store the encryption keys on a key server HSM designed for this purpose. Storing the encryption key on the same server is like taping your house key to your front door when you leave in the morning.
• Store passwords on a key server HSM and not in the local database. Many key server HSMs provide the option to import raw information like passwords to the key server, and then retrieve them only when needed.
• Most important! Don’t be discouraged about the effort required to implement good encryption and key management. I’ve seen security efforts defeated before they begin because companies think that the effort will be too complex and too expensive. It’s probably easier than you might think.

Database vendors like Microsoft, IBM, Oracle, and others have done a lot over the last few years to make this effort easier. And security vendors (we are one) have also made progress in making encryption and key management faster and more affordable. Encryption is widely viewed as hard to do and expensive. That’s no longer true - times have changed!  Download a free 30-day evaluation of our NIST-certified AES encryption and see how easy it is to encrypt usernames, passwords, and other PII on your systems.

Patrick

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

In May 2012, the Commodity Futures Trading Commission (CFTC) was the victim of a fairly high profile security breach. The breach occurred when a CFTC employee opened a suspicious email that turned out to be part of a “phishing” scheme. Phishing is a type of cyber crime where a hacker, posing as a legitimate company, gains access to a user’s private information when that user opens the fake email.

These emails often appear to be messages from large, well-known organizations that you may or may not be affiliated with or a customer of, such as cellular service providers, banks, or insurance agencies. The messages often contain fake bill statements with requests for payment, or requests for password or address changes. Once a user clicks on the email or the links provided in the email, the hacker gains access to personal information that can then be used for identity theft and other kinds of fraud.

In an official statement by the CFTC, chief information officer John Rogers revealed that the personal information stolen by the phishing scheme was largely social security numbers. However, Rogers asserted that CFTC operations would not be affected by damages due to the breach. This is, in general, is true for large organizations and corporations who can often afford to absorb the high cost of these setbacks. Rarely will these breaches affect them in the long run. Smaller and mid-sized organizations, on the other hand, often have difficulty rebounding from data breaches and are always at a greater risk to phishing schemes and other types of data loss.

Here at Townsend Security we recommend to everyone who has a personal or work email to take care that they are sending and receiving messages from reliable sources. Red flags to look for include emails with offers that seem “too good to be true”, receiving a bill you don’t expect, unsolicited offers from any organization, or requests to change any type of personal information through a link provided in the email.

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.

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.