Townsend Security Data Privacy Blog

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.

I am often asked about what policy and features can be assigned to an AES encryption key that is created by Alliance Key Manager, our encryption key management HSM.  Simply put there are various options available at key level for each symmetric encryption key you create. This helps you line up with PCI-DSS, HIPAA/HITECH and other compliance regulations, as well as providing a well rounded security strategy for proper encryption key management.  I wanted to give you a little bit of flavor of what some of these key options are so you can get a sense of the flexibility when it comes to key creation.

To get started, when creating a symmetric key, you assign it a user friendly name.  This can be something as simple as ENCKEY_HR.  This makes it easily identifiable from a management standpoint for what it's used for and for what group will be using it.  And since these are AES keys we are creating, you'll be asked to specify what key size you wish to utilize for each individual key.  Your options are 128 bit, 192 bit, and 256 bit keys.  I normally recommend the 256-bit size as it is the strongest options available, but in all honesty, any size is adequately strong against any brute force attack it might come up against by a crafty hacker trying to decrypt your data  

When creating keys, you’re allowed to set activation and expiration dates.  This allows you to pre-create keys and to define a schedule as to when a key can be made available for use.  You may want to have a policy where keys expires every few years and you revoke their use from users.  If you're familiar with PCI requirements you'll know that you have to establish a crypto-period for your active encryption keys.  When creating an encryption key you can specify how many days that key will be made available before it automatically rolls over into a new version of that key.  The friendly key name you assigned to it at conception will never change, but behind the scenes you'll have a completely new instance of that key for use.  Additionally, in an event where you suspect a data breach or need to roll a key manually, these options are available for you as well.

To provide an additional layer of security to who can have access to encryption keys, we provide a Key Access table that lets you lock down who or what groups can have access to which keys. There are varying levels of granularity that are made available for you in this area. For example, from a very unrestricted sense where anyone in your organization with an authorized TLS session to the server can request a key, all the way to the very strict policy where only specified users within specified groups can requests certain keys. These credentials are all set at the key level and are defined on the key requestor side within the distinguished name of the digital certificate they are using to connect to the key server and establish a secure link for key retrieval.

Additionally, keys have mirroring attributes that can be set at the key level to ensure you don't experience a business interruption by always having access to keys in the event of a network outage.  I've seen customers never miss a beat when that unexpected outages occurs due to the fact that they have a hot failover standing by and ready to go.  Also, to help add a level of detail to the keys you'll be creating, we provide sixteen different metadata fields for you specify details unique for each individual key.  These fields enable you to easily track important details relevant to the key throughout its lifecycle.

Managing encryption keys with a Hardware Security Module (HSM) is the best way to ensure encrypted data remains secure. Learn how to easily store encryption keys separately from your encrypted data with a secure encryption key management HSM by visiting our Encryption Key Management Simplified Resources page.

It is important for businesses of all sizes running on SQL servers to encrypt any sensitive data that they store or move. Although business size can determine specific compliance requirements that need to be met, all companies handling sensitive data are vulnerable to the major risk of failing a security audit if their data isn’t properly secured on their SQL servers.

Here are the 5 steps you can take to ensure you pass your next audit:

1. Test applications to address vulnerabilities

Continually test and re-test your applications including payment applications and firewalls  to look for vulnerabilities and address them from the start.

2. Protect information transmission

Protect data in motion by offering secure authentication features, logging application activity, using secure payment applications, and protecting wireless transmissions.

3. Protect your data

Ensure stored cardholder or PII/PHI data is protected with encryption; this information should never be stored on a server that is connected to the internet.

4. Encrypt sensitive traffic over public networks

Any transfer of data over public networks should be encrypted, whether this is cardholder information or PII/PHI data. Encrypting sensitive information guarantees that if it is intercepted that it is unusable without the encryption key.

5. Separate the encryption key from encrypted data

Separating the encryption keys from the data ensures the safety of the data in the event of an outside breach. It also allows internal separation of duties, thereby preventing unauthorized access to the the SQL Server data. This is a best practice for encryption management when dealing with sensitive information.

Taking theses steps in order to pass a security audit will proactively prevent data breaches. Even if data becomes compromised, properly encrypted data will guarantee that the data can not be used or accessed.  With a comprehensive data security plan, your company can easily meet state and national compliance regulations. Using proper encryption and key management on SQL Server will make encrypting your data quick and painless, and will help ensure you pass your next audit.

Download our White Paper “Encryption Key Management with Microsoft SQL Server 2008/2012” to read more about encryption key management, meeting compliance regulations with a certified HSM, and how to utilize about TDE and EKM on your SQL server.

Any way you look at it, 2011 was a very bad year for database security. From the high-profile (and highly embarrassing) series of attacks on Sony's PlayStation Network, to the less-publicized Epsilon breach which was described by the Privacy Clearinghouse as the worst data breach in history, there was a huge upswing in attacks targeting private user data. In fact, according to a recent Verizon PCI Compliance Report (PCIR), "about 42 percent of organizations have trouble implementing a proper encryption key management strategy to keep information safe."

In short, hacking has become a goldmine for criminals looking to steal and exploit personal information, and you need to be doing everything you can to avoid being their next victim. For database administrators, this means making sure your encryption keys are as secure as possible.

Key Management in SQL Server 2008/2012

In previous years, encryption security was difficult because the keys were almost always stored locally on the same computer as the data. However, with the SQL Server 2008/2012 Enterprise Edition encryption key management became much more robust thanks to the introduction of Extensible Key Management (EKM).

EKM works alongside the Microsoft Cryptographic API to create a system where SQL server key management is significantly more secure. They can now easily be stored in an external Hardware Security Modules (HSM) that store the encryption keys securely, away from the data they protect. This makes it far more difficult for hackers to gain access to your secure private information.

The Advantages of a Hardware Security Module (HSM)

Alliance Key Manager, Townsend Security's encryption key management HSM provides a number of significant benefits for secure encryption key management.

• Direct Integration With SQL 2008/2012: SQL Server 2008/2012 natively supports HSMs, requiring only a small tweak to the configuration files to enable their usage and disable local key storage.
• True Key Security: With TDE, the key to your encryption never actually leaves the HSM. It cannot be captured through packet-sniffing or at the end user's machine.
• Robust Standards Compliance: A properly-configured HSM setup gives you robust compliance with most of the major public and private security standards, including PCI DSS, HIPAA, SOX, and the Gramm-Leach-Bliley Act.
• End User Simplicity with TDE: EKM also allows for Transparent Data Encryption (TDE), meaning that it's invisible to the end user. Your employees can continue to use their applications as they normally did, with the Hardware Security Module being queried as necessary, behind the scenes.
• Cell Level Encryption: Through EKM, each individual column of cells can be encrypted separately, making large-scale data breaches far more difficult to pull off.
• Easy Implementation: Once the hardware is installed, the key management software only needs to be installed on your server machine. End user access to it is managed through software licenses rather than requiring time-consuming individual installations.

A Smart Choice for Server Security

While encryption and key management are not the only elements necessary for robust data security, they are a major component of it. By implementing a HSM, your business can quickly and easily give its security a shot in the arm, telling your customers and investors that you're serious about protecting private personal information on your servers.

Don't let 2011 be a sign of things to come; take steps now to make 2012 the year of data protection.

Download our White Paper “Encryption Key Management with Microsoft SQL Server 2008/2012” to read more about encryption key management, meeting compliance regulations with a certified HSM, and how to utilize about TDE and EKM on your SQL server.

As security auditors get more educated on the IBM i platform, more customers are having the experience of failing a security audit around encryption key management. CIOs, IT Managers, and System Administrators want to know why this is happening to them now? They ask, why was our approach OK two years ago, and why is it not OK now?

I think I can answer that.

My job brings me into conversations with a lot of companies undergoing security audits under a broad range of regulations including PCI DSS, SOX, GLBA/FFIEC, FERPA, and many others. Security and compliance auditors look to industry standards and best practices for guidance on what their clients should be doing in the area of key management. In the US this inevitably brings them into contact with the National Institute of Standards and Technology (NIST), an agency within the US Department of Commerce. NIST provides a wide set of standards and best practices guidance in the area of encryption and key management.

As you become familiar with the broader set of data security regulations, you start to realize that the one common source they have is NIST. Even if not directly referenced in the regulations, the concepts are largely drawn from work done by NIST, and that is why there are a set of common attributes that auditors look for in a key management implementation.

So, auditors now look for key management implementations based on NIST best practices and standards. Key management best practices can be found in the NIST Special Publication 800-57 (three parts).

One of those best practices is Separation of Duties. This best practice says that the people who manage encryption keys should not be the same people who manage and have access to sensitive data such as credit card numbers, social security numbers, patient data, and so forth. It makes sense – you want as few people as possible with access to sensitive data, and you only want people who have a real need to access sensitive data to do so. The same is true with encryption keys that protect that sensitive data.

On the IBM i platform the security officer and anyone with All Object (*ALLOBJ) authority can access any database file at any time, and can access any locally stored encryption key at any time, regardless of the protections you try to put in place. This is not really a limitation or weakness of the IBM i platform, the same condition exists on other operating systems and platforms, too. No matter what you do you can’t achieve a defensible level of Separation of Duties if you store encryption keys on the IBM i platform. You can try to mitigate this situation through system logging and similar controls, but you can’t eliminate it.

Auditors have learned this about the IBM i platform.

Separation of Duties is only one problem area with the local storage of keys. You also have to contend with Dual Control, Split Knowledge, key lifecycle management, and a broader set of key management best practices most of which are difficult or impossible to achieve when encryption keys are stored locally.

And that’s the main reason IBM i customers are failing security audits around encryption key management.  Download our our Encryption Key Management Requirements for PCI white paper to learn more on how you can pass your next key management audit with flying colors.

Patrick

As a company that provides NIST-certified encryption and FIPS 140-2 encryption key management, we need to secure data on a number of different platforms. Lately we have been coming into several cases where a customer needs encryption and key management on both Microsoft SQL Server and Oracle databases. Below is an email exchange with a customer who came to us “looking for a product to store, generate and manage keys that we use to encrypt/decrypt credit card information inside both SQL Server and Oracle Databases on Windows and UNIX.” We hope this discussion helps with your encryption project.

Customers Environment:

1. Encryption key is generated on the Windows platform through custom software, but if we can move away from that to an automated approach all the better. The key is moved to Oracle manually and we want to replace this with automation.

2. Credit card information is interfaced to our system then automatically encrypted using the key and stored in a SQL 2008 Enterprise Edition server table (only the one column is encrypted).

3. The SQL Server data is then sent to our Oracle database as encrypted data where it is stored in one column of a table.  It is then decrypted and sent to a payment services company who send us back a billing code, which replaces the encrypted credit card number.  So most of the encrypted credit cards are only stored for a short period of time, but some with problems are stored much longer.

Questions Addressed:

Our Alliance Key Manager (AKM) Hardware Security Module (HSM) provides full life-cycle management of encryption keys for PCI DSS and PII compliance. It works with applications and databases on a variety of platforms including Windows, Linux, UNIX, and IBM mainframes. We support the Microsoft EKM architecture for automatic encryption of SQL Server using TDE or Cell Level Encryption. Our customers also use AKM to manage keys for Oracle database applications, and support for Oracle TDE (requires Oracle Enterprise Edition and Advanced Security) is in our product roadmap.

SQL Server:

Because you are running SQL Server Enterprise edition, you have two options. The first is to deploy Extensible Key Management (EKM), which is supported by our Alliance Key Manager. EKM gives you the ability to automate encryption through Transparent Data Encryption (TDE) or Cell Level Encryption. TDE is usually the choice people make as it is the easiest to deploy and does not require any programming. Cell Level Encryption requires a bit of programming, but still fully automates the storage of keys on the key server.

The second approach is to use our Windows .NET key retrieval assembly to retrieve an encryption key from our key server and perform encryption in your application. Since you are already doing an encryption with a local key, this would probably be a pretty simple task. It appears that you might need this type of granular approach to support your current integration between SQL Server and Oracle. We have C# and VBNET sample code that shows how to retrieve a key from the key server.

Additionally, we support Windows 2003 for either approach and both of these approaches will meet PCI DSS standards for key management.

Oracle:

Our customers are currently using our key manager to encrypt data in Oracle databases. We provide sample code in Java, Perl, PHP, and other languages to support this. We also provide a shared library that does secure key retrieval from a variety of platforms, and also sample code that shows how use the shared library in PL/SQL.

Key Generation:

Encryption keys are generated on the encryption key manager using a secure administrator's console installed on a Windows PC. The interface to the key manager is a wire protocol and you can drive it from any application platform that supports SSL/TLS. All of your OS's do so. Our business users attempting to meet PCI DSS requirements for Dual Control and Separation of Duties typically stick to using our secure key management console.

Encryption on HSM:

Our Alliance Key Manager also supports encryption on the server. Rather than retrieving the key to your business application, you can send the data to the key manager with the name of the key you want to use, and it will return the encrypted or decrypted data back to your application on the secure connection. No key leaves the key server with this approach - just an alternative that is worth mentioning.

We hope that this case study can help you with your encryption project.  Listen to our podcast “Encryption Key Management with Microsoft SQL Server 2008 to learn how easy it is for your organization to start encrypting data on your SQL Server.

As we move closer to the finalized rules for HITECH data protection, some things are now becoming very clear.  The government wants ISVs and service providers to offer encryption of data at rest to their customers, and they want covered entities to use it!  While a careful read of the regulations reveals that they do not mandate encryption, the guidance makes clear that encryption is the ONLY safe harbor from breach notification.  Your customers will interpret this as a mandate, and will start demanding encryption in your products and service solutions.  We are already starting to see this happen.

Healthcare ISVs face some really big challenges as they start to move into the unfamiliar territory of encryption and key management.  Here are four critical issues you will face as you start down the path to securing your data at rest with strong encryption:

1)    The Big Challenge is Encryption Key Management

Encryption itself is not really the biggest technical challenge facing ISVs as they start to encrypt data in their application databases.  Most operating systems, databases, and programming languages offer encryption libraries that you can use right off the shelf.  For example, Microsoft provides encryption libraries in SQL server and the .NET language.  Oracle offers similar support for encryption in their database.  The really big challenge is encryption key management.  Encryption keys are the secrets that must be protected.  Key management systems create, store, and protect keys from loss, and this will be the hardest thing to get right.

2)    NIST & FIPS Certification

The HITECH guidance is full of references to the National Institute of standards and Technology (NIST) for encryption standards and best practices.  Advanced Encryption standard (AES) is the recommended technology for encryption.  And the NIST recommendations for key management are the gold standard for key management solutions.  Serious key management vendors submit their solutions to NIST for certification under the FIPS 140 protocol, and these vendors are easy to locate on the NIST web site.

3)    Getting Encryption and Key Management Right

You will be tempted to push the responsibility for encryption and key management to an outside vendor.  If it is really hard to do, why not let someone else do the job? You can refer your customers to the vendor for the solution, and the vendor can do the work of getting the database encrypted.  It seems easy.  Until you discover that your customers are not going to distinguish between your vendor and you when problems happen!  You will be ultimately responsible for any problems with data protection.

4)    The Right Partnership

Many ISVs discover that finding the right partner for encryption key management solutions is the biggest hidden challenge in their projects. Not only is the technology very specialized, there are a small number of vendors who offer FIPS 140 certified solutions.  You have to offer solutions to your customers that are easy to deploy and meet your product pricing objectives.  What if you need a customized key management solution?  Are there any vendors who are willing to help you with these requirements?  Finding the right partner is as important as finding the right technology.

Visit our ISV Partner Program page for more information on becoming a partner or download our white paper titled Healthcare ISVs: Critical Issues in Meeting HITECH Data Protection Regulations.

I recently had a conversation with one of our customers about the automatic encryption webinar they attended.  The webinar demonstrated how companies can implement AES encryption on their AS/400 without making application changes. This customer currently has our managed file transfer solution, FTP Manager with PGP encryption, and was confused as to why they would need AES encryption if they were using PGP. I explained that PGP encryption protects data in motion - when it is transferred outside his company. If he was storing data on his AS/400, he would need AES encryption to protect his data at rest.

AES Encryption
AES encryption is the standard when it comes to encrypting data in a database. Advanced Encryption Standard (AES) has been adopted as a standard by the US government and many state and local agencies. AES is the recommended encryption method for PCI, HIPAA/HITECH, GLBA and individual state privacy regulations. AES encryption uses an encryption key to encrypt the data. Typically, this key is stored on the AS/400 and used when the data needs to be decrypted.  To side track here a little, this is not a good idea. Leaving your encrypted data and keys in the same place is like leaving the key to your house under your door mat. If you want to learn more about why this is a bad idea, take a look at this blog article on the topic.

PGP Encryption
PGP encryption is the standard when it comes to encrypting files that need to be transferred. Pretty Good Privacy (PGP) is the standard for encrypted file exchange among the world’s largest financial, medical, industrial, and services companies. Also know that when encrypting a file with PGP, you may be using AES encryption.  

AES encryption and PGP encryption solutions work together to ensure that all your sensitive data is secure. AES will protect data at rest within your organization and PGP encryption keeps it secure when it is sent outside your company.

I hope this has been helpful in better understanding the differences and similarities of PGP encryption and AES encryption. Learn more about AES and PGP encryption with the webinar "Automatic Encryption on the IBM i" that spurred this conversation or the whitepaper "AES Encryption and Related Concepts". 
 

At Townsend, we have a lot of conversations with customers and prospects about data privacy, compliance requirements and best practices for IT security in general.  We have written numerous articles on these topics and posted them on our blog.  As the end of 2011 quickly approaches, we thought it would be worthwhile to list out our most read articles of the year.

Listed below are the top five read articles from the past year:

• AES Encryption Flaw - Calm Down
  
• PCI DSS 2.0 and Encryption Key Management
  
• Encryption and Key Management in a .NET World
  
• IBM i FIELDPROC Surprises
  
• RSA Encryption Key Size Requirements Change in 2011

We aren’t surprised that the articles on these topics; encryption, key management and PCI compliance are some of the most read on the blog.  We spend the majority of our days talking to people about these topics and helping them solve challenges around data privacy and compliance.  In fact, many of the conversations we have lead to new products and product enhancements.    

In 2012, we encourage you to talk to us about what you need and what you are doing at your company to protect sensitive data.  Subscribe to our blog, like us on Facebook, follow us on Twitter or join us on LinkedIn.

We hope you find the articles listed useful and that it inspires you to think of topics you would like us to write on for 2012. Thank you for your readership in 2011!

We are already preparing and looking forward to sharing more about data privacy in 2012.  

Happy Holidays!!

A number of studies show that only about 25 percent of companies and organizations have deployed encryption of data at rest to meet privacy regulations, and we seem to be stalled at about that level.  We are now about 10 years past the really big data losses that led to the emphasis on protecting data, why are we making so little progress?

I think one of the main reasons is the level of difficulty in deploying most data encryption solutions. Most organizations still see an encryption project as requiring lots of time, money, and human resources to accomplish. As humans I think we all have a tendency to avoid the hard and painful things we know we need to do (I plead guilty). And this is an impediment to getting our data protected with the right encryption and key management technologies.

Vendors of data protection technologies have been slow to address this part of the equation. We have our heads in the technical side of things trying to be sure that we implement secure solutions that meet best practices, and working towards the difficult product certifications that we have to accomplish. The user experience is not usually the thing most on our minds. So, I think we’ve been a part of the problem.

It is also true that developers who are good at the user experience are generally lousy at security. You just don’t go about security development in the same way you mash up a new web service.  Most of the new web-based security solutions that promise to make things so much easier look from the outside really terrible in terms of encryption, key management, and interface security.

It is up to those of us who make security solutions to make them easier to use. Here at Townsend Security we are trying to channel Steve Job’s focus on the user experience.  Once you have the foundational security applications done and certified, it is time to look at how to make them easier to use. This year we implemented our SQL Server EKM encryption key management solution that makes it easy to secure Microsoft data. We also introduced IBM i FIELDPROC automatic encryption which is making data protection a lot easier for AS/400 customers.  I am convinced we are on the right track in this regard, and you will find us trying to make other environments easier to secure as we go forward.

Best wishes for the New Year!

Patrick Townsend

Learn how we have made encryption key management easier and more affordable than ever with Alliance Key Manager.