Townsend Security Data Privacy Blog

I am on a new kick to share some security resources with you that I’ve found valuable over the years. I am not following any particular order or ranking people and resources by importance:  I’m just going to do this as the mood strikes me.

Let me introduce you to Chris Evans and his blog.

Chris works for Google, he’s a software and security geek, and is an independent sort. A lot of his work is technically deep, which is great for those of us who enjoy that sort of thing. But I also really like his world view.

Chris has a hacker’s mentality (in the good sense) and his values are lined up with making the world a better and safer place. He doesn’t avoid talking about his own mistakes, and believes that more information about security problems makes the world safer as it gives people the information they need to protect themselves, and it helps developers make their solutions better.  He also provides a lot of just plain good advice that anyone can use.

One example is a recent blog on web browser security. The blog combines some technical information, but it also gives you information about how to think about web browser security, and why some web browsers are better than others.

He also makes an interesting statement about browser security that I think has corollaries that apply to anyone writing software that needs to be safe. Chris says:

“The security of a given browser is dominated by how much effort it puts into other peoples' problems.”

For those of us who write business applications and security software, I would put it this way:

"In addition to everything else you do to make your solution more secure, you have to include other people’s problems in the scope of your thinking, including the unexpected ways they might use your solution."

Enjoy.

Patrick

Hundreds of thousands of Medicaid recipients are up in arms about a recent security breach that saw their personal information abducted by hackers. Originally it was reported that 181,000 had their information stolen including 25,000 who actually had their social security numbers taken as well. Currently the report has been updated to a staggering 900,000 and 280,000 respectively. Over a quarter million people on Medicaid had their social security numbers exposed, and many of these victims don’t have the means to hire private investigators or attorneys to right their personal situations. 

As many organizations that suffer a breach do, the Utah Department of Health is offering free credit monitoring services for one year to those who had their social security numbers compromised. Other than that, there isn’t much to be done for the breach victims.  Unfortunately, many are still concerned their identities could be stolen among other potential hardships.

To prevent security snafus such as this, the Utah Department of Health should have been protecting their sensitive data with encryption and key management.  Encryption would have rendered the breached data useless. The Utah Department of Technology holds millions of its citizen’s personal information and, unfortunately, didn’t take proper precautions to protect it. Alliance Key Manager, our encryption key management HSM, could have provided exactly what they would have needed to avoid a breach.  With on-board encryption, sensitive data can be sent to the HSM, encrypted, and then sent back to where the data needs to live. Additionally, Alliance Key Manager also meets regulatory requirements - a hurdle for many companies trying to pass an audit around encryption key management.

When you see a situation like this in Utah, its naive to think that hackers can’t access your information in your own home state. But just ask a Medicaid recipient from Utah, and it is clear that these dangers aren’t so far from home. Utah’s governor spoke on behalf of its citizens saying "Individuals provide sensitive personal information to the government in a relationship of trust. It is tragic that not only data was breached, but now individual trust is also compromised."

It’s a difficult situation, but as they try to mend the fences, it is important to audit your own encryption and key management processes to ensure that what happens in Utah stays in Utah.

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.

It is increasingly apparent how much smaller the world is getting. As long as there has been human civilization, technology has decreased the vast uncertainty of our universe. We are a far cry from the 15^th century, when the European elite didn’t know North America existed. Bell invented the telephone, and suddenly months of correspondence could be condensed into a five minute chat. Then came the personal computer and opportunities for seemingly everything in the world were endless. As the complete paradigm shift to cyber data happened, the increasing dependability on what is put on the net became a way of life.

Recently, The National Security Administration (NSA) began construction on what is plainly named the “Utah Data Center” in Salt Lake City, Utah.  The “Utah Data Center” is going to be a one-million square foot, state-of-the-art data center designed for the purpose of intercepting, deciphering, analyzing, and storing communications from all over the world.

NSA’s security director General Keith Alexander has been under a constant barrage of questions from the American public regarding the security and privacy of the information that is being collected.  Concerns include:

• Does the NSA have access to Americans’ emails?
• Does the NSA have access to Americans’ Google searches?
• Does the NSA have access to Americans’ text messages

All of these questions have been answered by Alexander with a flat “no.”

I think we can assume that the NSA doesn’t have outright access to these private details from our lives, but many are concerned about their right to privacy and if the NSA infringing on it. It is understandable when places like the “Utah Data Center” are created to intercept and store personal information. As a company that deals with protecting private information, we have to trust this new facility has the absolute best security in place.

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.

Data Privacy Day (January 28, annually) is an annual international celebration designed to encourage awareness about privacy and education on best privacy practices.  Sponsored by companies such as Intel, eBay, and Google, the day is designed to promote awareness on the many ways personal information is collected, stored, used, and shared, as well as education about privacy practices that will enable individuals to protect their personal information.  

As a data privacy company, this day is almost like our birthday – a day for the IT world to focus on our slice of the pie (can we celebrate Data Privacy Day with pie too?).  It also is a time to reflect on some of the data breaches that made news headlines in the previous year – “is my organization making some of the same mistakes?”

In honor of Data Privacy Day, StaySafeOnline.org has published a document titled “Stop. Think. Connect” that gives tips and advice on keeping your personal information safe.  Here is some of their advice:

Protect Your Personal Information

• Secure your accounts: Ask for protection beyond passwords.  Many account providers now offer additional ways for you verify who you are before you conduct business on that site.
• Make passwords long and strong: Combine capital and lowercase letters with numbers and symbols to create a more secure password.

Connect with Care

• Get savvy about Wi-Fi hotspots: Limit the type of business you conduct and adjust the security settings on your device to limit who can access your machine.
• Protect your $$: When banking and shopping, check to be sure the sites is security enabled.  Look for web addresses with “https://” or “shttp://”, which means the site takes extra measures to help secure your information. “http://” is not secure.

Keep a Clean Machine

• Keep security software current: Having the latest security software, web browser, and operating system are the best defenses against viruses, malware, and other online threats.
• Automate software updates: Many software programs will automatically connect and update to defend against known risks.  Turn on automatic updates if that’s an available option. 

By following these few tips your personal information/data will be more secure than ever.  We also urge you to think about who you give your personal information.  Do you think twice about whether it is being properly protected?

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.

 

I recently attended a webinar for accountants on the importance of IT security.  The webinar discussed findings from the newly released 2012 Global State of Information Security Survey®, a worldwide study conducted by Pricewaterhouse Coopers, CIO Magazine and CSO Magazine.  They used the information from the survey to make two important points

1. IT security isn’t just the responsibility of the compliance officer and IT department, everyone in the organization is responsible for keeping corporate assets secure - all of us, even those in accounting, customer service and sales play an important role in data privacy.  
2. IT security is not just a project with a due date for completion, it is something all of us must remain diligent about.  

Some of us have access to sensitive customer information or account numbers, while others may be collecting credit card information to process payments.  Sure, our IT department implements safety policies, installs security software and sets access rules and passwords to give us access to data we need to see.  But do we stop and think about what information is on our laptop before we take our laptops home or what files might be on that USB drive?  We need to think about the information that we email or send outside the company and think twice about the way we send it, especially if we think the information could cause damage if it landed in the wrong hands.

The companies used for the survey all felt they implemented strong controls around access to their data, but nearly all of them had some sort of budget allocated for additional resources because they know they need to do it better.  Interestingly, the confidence level these companies felt about their security strategy had declined over the years due to the increase in use of mobile devices and social media, which have introduced new risks and challenges for companies.  In 2009, 73% of the companies surveyed felt they had a good security strategy in place, however, in 2011 that fell to only 53% feeling confident about what they are doing.

It was very apparent to me after viewing this webinar that the adoption of mobile devices by employees and the acceptance of social media has made IT security everyone’s responsibility.  Key take-aways for me from this webinar – we all need to be thinking about how we keep information that our company entrusts with us secure.  We need to follow company policies and procedures and be diligent. We are all in this together.

For more information on data privacy, we have put together a podcast titled "Data Privacy for the Non-Technical Person."  Let us know what you think.

Periodically people ask me about hashes and why the use of a salt value with a hash is recommended. Let’s have a look at this topic in our last blog for 2011!

The use of a secure hashing algorithm is common in business applications. It has a variety of uses in the areas of authentication, data integrity, and tokenization. A hash method is sometimes called one-way encryption, but this is a bit of a misnomer.  It is true that you can’t reverse the result of a hash operation to recover the original value (thus it is one-way), but it is not formally an encryption method. This one-way property of hash methods is what makes them so useful. You don’t have to worry about sending a hash value across a network in the clear as it can’t be reversed. (At ease you crypto people, I know about the developing security concerns about SHA algorithms; more on that later).

While there are a number of hash algorithms available in the public domain, most security professionals recommend the use of the SHA-2 family of routines. I find that most people now use the SHA-256 algorithm when they want to create a one-way hash of some data, although the more secure SHA-512 method is being used more frequently. Older methods such as MD5 and proprietary hash methods should not be used in modern applications due to security concerns.  With SHA-256 and SHA-512 we have a really good method for doing one-way hashes.

So why do some security professionals recommend the use of a salt value with hashes, and what is salt?

The term salt refers to a one-off value that is difficult to guess. In practical application, a random number is generally used for a salt value. For the sake of this discussion, we will assume that a salt value is a random number.

By adding a salt value to some data before hashing it, you make it more difficult to guess the original value. Notice that I didn’t say you make it easier to reverse! For all practical purposes, you can’t reverse a hash value. But a clever attacker might guess at the original value and perform a dictionary or brute force attack on a hashed value. How can that be?

Well, take the example of your banking PIN code. It might be 4 or 5 digits in length. From the point of view of modern computers, that is a really small set of numbers to test against a SHA-256 algorithm. Only 9,999 values for a 4-digit banking PIN code. That is going to take less that a second to run through all of the possibilities. So this is where a salt value can come in handy. If you are creating a hash value of very small bit of data, you can append a salt value to the original data and make it really hard to attack that hash value. And that’s why using salt with your hashes is often a recommended security practice.

By the way, even though credit card numbers are only 16 digits in most cases, that is still a small number in computational terms. And once you account for BIN codes and LUHN check digits, credit card numbers are effectively smaller than 16 digits. This is why PCI and other regulations require or recommend the use of salt with hashes.

If you do use a salt value with a hash, you have to take care to protect the salt value from loss. You should take as much care about protecting the salt value as you take with encryption keys. If someone knows the salt value you’ve lost your advantage. Also, you should be sure to use a salt value that is large enough to provide good security. A 128-bit salt value is adequate for most business applications.

As I hinted at above, there have been some developments in attacks against the SHA-2 family of hash algorithms. I don’t think these attacks rise to the level of a practical concern in business applications, but the professional cryptographic community is hard at work on new hash methods. I think you should continue to use SHA-256 with confidence, but you should salt that hash for added protection!

Happy Holidays!

Patrick

Be sure to follow us on Facebook, Twitter, and LinkedIn to stay up to date on the latest technology and news about data protection.

   

We've been tracking the growing need for encryption and key management to secure the mass of data that is (or soon will be) residing in the Cloud. To address this issue, a security group was recently formed that is completely focused on Cloud security. If you’ve not visited the Cloud Security Alliance web site, it is well worth a visit at www.cloudsecurityalliance.org.

The alliance has attracted top tier talent in the security and audit communities, and has published guidance on issues that should concern anyone considering deploying Cloud solutions.

The guide covers three basic models of cloud deployment – IaaS (Infrastructure as a service), PaaS (Platform as a Service), and SaaS (Software as a Service). It goes on to discuss the necessary differences to approaching security in the Cloud. It’s a nicely done, high-level guide to security in the cloud.

Section 11 in the guide is on encryption and key management, which is the focus of our company and products. Their recommendations on encryption are spot-on. Because of co-tenancy and shared resource management on cloud platforms, security professionals recognize that there is an elevated risk of loss. Cloud users need to take extra steps to protect sensitive information. Encrypt data in motion, even between different applications and environments on the same cloud; Encrypt data at rest and in archival storage; Encrypt data on backup media and insure that you have access to the encryption keys in a non-cloud environment.

The recommendations on key management are also very interesting. The alliance has recognized that weak key management is much more of a problem in Cloud environments. Here is a sample and summary of some of their recommendations (you can get the full report at their web site):

Key stores must themselves be protected in storage, transit, and backup. Encryption keys should never be stored in the clear, and keys should never be stored on the platform where they are used.
Access to keys should be controlled, and the users of encryption keys should not be the ones storing and managing the keys. This means you should never use native operating system account management as the access control mechanism for key management.

Secure backup and recovery of key management systems is more important. There are special requirements for backing up key management systems.

Segregate key management from the cloud provider to avoid conflicts in the event of legal disclosure requirements. This will be a real challenge for companies that use Clouds for substantially all of their operations.

Insure that encryption adheres to industry and government standards. Of course, the only way to insure adherence to standards is to insist on NIST certification of encryption and key management solutions. For example, FIPS-140 certification should be a requirement for a key management solution.

These are just some of the recommendations in this important guidance. If you are considering the Cloud as a home for your applications and systems, this guide is definitely for you.

For further information, we have produced a podcast titled Key Management Best Practices: What New PCI Regulations Say.



Patrick

Many of us have been watching the on-going drama between RIM (makers of the ubiquitous Blackberry) and various governments around the world. Governments have been successfully pressuring RIM to provide access to their internal messaging servers in order to get access to encrypted messages sent and received by Blackberry users. I think RIM has been trying to fight this access as best they can. After all, one of their key product messages is around the security of their systems. In spite of that I suspect some governments have been successful in getting at least limited access to the Blackberry servers that process secure messages.

At first I was puzzled by this story when it started to emerge. I mistakenly thought that the private key needed to decrypt a message was stored on the receiver’s Blackberry and that the intermediate message servers would not have the key necessary to decrypt a message. I was apparently wrong about this architecture and it turns out that the Blackberry message servers do have the ability to decrypt messages in transit. That ability puts RIM in the uncomfortable headlights of law enforcement and security agencies around the world.

People have been asking me if a similar situation exists with other common encryption technologies. For example, when I encrypt a file with PGP can it be decrypted by someone (A government? A credit card thief?) before it reaches the intended recipient. Before the drama with RIM I was not hearing this question, but now I think many people are wondering about it.

The short answer is to the question is No: When you encrypt a file with PGP it is not possible to decrypt it before it gets to the intended recipient. PGP is based on the widely used public/private key encryption technology deployed in many secure systems such as VPNs, web browsers, and secure FTP. When I encrypt some information with a public key, only the person holding the private key can decrypt the information. As long as I protect my private key an intermediary can’t decrypt a message intended only for me. Almost all of our assumptions about security depend on this fact.

Is this system perfect? No. As a recipient of secure messages I may inadvertently disclose my private key or lose it by failing to protect it properly. Also, I may be legally compelled by a government agency to relinquish it. Many governments are now requiring people to disclose their private keys and passwords when ordered by a court to do so. You might think that you can’t be compelled to give up a password or private key, but I think that resolve might fade after a few days of sitting in a jail cell. The bottom line is this: public/private key technology is the best method we have of protecting sensitive information. When done well it prevents anyone but an intended recipient from reading the sensitive information. But it also means that you have to pay attention to how you manage and protect encryption keys. Proper encryption key management is essential to any data protection method you use. We’ll be talking more about this in the days ahead.

Patrick