Townsend Security Data Privacy Blog

Microsoft has announced that the October Windows update will change Windows support for certain RSA key sizes.  Our customers have asked:  How will this affect our use of your encryption key manager? Do we need to worry?

No, you don’t need to worry. Here’s why:

Microsoft operating systems will remove support for RSA keys smaller than 1024-bits. The use of 1024-bit and larger keys will still be supported without change. So, only RSA keys that are SMALLER than 1024 are affected.

Alliance Key Manager, our encryption key management HSM, enforces the use of 2048-bit keys and does not allow they use of keys smaller than 1024 bits. NIST has recommended that applications migrate to larger RSA key sizes for some years, and we built Alliance Key Manager to meet those key size best practices. Today, no application should be using an RSA key that is less than 1024 bits.

Our existing customers will not be affected by this Microsoft change. If you are using Alliance Key Manager for Microsoft SQL Server Transparent Data Encryption (TDE), Microsoft SQL Server Cell Level Encryption, Microsoft SharePoint 2010 with SQL Server TDE, Microsoft Dynamics CRM, or our Microsoft Windows .NET client applications, you will not be affected by this change.

We simply do not allow the use of insecure RSA key sizes.

Download our podcast "Encryption Key Management" to learn more about encryption key management and what auditors are looking for and how to easily manage your encryption keys.

Patrick

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

If you have Microsoft SQL Server with Extensible Key Management (EKM), the implementation of encryption and key retrieval with Alliance Key Manager, our encryption key management Hardware Security Module (HSM) is easy. Our HSM comes with the Windows EKM Provider software that you install, configure and deploy.  Problem solved.

But what if you have a significant investment in Microsoft applications that don’t support EKM?

For example, you might have applications built on SQL Server 2005 or SQL Server 2008/2012 Standard Edition which do not support EKM. You could upgrade to SQL Server 2008 R2 or SQL Server 2012, but there might be application roadblocks that prevent the upgrade right now.

Or, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data.

These technical hurdles won’t stop you from using our encryption key manager to meet compliance requirements for protecting encryption keys. We provide a .NET Assembly and DLL that you can add to your .NET project to retrieve encryption keys from the HSM. A few lines of C# code and you are retrieving the encryption key from the HSM, and the problem is solved.

The sample code on the product CD will get you up and running quickly. There are C# sample applications with source code that you can use as a starting point in your projects. The Alliance Key Manager .NET Assembly works with any .NET language including C#, C, and C++.

The Alliance Key Manager .NET Assembly also works with the Common Language Runtime (CLR) environment, and with Stored Procedures. And you can mix and match your .NET languages, databases, and OS platforms.

The combination of automatic encryption (EKM, TDE, Cell Level Encryption) with the Alliance Key Manager .NET Assembly code means that you won’t have any gaps in your coverage of your Microsoft platforms.  Download our white paper "Key Management in the Multi-Platform Environment" for more information on securing your encryption keys.

Happy coding!

Patrick

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

The last 20 years has seen a dramatic re-alignment of the Chief Information Officer’s (CIOs) responsibilities to match the business goals of their Organizations. The modern CIO is less likely to be a pure technologist, and far more likely to be imbued with a deeper knowledge of business issues such as organizational goals, strategic alliances, bottom line financial analysis, and even with merger and acquisition strategies. In the public sector, this means that CIOs are far more aligned with political and policy goals, and not just minders of the IT infrastructure.

This has largely been good for the competitive stance of business organizations, but I think it has led to some technology blind spots. CIOs today are far more dependent on their vendors, consultants, and shrinking IT staff for guidance on security issues, and data privacy in particular. And in today’s risk environment, that may not be a good thing.  Because when a data breach happens, the CIO is going to be the one on the hot seat to explain the problem and take responsibility.

And that is not a comfortable place to be.  Just ask anyone who has been there.

When CIOs try to assess their data privacy stance, they often question their IT staff questions like this:

• Do we have our data protected properly?
• Is our data protected according to compliance regulations?
• What assurances do we have from software and cloud vendors that our data is protected?

Patrick Townsend recently contributed this article to OneAccord's blog.  To read this article in it's entirety you can visit OneAcord's blog here.  If you are ready to learn more about encryption, download our white paper "AES Encryption Strategies - A White Paper for the IT Executive."

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

The Healthcare industry is still struggling to come to terms with the new HIPAA/HITECH requirements to protect patient health information. There are now clear requirements to protect patient information (called Protected Health Information, or PHI) from loss, and data breach notification is now mandatory, but CIOs in the medical segment have not yet developed pro-active attack plans to secure their data, and are caught by surprise when they experience a data breach - something that is happening at an alarming rate.

Why is this?

I think we can understand this by looking back at the history of the Payment Card Industry rollout of data security standards about 8 years ago. In the early days of PCI DSS compliance, many companies also took a reactive stance regarding the regulations. I heard CIOs say that they thought their data was already safe, that their IT staff assured them that everything was OK, and even that they would only do something if they had a loss and were forced to make changes. I even heard “I’ll pay the fine and do the time if I get caught.”

It took a number of years before CIOs and their executive teams who fell under PCI DSS to come to understand the real impacts of data breaches and developed a pro-active stance around data protection. Companies came to realize that data breach costs went far beyond the initial fines for non-compliance. There are litigation costs, costs for notifications, new external audit requirements that extended years into the future, opportunity costs while valuable staff focused on fixing the problem and not enhancing the business, and a loss of confidence by their customers and partners. Additonally, breaches can create a public relations nightmare for your company and possible long-term damage to the brand. All of these have real impacts on the bottom line.

When companies in the payment industry fully grasped the impacts of a data breach, they went to work pro-actively to protect sensitive data.

The Healthcare industry is not there yet.

What can a CIO do to change their organization’s posture on protecting PHI? Here are some things to start on:

• Educate senior management on the real costs of a data breach. (This is probably the most important first step - everyone has to buy into the need and the plan).
• Involve your IT professionals in creating an inventory of PHI every place it resides in your organization.
• Identify everywhere in your IT systems where you receive PHI from outside sources, and where you send PHI to outside sources.
• Create a plan to encrypt PHI and protect the encryption keys.
• Prioritize your projects. There will be low hanging fruit – places where putting encryption in place is relatively fast and painless.
• Focus on execution. “Are we there yet?”

I know that the Healthcare industry will eventually get to the right posture on data protection. It will take some time before the realities are well known. But as I talk to CIOs at companies who have experienced a data breach, I know that they get it. Hopefully, these painful lessons will seep into the larger industry sooner rather than later, and you won’t be that CIO who wakes up one morning to the unpleasant surprise of a data breach.

Patrick

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.

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

The adoption of the Secure Shell (SSH) file transfer protocol has gained a lot of momentum over the last few months. Major financial institutions are migrating from proprietary transfer systems, and from the Secure Sockets Layer FTP protocol (SSL FTP) to Secure Shell implementations. We’ve had support for Secure Shell file transfer automation in our Managed File Transfer solution, Alliance FTP Manager, for many years and our customers are making the switch with no difficulties.

But what about running the Secure Shell server on the IBM i platform? What do you need to know about securing the SSH server when it runs on the IBM i?

One of the most important things you can do is create a CHROOT jail for the SSH server.

I can see you raising your collective eyebrows right now! Let’s talk about what a CHROOT jail is, why you would want to do this, and how you can make it happen.

Without creating some additional controls, your implementation of the SSH server will leave your system very exposed to abuse. For example, if you SSH to a server and log in, you will be presented with a command line. For any of you Linux geeks, you know what a command line means. It’s free reign to wander all over the system. On any SSH server without good controls, you can change directory (CD) to any library or IFS file on the system. And then you can do a lot of damage!

CHROOT to the rescue!

The Linux CHROOT facility is designed to keep users in a tightly controlled area, or “jail”. It’s been a part of UNIX and Linux for decades, and is very well implemented in those systems. But we also have it on the IBM i platform. If set up correctly, your IBM i SSH server with CHROOT implemented will keep those users from wandering around your system. They will only be able to see the directories you give them, and they won’t be able to change to other directories. They are in the little jail that you created.

Fortunately, the IBM i OpenSSH licensed software provides full support for implementing CHROOT jails. You can enable CHROOT support in the SSH server configuration file, and IBM provides a Shell script to create all of the directories and objects you need for each user. And there are good instructions on how to set this up.

But there is one little piece of CHROOT that can be a challenge. For CHROOT to work properly, the SSH server has to be running as “root” when it starts. On an IBM platform, that means it has to be running under the QSECOFR user profile. But you can’t submit the job and specify the QSECOFR profile, so how does this bit of logic get automated?

In Alliance FTP Manager we’ve solved that problem for you. When you specify that you want to run in a CHROOT environment, we submit the job and perform a profile swap to QSECOFR. Voila! You have everything you need to use the SSH server with CHROOT enabled.

If you want to run the SSH server on your IBM i you can contact our technical support group to receive the added software for the Alliance FTP Manager product. You can be up and running with CHROOT’ed SSH in no time at all.

Patrick

---

Townsend Security’s FTP Manager has been helping IBM i (AS/400) users meet compliance regulations by securing and automating their data in motion to trading partners, customers, employees, and internal systems. Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how we can help your organization save time and money by securely automating your file transfers.